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
step...@touset.org
On Mon, May 19, 2014 at 5:34 AM, Gabriel Sobrinho
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
>> >
>> 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-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.
--
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.
