I'm not sure you understand the distinction here. We had server-side sessions before. We still do. They accomplish everything you are describing, without requiring every developer to implement an AuthenticatedSession object himself. Look into ActiveRecordStore in action_controller/session/active_record_store.rb.
This discussion is about the recent move to sessions stored in a cookie, and how to secure such sessions. I would suggest you go to Google Groups and read this thread from the beginning to get the background. On Mar 26, 2007, at 1:35 PM, Neil Wilson wrote: > > The 'standard' use is incorrect. I don't believe it has ever been put > forward as 'best practice' by any serious modeller. All I've seen it > in is in simplified tutorials. Are you sure it isn't a case of truth > by repeated assertion? > > You shouldn't be storing ID references to the User model in the > session hash; you should be storing ID references to the > AuthenticatedSessions model. > > That way when you click 'LogOut' the relevant AuthenticatedSession > object is deleted from the database, and then it doesn't matter one > jot what the next persion does with the cookie. > > If something doesn't fit, then look to the model. You've probably > missed a relationship that should be a first class model object. > > On Mar 22, 5:15 pm, "S. Robert James" <[EMAIL PROTECTED]> wrote: >> On Mar 22, 10:44 am, Brad Ediger <[EMAIL PROTECTED]> wrote: >> >>> This is the crux of the issue... of *course* it's a terrible idea to >>> store sensitive or transient data in the session, but the >>> question is >>> one of API design. Do we want the penalty for ignoring best >>> practices >>> to be compromised security? >> >> It's even more complicated. Defining "sensitive or transient >> data" is >> not at all trivial. >> >> The standard use case for a cookie session is store only flash and >> user id. Not sensitive or transient? Okay. >> >> Now, I click "Log Out", and get up from the library's computer, only >> to let the person waiting after me to retrieve the old cookie.... >> That >> innocuous user id just became both sensitive and transient. >> >> The point is, answering these questions is hard. Witness the >> confusion in this thread alone. DIY cryptosystems are hard: >> professionals fail. WEP failed. Does it make sense to push all >> these >> questions onto each new Rails developer's shoulders? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
