[Spaces] Remember selected space #19417
Conversation
| @@ -47,12 +49,19 @@ export const spaces = (kibana) => new kibana.Plugin({ | |||
| }; | |||
| }, | |||
| replaceInjectedVars: async function (vars, request) { | |||
| // A rather obtuse way of preventing the Kibana login/logout resources from trying to make these requests. | |||
There was a problem hiding this comment.
I'm open to suggestions here -- replaceInjectedVars is called when loading the login/logout pages, which throws visible security exceptions, because the user is not yet (or no longer) authenticated to ES.
We should only need to do the variable replacement when doing a full page load within Kibana, which I believe is constrained to loading entire apps, via the /app/* pattern
legrego
added
the
Team:Security
|
I don't think we should do this. As you alluded to, the right solution here is to lean on user preferences, which is a feature we don't have yet. However, just because we don't have the feature doesn't mean we should hack together some other feature. User preferences is a really important feature to sort out sooner rather than later. Folks don't need to use the spaces feature if they don't want the burden of selecting a space on login, and we can make this annoyance go away when we have user preferences. Specifically, this proposed feature not only leaks the existence of space ids, it implicitly leaks that one person or set of people has access to that space as well. If I see Sally log out of Kibana and walk away from some shared computer, I can now not only learn of a space I might not have access to, but I can learn that Sally does have access to it. That's doubly bad. Let's not start our authorization model in Kibana with convenience features with dubious security implications. |
|
@epixa, you raise some great points, thanks for grounding me on this. We'll defer until we have proper user preferences in place, and I'll split off the unrelated UI work into a separate PR. |
[skip ci] This PR makes the "Recently viewed" widget on the Kibana home page space-aware. The widget will only show saved objects that were viewed within the user's current space. This is accomplished by changing the way the `RecentlyAccessed` module creates its `PersistedLog`. Previously, the `PersistedLog` was using a hard-coded key, but now it is deriving its key based off of the current `basePath`, which contains the space identifier. I chose this approach because this code lies completely within OSS Kibana, and I did not want to make this module aware of the Spaces plugin. Spaces augments the `basePath` in order to function and construct space-aware links within the UI, so this ends up being transparent to consumers of `chrome.getBasePath` You'll notice that the `PersistedLog` key is partially hashed. We do this because we don't want the browser to store information about which spaces a particular user may or may not have access to (see this [earlier conversation](#19417 (comment))) ### Important Installations that have a configured `basePath` other than the default `''` will have their "Recently viewed" list cleared after upgrading to 6.5, because the basePath will become part of the `localStorage` key, when it previously wasn't. While this may _technically_ be a breaking change, I'm hoping this will be acceptable. Fixes #21961
This PR supports remembering the user's selected Space.
Motivation
Showing the Space Selector screen every time a user logs in (or accesses Kibana w/o security) is rather cumbersome and annoying. Instead, we should remember the last Space the user chose, and automatically send them there if possible.
Implementation
This feature is enabled by default, but may be disabled by setting
xpack.spaces.rememberSelectedSpacetofalsein yourkibana.yml.Kibana does not have the notion of "user profiles", so we don't have the ability to record this information server-side (i.e., in ES). Therefore, we decided during the design review meeting on May 23rd that we could store this information client-side, with the caveat that we would not remember this information if a user switched browsers or computers.
Originally, we discussed using
localStorage, which is consistent with other features in OSS Kibana. UsinglocalStorageends up being problematic for this feature, however, because the data is not immediately accessable to the Kibana server. We would have to load a page which reads the localStorage data, and then sends it to the server for processing. Instead, this PR opted to store the user's selected Space in a long-lived cookie (calledselectedSpace). Cookies are sent to the server automatically, so it eliminates an unnecessary page load and round-trip. This will also work regardless of which authentication mechanism is used.This PR includes a rewrite of the Space nav control in Kibana's main menu. It is not fully functional, but is more of a POC showing how we can use a smaller Popover instead of a Modal. It is working within the context of this PR, but will need additional work. I didn't want to blow up the scope here, so I'll submit a separate PR for that work.
Examples:
User accesses Kibana homepage for the very first time
selectedSpacecookie.User accesses Kibana homepage after previously accessing it
Kibana will attempt to automatically send the user to their last selected space. If the space is no longer available, then the Space Selector screen will be displayed instead.
Kibana will prompt the user to login, before sending them to their last selected space. If the space is no longer available, then the Space Selector screen will be displayed instead.
User switches spaces using the Spaces control in the Kibana main nav
Kibana will remember this setting, and automatically send user to this Space the next time they visit the Kibana homepage.
User has a direct link to an app, Dashboard, etc.
Kibana will allow the user to navigate to the link directly, and will not attempt to direct them to their previously selected Space.