Username Password
Bookmark and Share
Allow purely cookie based sessions?  (#11706)

Using Plack::Middleware::Session, it is trivial to allow session data to be stored in a cookie in a safe way.

While the cookie data would be unencrypted, it would be protected against tampering using a signature.  This would make it safe to store information like the user ID in it and rely on that data.

The main problem with this is if we ever stored data in session scratch that the user shouldn't have access to.  I don't believe we do, and can't think of any good examples of this either.

This also has an impact on other session related data stored in the database.

7/12/2010 12:14 pm
This also means that the system has no way of tracking or expiring active sessions.

It would be simple to have the storage mechanism configurable.  So as an administrator you could specify sessions be stored in cache, DB.  But it would be harder to have the rest of the system adapt to that change.  If we made sure all session data was stored in the session itself, it would probably be reasonable.  Tracking and expiring of sessions are mostly self contained and auxiliary features, and could be dependent on having sessions stored in the DB.
7/12/2010 12:44 pm
This sounds like "If it ain't broke, don't fix it".

It would protect against stale and/or unreachable scratch data, but so would triggers or other things.

There are limitations: Size/number of cookies (20 cookies per domain, 4K per cookie or something), so it might not be a problem really (80K is more than the size of a MySQL Text field, but there is also overhead).

Configurable shouldn't be an option, that's a developer decision (or, it requires knowledge that only a developer will really have like "How much data are we storing in Scratch" and "How sensitive is the data in Scratch").

Is the goal to reduce DB access? If so, a more persistent cache might be a better option (with levels of l1_cache).
7/12/2010 1:19 pm
It has the advantage of eliminating a number of db/cache hits, and makes it so you never have to track sessions.  This means you could set an almost infinite session timeout and not have to worry about having to deal with the data on the server side.

For some sites, being able to track sessions is valuable, but for most it is an unnecessary burden.  Being able to eliminate both the database and cache hits as well as the maintenance tasks needed would be better for those cases.

I see it more as a server admin decision because it would be a trade off between active tracking of sessions and performance.  And that decision depends more on the site than the code.

The size limitation does present a possible problem.  But do we ever store that much data in scratch?  Granted, the amount you can store is currently assumed to be unlimited.

I'm really having a problem coming up with a case where you would store something in a session that the user wouldn't otherwise have access to read.
7/12/2010 1:46 pm
I use it in the Twitter auth module to store the two keys (one says its secret) needed to complete session validation, but would that really be a problem if they could see it?
7/12/2010 1:55 pm
The more I think about the size limitation the more I don't care about it. If you're really storing a full HTML page or PDF or what-have-you, you should be putting it somewhere other than session scratch. Scratch is just a little place to jot down notes attached to a session, if you need more store an ID and reference another table.
7/12/2010 2:03 pm
And that same argument could be applied to the "sensitive data in scratch". If you, the developer, are worried about it, encrypt it or store it somewhere and keep a nice harmless ID in the session.

That being said, this is low-priority.

And okay, there should be a "trackUserSession" config option which would enable the "Active Sessions" pane and maintain the current userSession table.

Question: What happens if someone changes the expiration on their cookie? Steals an entire cookie from someone? (though really is that any different from what would happen now?)
Ticket Status Pending  
Submitted By Graham  
Date Submitted2010-07-07 
Assigned To unassigned  
Date Assigned 2019-08-22  
Assigned By  
Priority Not Blocking/Desired  
Milestone 8.0.0 Beta  
Ticket History
11:49 AM
Ticket created Graham
© 2019 Plain Black Corporation | All Rights Reserved