Multiple cookies and infinite redirects

[kobelb]

Problem

We currently have an infinite redirect when Kibana goes from being hosted on no base-path to being hosted on a base-path. We end up with multiple sid cookies, one with the path set to /${basePath} and one with the path set to /. When we see this, we'll respond with a 401 and try to clear the cookie at /${basePath} but we leave behind the one at /. The user logs back in, and the same situation repeats itself, it's glorious.

A similar situation occurs when we go from hosting Kibana at https to being hosted at http. We end up with multiple sid cookies being set, one with the secure flag set and one without the secure flag being set. A similar situation to the above then manifests itself.

Potential Solution

What if we were to change the name of the cookie which we use for the session based on whether it was hosted at a basePath and secure? Something like sid-${basePath ? '0' : '1' }-${secure ? '0' : '1'} with a better scheme. That way we wouldn't be trying to use cookies for auth which we can't use.

[elasticmachine]

Pinging @elastic/kibana-security

[legrego]

I'm not opposed to a suffix on the cookie name. For the sake of discussion, I'll pose another potential solution:

What if we were to encode these attributes as part of the session data? When we see multiple sessions on a single request, the server should be smart enough to determine which one of them satisfies the server's current configuration.

I know it's not part of our public API of any sort, but I'm worried that users with custom setups will expect cookies to be a specific name that they've already configured via kibana.yml. Upgrading Kibana would in turn break their setups, and they'd have to know what the expected cookie suffix is going to be. For a contrived example, a reverse-proxy might be configured to allow specific cookies through, while denying others.

[kobelb]

What if we were to encode these attributes as part of the session data? When we see multiple sessions on a single request, the server should be smart enough to determine which one of them satisfies the server's current configuration.

I like it better, I can't think of any downsides to this approach either. We'll likely have to ensure it works properly with all of the various scenarios of http -> https, https -> http, etc.

[azasypkin]

What if we were to encode these attributes as part of the session data? When we see multiple sessions on a single request, the server should be smart enough to determine which one of them satisfies the server's current configuration.

++, also it's kind of in line with the provider part of the session data (e.g. we already analyze provider and clear cookie if it isn't available anymore for some reason).

[kobelb]

Removing the discuss tag since it seems we have an approach we should pursue