Jump to content

PHP Sessions


vickyb

Recommended Posts

Hello

 

I am using the following code to fetch the USERS name based on the key I stored as a session when the user logged in

 

My code is

$key = $_SESSION['logged_key'];
if ($pcess = $mysqli->prepare("SELECT id, name FROM people WHERE key = ? LIMIT 1"))
{
$pcess->bind_param('s', $key);
$pcess->execute();
$pcess->store_result();
$pcess->bind_result($id, $name);
$pcess->fetch();
}

My question is:

 

Is there a better way to pass the session ID, or run the Query that would increase the security, performance and overall safety?

 

Thanks Everyone

 

V

 

 

Link to comment
Share on other sites

Hi

 

Thanks, but the reason I dont store all this data when they login is because i need to pull other bits of data also, and it would be too much to store everything as sessions

 

Why not fetch that info (users name and id, etc...) when he logs in? Then just store in session and use when needed. Sessions can hold quite a lot of information, and it will keep you from having to make a lot of database requests.

Link to comment
Share on other sites

My preference is to store just the user's ID. Whenever the visitor goes to a different page, I'll query the database to re-validate the user and get the rest of the information. That way if the visitor's permissions are ever revoked, they can be kicked out during an active session if necessary.

 

How would you re-validate without the user having to enter password etc each time?

Link to comment
Share on other sites

I guess what I meant be re-validate, is to check the flag which indicates whether they have access or not. I'll basically create a column to indicate if a visitor is active. Every time they go to a new page, I'll check that flag before getting the other information like their name. If the flag is set to false, an error message is displayed. Otherwise, the page content displays as normal.

Link to comment
Share on other sites

I guess what I meant be re-validate, is to check the flag which indicates whether they have access or not. I'll basically create a column to indicate if a visitor is active. Every time they go to a new page, I'll check that flag before getting the other information like their name. If the flag is set to false, an error message is displayed. Otherwise, the page content displays as normal.

 

OK thank you, that makes sense.

 

Should I wrap anything around the sessions vars when doing a WHERE lookup? Like mysql_real_escape_string ? Or

 

I guess my question is, if the user logs in and the database flag is set to 1, then when the user is not logged in the flag needs to be set to 0.

 

0 = not logged in

1 = logged in

 

I could set the flag to 0 when the user logs out of the website, but how do I handle the case where the session expires and the user has to re-login?

 

Because if the session expires before the user actually logs out, then the database flag would still be set to 1, so how do I get it to revert back to 0 if the session expires, or the user simply closes the browser before logging out?

 

Thank you

Link to comment
Share on other sites

Just to clarify, the flag I use indicates whether the user has access or not. It's not whether they are logged in or not. That's what the session is for. Basically I use the "active" flag to remove someone's access to the content for an extended period of time. For example, I may have a group of people who manages an aspect of a website. If someone is no longer part of that group for whatever reason, I'll switch the "active" flag to false. That way they can no longer make changes; even if they are currently logged in. As soon as they visit another page, the system logs them out (removes the SESSION) and displays an error.

 

As for your question about wrapping the SESSION variables, it depends. If you're only using a SESSION variable which contains the user's ID and that ID only contains numbers, I would just make sure the ID is valid before running the query. Currently, I prefer to validate numbers with ctype_digit():

http://www.php.net/ctype_digit

Link to comment
Share on other sites

Just to clarify, the flag I use indicates whether the user has access or not. It's not whether they are logged in or not. That's what the session is for. Basically I use the "active" flag to remove someone's access to the content for an extended period of time. For example, I may have a group of people who manages an aspect of a website. If someone is no longer part of that group for whatever reason, I'll switch the "active" flag to false. That way they can no longer make changes; even if they are currently logged in. As soon as they visit another page, the system logs them out (removes the SESSION) and displays an error.

 

As for your question about wrapping the SESSION variables, it depends. If you're only using a SESSION variable which contains the user's ID and that ID only contains numbers, I would just make sure the ID is valid before running the query. Currently, I prefer to validate numbers with ctype_digit():

http://www.php.net/ctype_digit

 

Thanks, I was going to store the user id and a unique MD5 hash for each user record, and then store them as sessions, so when i do an update i'll use the user id and hashed string, for a double check.

 

So you're suggesting not to bother wrapping anything around sessions in that case?

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

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.