Jump to content

how to hide data behind the = (page.php?id=xx) for the user


wildware

Recommended Posts

Hello there, Im doing php just for a short time, so Im not expert in many aspects and Im still learning.

I have a problem and I looking for a solution.

I have more pages, where I need get user ID number for receive result from code.

I writen example for understanding.

How to hide the number behind (?id=) ?

I dont want result from another user if anyone just write another number behind = .

Is this possible to hide the number for user or is there any solution? Or maybe repleace the number with any rand (20,200) for example? I tryed many options with rand but i am not getting the result from the database, because I need the proper ID for getting info from database.

Many thanks!!

<?php print "<div class='button'><A  href='ranklist.php?id=$user[id]'>User info</a></div>" 


if (isset($_GET['id'])) {
$userid=$_GET['id'];
 //HERE IS CODE FOR RESULT //
}

 

 

 

 

Link to comment
Share on other sites

Assuming that the user ID is not supposed to be for the current user,

If ranklist.php needs to know which user ID to show then there is no way to hide that information from the user.

If you don't want to show the information then make ranklist.php decide whether or not to show the information. It should check the current user, decide if they're "allowed" to see other users, and if not then give an error or redirect away or something.

Link to comment
Share on other sites

is this your code and design or are you using someone elses code and design?
valid user ids as query strings is insecure and, frankly, stupid.
if you wrote the code, then i suggest a rewrite is in order. do you pass a user id query string to every page as a method of validating a logged in user?
ranklist should simply use the user id in the database to query results for the valid logged-in user.
you would need to rewrite your code to utilize a proper log in script and check the database each page request (shared hosting).
if you have a dedicated host then use a session variable to flag a logged in user but still check the database at each page request.

nota bene: if the current user is not permitted to view another user's page, then this is simply access control and you should slap yo'self for posting this question. if user_id query not equal to user_id then not permitted to view. In other words, if user_id !== user_id query
McFly? Hello, McFly?

try not to search the internet for solutions because you may stumble across a "pretty uri" Apache rewrite proposal, which is not pretty and it is an awful patch for even more awful design methods. Any use of Apache rewrite is alot like saying "pretend [that] you didn't see that", so silly and resource consuming.

i have no idea what "ranklist" is displaying and i don't really care but it could effect resolutions.
if there is a particular reason why you cannot just use a db query to control access, then you are left with patching the code.

if the current user is able to view this current user id associated data, then you could use a session variable instead. However, if all of the users id associated data is accessible to a user, then this would be too many session variables used to replace ids.
use a session variable with a random get_id string id as key and user_id as value
check if isset session variable $_SERVER['QUERY_STRING'] (not $_GET['id']), which is now random get_id string, then display the user_id associated results.
the real id is associated with the random get_id string (= key/value)

you could also use a database instead of a session variable.
at login, generate a random string and insert it into the user table column, named (for example) hide_user_id
then, you could use that temporarily valid id instead of a session variable.
query the db when loading ranklist and retrieve the correct user id to display the asociated data using this hide_user_id in the query.
just be certain that the hide_user_id column has a unique constraint applied.

just use your noggin and create a patch until you can rewrite the code correctly.

Best Wishes, Biff.

Link to comment
Share on other sites

your code should be as general-purpose as possible, so that you don't need to keep redoing it as requirements change. the URL should uniquely determine what information will be displayed on a page, so, yes you should put the user id as a get parameter in the URL.

the code for any page must enforce access permission for that page. for what you are seemingly asking, you would compare the logged in session user id with the get parameter id and only query for and display the requested user's data, using the get parameter id, if they match.

if at some point you have a site administrator or a list of permitted 'friended' users, you would query for and display the requested user's data, using the get parameter id, depending on the current user's access permission for the requested user's data.

Link to comment
Share on other sites

If you're using Sessions (not everybody does) you could capture the given QueryString Argument, save it into the Session, then redirect to the same page without the QueryString Argument, this time taking the id value from the Session.  

This may go some way to achieving what you want: 

if ( isset( $_GET[ 'id' ] ) 
{
   $_SESSION[ 'id' ] = $_GET[ 'id' ] ; 
   http_response_code( 302 );
   header( 'location: .../same_page_without_querystring_arguments' ); 
   return; 
}

if ( ! isset( $_SESSION[ 'id' ] ) )
{
   // No id available! 
   header( 'location: .../errorpage.php' ); 
   return; 
}

$id = $_SESSION[ 'id' ]; 
// Display rest of page. 

 Of course, it's not foolproof - anything that can be built can be broken and, at the end of the day, the browser simply has to know this value in order to request it! 

Regards, 
   Phill W. 

 

Link to comment
Share on other sites

4 hours ago, Phi11W said:

This may go some way to achieving what you want:

...with the unfortunate downside that a user can simply add an ?id to bypass the "verification" this process tries to add.

Side note: adding arbitrary data into the session is generally not a good idea.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.