Hi Phil,
Phil Sturgeon - 26 June 2009 11:46 AM
That is a definite security improvement. Is this basically a fully compatible drop-in replacement that moves the data from browser to database?
i am using this as a fully drop-in replacement in my app. As you can see i am currently in a phase wich i am open to improvements 
Phil Sturgeon - 26 June 2009 11:46 AM
I’m not so keen on the way you create your security key though. It seems to be created from a static string and then use only a few bits of pretty common $_SERVER data. I would rather see it using the encryption_key from codeigniter and a random salt, mixed in with that data if you wish.
the security key is needed just for not saving the tokens of this user in plaintext. Other session-libs are saving the useragent in plaintext. I think there is no need to get more encrypting. Maby i don’t get the point!?
Phil Sturgeon - 26 June 2009 11:46 AM
Also, will this data be cached?
What do you mean exactly with: “will this data be cached”? Any examples?
Phil Sturgeon - 26 June 2009 11:50 AM
Another thing, how well do you handle mismatches of sessions/cookie/database? I have implemented something like this at work to allow login integration between a CMS and our online trading systems and I had to find a way to keep the cookie refreshed while the user was looking around either site even when not requesting any session data. I also had to make sure the database record was replaced if the cookie existed while the database record didn’t, will your library do this?
Because the library is based on the native PHP-session-management, there is (as far as i know) no need in handling such issues because PHP itself does.
If the session in the database does not mach the cookie, the session will be started with the session-id of the cookie, if the cookie does not match the database, the cookie will be updated.
Regards
Carnalito