-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple cookies and infinite redirects #36825
Comments
Pinging @elastic/kibana-security |
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 |
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. |
++, also it's kind of in line with the |
Removing the discuss tag since it seems we have an approach we should pursue |
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 thepath
set to/${basePath}
and one with thepath
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 thesecure
flag set and one without thesecure
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.The text was updated successfully, but these errors were encountered: