Sessions management and AJAX
Moderator: General Moderators
Sessions management and AJAX
There is suprisingly little said about this on the net. What's said isn't exactly what I'm after (Eric Pascerello's examples).
Essentially, I'm interested in hearing what others are doing to make sure sessions are managed in AJAX rich pages in much the same way they are
using the normal web development model.
Presently, I'm generating a token for each page load. That token is associated with a session security ID. The token itself is a hash of that ID and a randomly generated string of arbitrary length. I'm planning on providing a mechanism to allow multiple tokens to be associated with a single security ID since there's bound to be some tosser that will open multiple pages once they've logged into the site.
Anyway, that's the approach I want to take but I'm curious to hear what's being done.
Cheers
Essentially, I'm interested in hearing what others are doing to make sure sessions are managed in AJAX rich pages in much the same way they are
using the normal web development model.
Presently, I'm generating a token for each page load. That token is associated with a session security ID. The token itself is a hash of that ID and a randomly generated string of arbitrary length. I'm planning on providing a mechanism to allow multiple tokens to be associated with a single security ID since there's bound to be some tosser that will open multiple pages once they've logged into the site.
Anyway, that's the approach I want to take but I'm curious to hear what's being done.
Cheers
Is this really needed? I would assume that if you called say 'client.php' and that page displayed your ajax viewer, then you had a file called 'getClientList.php' that returned a list of clients from the same server.... then client.php would start a session, and getClientList.php would refresh/use that session and you wouldn't have to do anything funky.
Yeah, this is really needed. The net is apparently rife with issues relating to race conditions stemming from AJAX usage as well as the fact that an RPC server (or whatever you use to answer your AJAX requests) needs to be just as vigilant in not letting in the rift raft. That said, I'd better get the sessions management right before I go stumbling into a Charlie Fox.
Do a google search on AJAX and Race conditions.
Do a google search on AJAX and Race conditions.
It appears the race conditions aren't all that terrible. It can be simply an issue of time stamping the requests and then making sure to check the order as they come in. I guess it depends on your app. If its not something where race conditions are going to kill everything then I wouldn't bother messing around with it.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
I'm I correct in that this problem exist only where multiple requests are executed at once? I ran into that problem early and it required a complete change in architecture. Instead of making a request for each part of the view separately, one request is used to gathers the separate parts of the view.
Exactly!Buddha443556 wrote:I'm I correct in that this problem exist only where multiple requests are executed at once?
That said, how do you ensure that a user who has just logged into your site and now has an open session isn't going to open 3 seperate links in 3 seperate tabs? All links that have AJAX in them that is polling (or something) the server on their own as well as manually. While each of those 3 seperate pages may not have anything to do with one another, that fact alone won't garauntee something unforseen when these multiple requests start heading in.
But that's just the race conditions part and the more we talk about it, the more we get off track.
I'm more interested in how people are
a) Ensuring that the person calling their service via HTTPRequest has a valid session in the first place.
b) And how they're updating the session information.
I'm more interestin in a) to be honest with you.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
To tell you the truth I don't recognize this as a race condition problem, till you mentioned it, to me it was a resource problem. Too many database connection per page. If I did more testing down that path the race condition would've been obviously a bigger problem. I'm not doing any automated polling [anymore]. So basically, I've mitigated the problem [by using only one request per action] to levels equal to that of non-Ajax PHP pages. Though I really have to give this more thought now that you've pointed it out to me.BDKR wrote:Exactly!Buddha443556 wrote:I'm I correct in that this problem exist only where multiple requests are executed at once?
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
The request is standard HTTP - the method of validating the session is the same for any "generic" request. To be honest I'm finding a lot of oddities in how AJAX is being described. At the end of the day all it's doing is sending atypical HTTP GET and POST requests. There's nothing complex about that. The problem seems to be in assigning blame. PHP is doing nothing wrong. The client browser is doing nothing wrong. The HTTP spec is certainly not wrong. So what's gone wrong?a) Ensuring that the person calling their service via HTTPRequest has a valid session in the first place.
Here's the problem in a nutshell. Your PHP Sessions are not being locked. It's a revolutionary concept - locking. I could spend all day moaning about how custom session handlers are the bane of the Universe, they sit on my uber security/quality checklist looking all sad and depressed as I put an X alongside and tell the programmers who fiddled the handler from the PHP manual to go away and do it properly.
So you need to add locking. Nothing client side will enforce that - though it can help. In AJAX applications, people have a habit of letting one user mouse click fire off multiple requests. They're rarely ordered, numbered and queued on a FIFO basis which would prevent the whole "my responses are coming back in a different order!" surprise act. Shouldn't be a surprise - on dial up it's funny enough without adding broadband to the show. If requests go out one by one then there won't be a race condition (though the multiple-tabs will break that).
At the end of the day, you need a server side solution - only concrete method since the client code is "suspect" anyway. I'm guessing you are either a) implemented a file based session handler and left out locking or b) implemented a typical scalable database session handler.
You can resolve a) by adding locking. Depends on the system for support. Check if your filesystem supports it (usually does). Does not work on NFS, which moves us to the b) option.
Resolving b) is more challenging since it requires some nifty session support to be built into the application from the start. You start by recognising the traditional Session as a lost cause. Using session_start() on a database handler and expecting perfection is not going to work. You need to throw it out, and put in a replacement for the $_SESSION variable you likely reference everywhere (in some form even an OO wrapper).
I won't detail it. I robbed it last year from Andy Bakun. I blatantly copied the code line for line. He wrote the finest analysis of race conditions on the web for AJAX specific problems (i.e. the disordered requests hitting an unlockable session datastore). You can find him here: http://thwartedefforts.org/2006/11/11/r ... -sessions/ . Before this I had something similar, but far less prettier. I also suspect it didn't really work very well since it relied on a few "timing" assumptions which is never a good sign - on a more popular site it would have failed miserably and sulked for weeks. Use this one or a variant of it.
Code: Select all
<script type="text/javascript">
var sessionId = "<?php echo session_id(); ?>";
var sessionName = "<?php echo session_name(); ?>";
var http = XMLHttpRequest();
http.open("GET", "http://www.host.com/page.php?" + sessionName + "=" + sessionId);
// etc..
</script>Maugrim_The_Reaper wrote:The request is standard HTTP - the method of validating the session is the same for any "generic" request. To be honest I'm finding a lot of oddities in how AJAX is being described. At the end of the day all it's doing is sending atypical HTTP GET and POST requests. There's nothing complex about that. The problem seems to be in assigning blame. PHP is doing nothing wrong. The client browser is doing nothing wrong. The HTTP spec is certainly not wrong. So what's gone wrong?a) Ensuring that the person calling their service via HTTPRequest has a valid session in the first place.
Here's the problem in a nutshell. Your PHP Sessions are not being locked. It's a revolutionary concept - locking. I could spend all day moaning about how custom session handlers are the bane of the Universe, they sit on my uber security/quality checklist looking all sad and depressed as I put an X alongside and tell the programmers who fiddled the handler from the PHP manual to go away and do it properly.
So you need to add locking. Nothing client side will enforce that - though it can help. In AJAX applications, people have a habit of letting one user mouse click fire off multiple requests. They're rarely ordered, numbered and queued on a FIFO basis which would prevent the whole "my responses are coming back in a different order!" surprise act. Shouldn't be a surprise - on dial up it's funny enough without adding broadband to the show. If requests go out one by one then there won't be a race condition (though the multiple-tabs will break that).
At the end of the day, you need a server side solution - only concrete method since the client code is "suspect" anyway. I'm guessing you are either a) implemented a file based session handler and left out locking or b) implemented a typical scalable database session handler.
You can resolve a) by adding locking. Depends on the system for support. Check if your filesystem supports it (usually does). Does not work on NFS, which moves us to the b) option.
Resolving b) is more challenging since it requires some nifty session support to be built into the application from the start. You start by recognising the traditional Session as a lost cause. Using session_start() on a database handler and expecting perfection is not going to work. You need to throw it out, and put in a replacement for the $_SESSION variable you likely reference everywhere (in some form even an OO wrapper).
I won't detail it. I robbed it last year from Andy Bakun. I blatantly copied the code line for line. He wrote the finest analysis of race conditions on the web for AJAX specific problems (i.e. the disordered requests hitting an unlockable session datastore). You can find him here: http://thwartedefforts.org/2006/11/11/r ... -sessions/ . Before this I had something similar, but far less prettier. I also suspect it didn't really work very well since it relied on a few "timing" assumptions which is never a good sign - on a more popular site it would have failed miserably and sulked for weeks. Use this one or a variant of it.
I guess I'd better add to this since the last post was deleted.
Your post was a waste of time! Why? Because in my previous post I said....
If you want to continue to discuss Race Conditions in depth, start another thread.BDKR wrote: But that's just the race conditions part and the more we talk about it, the more we get off track.
Cheers
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact: