As I mentioned, it has advantages for all browsers when you don't want to use SSL (e.g. for dev purposes).

@vmuzikar That's something we can detect as well, and configure SameSite accordingly. I essentially think that we should have a single cookie and be smarter on how we set it on the server side, rather than having the two cookies.

IMHO there's no harm in having two cookies but I agree a single one is a cleaner solution as we tend to be asked about it quite a lot.

I would not try to detect the browser, though. It's quite a complex task add additional complexity (or new dependencies) just for a workaround for old Apple OS's. Apple updates their devices quite well and the affected OS's/browsers have even lower market share since when we implemented the workaround.

I can imagine we set the SameSite attribute and therefore also Secure attribute based on the HTTP/HTTPS request. Maybe we could even somehow leverage the Quarkus profiles, maybe have a little bit less strict behavior in the dev profile?

What browsers do need a workaround today? We already have dependencies on parsing the user-agent headers, so couldn't that be used relatively easily?

For the Secure that's pretty much just setting it correctly if it's a http or https request. Whether or not http is permitted or not is controlled in Quarkus by running prod or dev profiles, or explicitly enabling http, which further can be controlled by the proxy settings if it's actually https to the user, or just to the proxy. The bit setting the cookie should just set the value correctly depending if it's a http or https request though, as the rest should be enforced elsewhere.

Oh, and the sslrequired option in a realm should probably go away ;)

The workaround is needed only for older Apple browsers/OSs (notice that even 3rd party browsers on iOS/iPadOS use the engine from Safari).

We don't have much choice around Secure. When using SameSite=None, we also need to use Secure.