I understand the distinction very well. I would suggest that you have ascribed more capability to 'session' than the semantics of that facility allow.
What I'm saying is that now you have client side session data, you have exposed the limited semantics of 'session' and there is an issue that was simply masked by the server side stores. Rails has never offered authenticated anything. That's why there is no standard login mechanism. Why not switch to session side stores and mask the issue, or implement an AuthenticatedSession that does what you want it to do (and release it as a plugin if you so desire). Complex cookie encryption might be an interesting technical puzzle, but is it really required by default? It's a question again of where the framework ends and the application begins. I don't believe that there is justification for foisting complex default encryption mechanisms on the framework when the 'problem' is that you are using the wrong model. Just use a server side session store. Now I may be wrong about 'session'. Perhaps it is a much more complex object than it appears. Perhaps it should be. That is not for me to decide. NeilW On Mar 26, 7:45 pm, Brad Ediger <[EMAIL PROTECTED]> wrote: > 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?- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
