Is this proposal dead? I would like to see this as well. It seems like a default worth having, and an optional way to turn it off solves the backwards compatibility problem.
On Tuesday, May 27, 2014 at 9:56:58 AM UTC-7, Stephen Touset wrote: > > In that case, even that shared cookie should likely be HttpOnly anyway. > > I'm not quite following why anyone would really oppose such a change here > — Rails needs to maintain a strong secure-by-default stance, and every case > where developers have to opt-in to security is a case where many developers > will not. As long as there's a flag that's set to the current behavior for > existing projects, and defaults to secure behavior for new projects, there > shouldn't be any backward-compatibility concerns. > > If you need to access a cookie in JS, set it in JS or disable HttpOnly for > that specific cookie. If a developer doesn't upfront anticipate it being > used in JS, then it shouldn't be *allowed* to be accessed from there. > -- > Stephen Touset > ste...@touset.org <javascript:> > > > On Mon, May 19, 2014 at 5:34 AM, Gabriel Sobrinho <gabriel....@gmail.com > <javascript:>> wrote: > >> I can't be sure but using cookies for that sounds the wrong solution for >> me, you have better options like a shared database, a redis instance may >> work. >> >> You'll need to use a cookie to share a session identifier (I would use a >> uuid) between the applications but reducing it to just one cookie may >> mitigate the need to mark all shared cookies as http only, but I don't know >> your environment, so please don't take this a recommendation ;) >> >> >> About rails, I would be concerned to backwards compatibility too, but we >> need to have access to both options (httponly and not httponly). >> >> Something like cookies.secure[:key] = 'value' and cookies[:key] = 'value' >> may work but it won't be secure as default. >> >> If we are choosing for security first, we may have cookies.insecure[:key] >> = 'value' or something like that. >> >> On Sunday, May 18, 2014 4:25:35 PM UTC-3, Matt jones wrote: >>> >>> I’ve had to resort to some pretty weird cookie stuff when passing data >>> between a Rails app and non-Rails applications. The session is handy, but >>> parsing it anywhere but in Rails is difficult and *updating* it outside of >>> Rails is more difficult. >>> >>> —Matt Jones >>> >>> On May 17, 2014, at 9:12 AM, Gabriel Sobrinho <gabriel....@gmail.com> >>> wrote: >>> >>> I would argue that if you have some information that can't be hijacked >>> and even parsed on javascript (httponly cookies can't be read on javascript >>> at all), why would you use cookies instead of the rails session? >>> >>> On Friday, May 16, 2014 7:07:42 PM UTC-3, fedesoria wrote: >>>> >>>> I would like to see this happen, since when dealing with >>>> Enterprise Vulnerability Scans it always comes up. >>>> >>>> On Monday, January 7, 2013 2:09:42 PM UTC-8, Stephen Touset wrote: >>>>> >>>>> Earlier, someone proposed on the GH issues tracker that Rails default >>>>> all cookies to HttpOnly[1]. Rails already makes the session cookie >>>>> HttpOnly, but given a general to keep Rails secure-by-default, it would >>>>> probably be best if *all* cookies defaulted to HttpOnly. This would be a >>>>> compatibility-breaking change, but it wouldn't be difficult to add a >>>>> configuration option that can be defaulted to false for existing Rails >>>>> apps >>>>> that are upgraded. >>>>> >>>>> I'm more than happy to write the code for this change, but wanted to >>>>> discuss it here first to see if anyone objects strongly. Josh Peek had >>>>> concerns with backwards compatibility, but I think my proposal above for >>>>> a >>>>> configuration option should satisfy them. Anyone care to weigh in? >>>>> >>>>> [1] https://github.com/rails/rails/issues/1449 >>>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ruby on Rails: Core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to rubyonrails-co...@googlegroups.com. >>> To post to this group, send email to rubyonra...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/rubyonrails-core. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Ruby on Rails: Core" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/rubyonrails-core/yDzoifkfqvc/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> rubyonrails-co...@googlegroups.com <javascript:>. >> To post to this group, send email to rubyonra...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
