Jump to content

Recommended Posts

Posted

so who know alot about php sessions? i kind of have them working right now. but what should i be checking for? like what data should i save in the sessions considering that ppl will be logginning in with a username+password?


Posted (edited)

edit in: It's late, I'm tired, and haven't much time on the net lately, so I may have rambled a bit here.

Personally, I've been using a self-handled PHP session rather than php's built in session functions so, your mileage-may-vary here. Working with sessions myself are based off the users Primary-IP, Forwarding-IP (if applicable), and a random UID# which is sent through a cookie(only the uid is in the cookie). Those 3 variables make up the session itself which is then tracked/updated/validated serverside.

So, take for instance, the users IP is 127.0.0.1, they are sent a cookie containing a randomly generated UID# which is stored on the client. The session ID is a combo of the users IP+UID#. If any any point the users ip changes, or the cookie is changed/deleted, the session is no longer valid. If it stays the same, the server looks up the stored session 'key' (made up of the mentioned info) and then matches it to the user.

The drawback to using this method though means the sessions lasts as long as the users cookie & IP stay the same. So, 'remember me' logins & methods won't last.

Breakdown:

Users IP is: 127.0.0.1

User gets UID from server as cookie with uid: '1234'

both of these create a session key (crypted possibly under md5) such as '13287sessionkeyblah1234'.

The server stores the session in a local database or file (in this case) as:

$session['13287sessionkeyblah1234'];

The session however contains user relevant info such as the last active time, username, and other information.

So, it would end up as:

$session['13287sessionkeyblah1234']=array('time'=>12345678,'user'=>'username');

Now as long as the users ip's stays the same and their UID in the cookie stays as '1234', their session info will match. Otherwise there is no data to assign to them and so treated as a guest.

The point of the timestamp is for session purging. Every page load the sessions would get queried by time and any of them last active longer than a set threshhold (such as 360 sesonds) will be removed.

(yay! rambling!!!)

What you store in the sessions is up to you as to what is being handles really. A session would really work out serverside for user specific functions as that could alleviate extra queries on the users database when looking up on the user themself. So, items such as:

0) What session 'key' am I bound to?

1) Which user am i?

2) When was this session last active?

3) What did I last click or do here?

4) Did I do this yet? or that?

etc. would be best stored in a temporary session.

Edited by Chozo4

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...