Need to be able to send secure session cookie for localhost

[jrmcgarvey]

Right now, unless it is ssl, you can't send a secure session cookie. It is perfectly valid to do this for localhost, and very desirable for development.

In lib/rack/session/abstract/id.rb, I think it should say something like:

def security_matches?(request,options)
return true unless options[:secure]
request.ssl? || request.host == "localhost"
end

[ioquatix]

That seems reasonable to me, but I don't fully grok the implications. Do you mind submitting a PR? Then we can discuss the specifics.

[jrmcgarvey]

I can. It's a little confusing, because Rails sets cookies two ways, one for sessions, one for all other cookies. For other cookies, Rails does not document how to send secure cookies when the app is in production behind a proxy, so that requests are not coming over ssl. But I'll submit a PR.

One background issue is that when Rails is used as a back end, it would be nice to use the httpOnly session cookie, so that one doesn't have to adopt the risky strategy of storing auth tokens in local storage -- but the browser vendors are on a path to eliminate third party cookies.

[ioquatix]

It is perfectly valid to do this for localhost

Is there any other evidence (library implementation, framework, documentation) to support this assertion? It would be extremely helpful to understand the broader context.

[jrmcgarvey]

Yes, this is documented here. RFC 6265 punts to the browser implementation on the question of what constitutes a secure connection. See my response on the PR.

[ioquatix]

Just for reference, I assume we are talking about:

A cookie with the Secure attribute is only sent to the server with an encrypted request over the HTTPS protocol. It's never sent with unsecured HTTP (except on localhost), which means man-in-the-middle attackers can't access it easily. Insecure sites (with http: in the URL) can't set cookies with the Secure attribute. However, don't assume that Secure prevents all access to sensitive information in cookies. For example, someone with access to the client's hard disk (or JavaScript if the HttpOnly attribute isn't set) can read and modify the information.

[jrmcgarvey]

Yes, that's the only reference I can find on the issue, other than the RFC.