WildFly 38 -> 39 Domain Cookie Regression?

[Peter Griffiths]

Hi,

We're upgrading from WildFly 38.0.1 to WildFly 39 but are having issues with our domain cookies. Our applications deployed to a domain server will return cookies in the form of cookiename="value.host_name:server_name". The server however isn't successfully validating these cookies in WildFly 39, thus the user remains unauthenticated. If I remove the quotes from the returned authenticated cookie and try via Postman, it works. In WildFly 38, cookies with quotes are validated successfully.

Looking into the undertow changes, I see UNDERTOW-2675 which feels like the cause of this, specifically that RFC6265 validation is now enabled by default; this RFC changes how quotes are processed in cookies.

It seems like there's a disconnect between the spec followed by the code that generates the cookies and the code that validates them for domains.

For a standalone server, I'm seeing that cookies are returned in the form of cookiename=value.host_name without the double quotes so continue to be processed OK in WildFly 39. For domains, I suspect the colon is triggering the quotes to be included in the response value in the first place. So this issue might just affect domain based installs.

Does this sound like a regression/bug or undocumented migration step? Is there an available workaround?

Regards,

Peter

[Bartosz Baranowski]

FYI: https://issues.redhat.com/browse/UNDERTOW-2685, https://issues.redhat.com/browse/UNDERTOW-2662
And possibly: https://issues.redhat.com/browse/UNDERTOW-2603

Oh. thats interesting. Im going to create test and see if it triggers in standalone undertrow/WFLY.

Anyway, just for context, this change was sort of forced by TCK compliance, it seems that implementation/APPS dont consider DQOUTE as part of value, since in general its not allowed, unless its first and last character -  cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
If this becomes problematic, it might warrant some thought in the end.

[Bartosz Baranowski]

Still, by any chance - having simple POC would be better.

[Peter Griffiths]

I've raised https://issues.redhat.com/browse/WFLY-21426 to cover this which has more information following further digging from my side. This may be a duplicate if the above covers the issue. 

It works fine for a standalone WildFly server as jboss.node.name doesn't end up containing a colon that needs quoting by the legacy cookie handling code but the crux of the issue seems to be that RFC6265 is used to parse all cookies regardless of the rfc6265-cookie-validation http listeners setting in the undertow subsystem. As this is off by default, we end up with cookie creation and validating code using different specs.

[Bartosz Baranowski]

Just to make it crystal -  rfc6265-cookie-validation option has no effect on this ?

[Peter Griffiths]

The rfc6265-cookie-validation option does have an effect here. It looks like cookie parsing is always forced into RFC6265 mode as of the last couple of undertow releases but cookie creation will look at the rfc6265-cookie-validation option to determine whether to create RFC6265 compliant cookies; so setting this option to true for all listeners in my domain does allow cookies to roundtrip successfully in WildFly 39. It works as a workaround for now.