Proposal for remember me (protocol switch)

Hello,

I'm using Spring Security 3.1 RC3 but this is a common problem with other versions.

On a regular basis, we see questions about switching from HTTPS for login page to HTTP for other pages. This switch cause the session to be lost because of the flag "Secure" of the relevat session cookies (jsessionid or remember-me).

I know the criticisims about this approach "it's not a good idea to switch back to http" but since a LOT of people anyway are triying to do this, I think this scenario should be supported, at least not in the default configuration.

Basically the problem can be solved giving the user the ability to choose if the relevant cookies can be flagged as secured or not, overriding the container default behaviour that is flagging the cookie based on request.

I see there is the option "use-secure-cookie" on the <remember-me> namespace config that flags the cookie as secure. IMHO, there should be also the opposite behaviour. Setting it to false should avoid the flag.

Unfortunately this doesn't happen right now. From the 3.1 RC3 code of RememberMeBeanDefinitionParser, line 101

Code:

---

    if ("true".equals(element.getAttribute(ATT_SECURE_COOKIE))) {
        services.getPropertyValues().addPropertyValue("useSecureCookie", true);
    }

---

This means: if it's true, set the property to true, otherwise, leave it null. And now, from the AbstractRememberMeService, line 348

Code:

---

    if (useSecureCookie == null) {
        cookie.setSecure(request.isSecure());
    } else {
        cookie.setSecure(useSecureCookie);
    }

---

As you see, setting the use-secure-cookie to false, doens't mean "don't flag the cookie" but "let the container decide".

If the property is set to false, instead, the remember me cookie won't be flagged as secure, and the session will survive a protocol change.

So my proposal is to set the property to whatever the user set in the config ("true if true", "false if false", not "null if false"), writing a warning in the documentation about the issues this approach brings.

Hope this makes sense.

Often the requirement is just to have the login page or payment page secured in https because the user feel more comfortable writing credentials in a "green bar" page (this is for example the requirements for many payment gateways) but the user still is ok staying in http for other pages.