Add support for omitting the SameSite attribute from the session cookie

[filiphr]

The main reason for this pull request is to make it easier to disable setting the SameSite cookie in the Spring Session CookieSerializer. The default for the Spring Session is Lax. However, this does not work when using SAML with POST redirect, when the cookie is Lax, then the session cookie will not be sent when the redirect happens and thus the authentication will not work (see https://stackoverflow.com/questions/60068271/samesite-attribute-break-saml-flow/60096206#60096206 and https://www.linkedin.com/pulse/samesite-cookie-infinite-redirections-saml-digvijay-singh/).

The current workaround I have is to expose the following bean

@Bean
public DefaultCookieSerializerCustomizer disableSameSite() {
    return cookieSerializer -> cookieSerializer.setSameSite(null);
}

i.e. use the serializer to disable the cookie.

If this PR is accepted it would make it easier to configure this without the need to expose a bean by just doing

server.servlet.session.cookie.same-site=unset

[wilkinsona]

It may just be me, but UNSET makes me have to stop and think to understand what it does. I wonder if OMITTED, described as "The SameSite cookie attribute is omitted" would be clearer?

Also, could the attribute value be null? I wonder if that would simplify the logic for applying it.

[filiphr]

I wonder if OMITTED, described as "The SameSite cookie attribute is omitted" would be clearer?

You are fully right @wilkinsona. OMITTED is extremely clear. I'll look into it tomorrow.

Also, could the attribute value be null? I wonder if that would simplify the logic for applying it.

I'll check that tomorrow, I had an idea to use null, but not sure why I didn't do it in the first place.

[filiphr]

I remember now why I picked UNSET, it's because the enum org.apache.tomcat.util.http.SameSiteCookies has it. In any case OMITTED is more clear so I'll go ahead and use that

[filiphr]

Thanks for the review @wilkinsona. I've changed the name and tried using null for the attribute value.

[wilkinsona]

Thanks very much, @filiphr.

[filiphr]

Thanks for the quick integration @wilkinsona

[vpavic]

@filiphr are you sure it wasn't possible to solve the issue you're having using this combination of properties:

server.servlet.session.cookie.same-site=none
server.servlet.session.cookie.secure=true

I distinctly remember one of the teams in organization I'm working with having what looks like the same issue, and we were able to solve it this way.

It's been a while since I looked at SameSite at depth, but resources like this one still mention Lax being the default if SameSite attribute is omitted. Any behavior different from that might be browser specific and only temporary - from that standpoint I'm not sure if adding omitted as an option is a wise thing.

Also see this StackOverflow answer: https://stackoverflow.com/a/72652458/3944191

[filiphr]

I didn't try that combination @vpavic. I did try with:

server.servlet.session.cookie.same-site=none

However, that was not working. I was also reading and it was saying that if SameSite is omitted then it should be as Lax. However, when I was testing this in Chrome it was not working the same.

Also see this StackOverflow answer: https://stackoverflow.com/a/72652458/3944191

That's the StackOverflow answer I also referenced in my initial issue. That's where I found

@Bean
public DefaultCookieSerializerCustomizer disableSameSite() {
    return cookieSerializer -> cookieSerializer.setSameSite(null);
}

I was also comparing the Tomcat JSESSIONID cookie with the Spring Session SESSIONID cookie and the only difference was the Lax being there for the Spring Session cookie. When I was not using Spring Session, i.e. when I was using the default Tomcat implementation, then it worked properly. That's how I came to the conclusion that I need to omit the SameSite

[vpavic]

From what I can see your issue description links to different SO question, but that's not so important as both SO questions we linked mention the same thing as the article about SameSite I also linked to in previous comment:

Cookies with SameSite=None must also specify Secure, meaning they require a secure context.

I personally wouldn't rely on unspecified behavior that might change in future without notice.

[filiphr]

From what I can see your issue description links to different SO question, but that's not so important as both SO questions we linked mention the same thing as the article about SameSite I also linked to in previous comment:

You are right, I saw it incorrectly.

Cookies with SameSite=None must also specify Secure, meaning they require a secure context.

I personally wouldn't rely on unspecified behavior that might change in future without notice.

I am not sure that I understand. This is not about using SameSite=None. This PR was created to make sure that we can make sure that no SameSite attribute is specified on the cookie.

Reading the article you shared (https://web.dev/articles/samesite-cookies-explained) again, it indeed looks like the combination of

server.servlet.session.cookie.same-site=none
server.servlet.session.cookie.secure=true

should be enough. I'll need to test this for our scenario to validate this fully.

[vpavic]

This PR was created to make sure that we can make sure that no SameSite attribute is specified on the cookie.

If you read the article I shared, it says that Cookies without a SameSite attribute are treated as SameSite=Lax. From your description, sounds like you're relying on browser behavior that's different from that and is what I refer to as unspecified behavior that might change in the future. There's also a sentence about that at the end of SO answer I linked.