On Mar 22, 2007, at 11:15 AM, S. Robert James 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?
And I think that is exactly what it comes to. That's kind of where I landed with that post when I started considering what user_id really meant. As neat as cookie sessions are, I don't think I'm going to use them to store authentication info anymore. Too many question marks. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
