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 > <[email protected]<javascript:>> > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected]<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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
