NYCPHP Meetup

NYPHP.org

[nycphp-talk] preventing randomized session variable from changing when page is refreshed

Ben Sgro ben at projectskyline.com
Thu Aug 21 09:51:40 EDT 2008


Hello Kristina,

David summed this up pretty darn well. I don't see why you are reluctant 
to use session_id and the other functions. It solves all the problems
I can see that you are mentioning.

Maybe you could create a test script to play with session_id to get a 
better feel for how it works, and remove and doubts you have as well.

Good luck,

- Ben

David Krings wrote:
> Kristina Anderson wrote:
>> Yes, but if I do $_SESSION['cart_id'], it is effectively the same 
>> thing, I'm using this random string as an identifier for the unique 
>> cart.  This is effectively the same as $_SESSION['session_id'] -- 
>> only the name is different.
>
> And there is no reason to name it differently. I have a script using 
> sessions extensively and create a temporary folder using the session 
> string. I have code in place that checks if the directory already 
> exists, but session IDs generated by PHP are so unique that I yet have 
> to see that code getting executed - and that after I don't know how 
> many ten thousand times. I agree with John that there is absolutely no 
> reason to generate your own ID.
>
>> the unique identifier is generated when index.php loads, and is 
>> passed as a querystring throughout the user's shopping and each 
>> product they view/order is tagged with their unique identifier.
>
> Which isn't necessary if you run session_start() at the top of each 
> page before executing any other code and sending anything to the browser.
>
>
>> The problem is that if they refresh/reload index.php...that value 
>> will change and their cart will be nuked.  Which will be bad.  
>
> Not if you use session_start() as John rightfully mentioned already. 
> As far as I know session_start() checks if the requesting browser 
> connection ever started a PHP session and if yes, it uses the same 
> session ID again, otherwise it generates a new one. And that is 
> exactly that you want. You have an entry point such as a login or a 
> "Shop 'til you drop now" button or in your case the index.php. When 
> the browser requests that resource for the first time session_start() 
> will not find any session ID for that requesting browser session. So 
> it creates a new one that can be retrieved via session_id(). And that 
> ID does not change when each consecutive script calls session_start() 
> before executing any other code and before sending anything to the 
> browser. So when you have session_start() as the first line after the 
> opening tag in the index.php two things can happen:
> a) the current browser connection never had a session ID and a new one 
> is generated
> b) the current browser connection has already a session ID established 
> and uses that one
>
> Especially case b) allows for a browser to call index.php as many 
> times as desired and any consecutive request will cause that PHP / the 
> web server always end up with exactly the same session ID. And what is 
> even better, PHP takes care of getting this to work even when the 
> requesting browser does not accept cookies. I think PHP's session 
> handling is absolutely awesome and makes things so much easier. I key 
> everything off the session ID, even the name of temporary tables in 
> MySQL (you just need to add a _ in front of the ID to prevent illegal 
> table names to occur). And the big master key for everything is always 
> in place when you just make sure that the first thing to do in a 
> script is call session_start().
> I have the bad habit to start writing all kinds of things into the 
> session array because it gets conveniently carried around for me, but 
> I guess in a serious application that involves money you want to keep 
> things on the server.
>
>> One thing that I just thought of a couple minutes ago would be to 
>> just use index.php to generate that...then include a new page and 
>> exit index.php so they won't ever be going back to that page during 
>> the session.
>
> Well, but they DID get to the initial index.php in the first place, so 
> they can get back there again, just by using the back button of their 
> browser. Using session_start() will even take care of that.
>
>
>>
>> As for why I do things the way I do...I am using $_SESSION and not 
>> just $_GET which may not have been clear from what I posted.
>>
>
> I found only one case where GET saved the day in all the years I deal 
> with PHP (well, on your schedule it ends up to be maybe only a few 
> months). POST or keeping things on the server side and keying off a 
> session ID is better.
>
>
> What you could do is add code to the index.php to fire some 
> housecleaning script that takes care of stale carts. In my projects I 
> store the session ID with the user ID and the date / time of login in 
> a table. Each time the main page gets loaded I run a quick check 
> against the date / time field and see if there are any stale logins. 
> Anything older than a day is considered stale and I ditch any 
> temporary directories, tables, and eventually the login entry itself. 
> That works reasonably well for my purposes and cleans up the crud for 
> all those cases where the user did not log out, which I assume will 
> happen often. I doubt that my approach scales well as I hit the 
> database once for typically nothing and potentially end up cleaning up 
> a lot of stuff. For example on one day I end up with 50000 stale 
> sessions and two days later the next user comes along and now I start 
> this big cleanup and let that poor bastard wait until I'm done. What 
> might be better is to write the login info into a flat file so that a 
> cron / scheduled job can run during slow times and kick off a script 
> that does the house cleaning then. There may also be better solutions.
>
> Basically, I can only nod in agreement with what John wrote, you do 
> want to use session_start().
>
>
> David
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>



More information about the talk mailing list