-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Support space-specific default routes #44678
Conversation
This comment has been minimized.
This comment has been minimized.
💚 Build Succeeded |
I would love this feature! |
@kobelb I'm looking for feedback on the general approach here (see description above for details). If we're ok with the general approach, I'll start splitting this out and tagging for reviews as appropriate. Thanks! |
Pinging @elastic/kibana-security |
💚 Build Succeeded |
💔 Build Failed |
ACK: Will be reviewing first-thing tomorrow, time got away from me today. |
💔 Build Failed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forcing validation on consumption of the defaultRoute
uiSetting seems rather fragile. This requires us to include this logic in src/legacy/server/http/index.js
and then in X-Pack. Additionally, I think that we should be enforcing stricter validation on the uiSettings defaultRoute
than we did in the kibana.yml
. The kibana.yml
is only writable by true systems administrators, while the ui setting is writable by anyone. To protect against "open redirect" issues with the login screen's next
query-string parameter, we do the following, which ideally we'd be doing here as well:
kibana/x-pack/legacy/plugins/security/public/lib/parse_next.ts
Lines 24 to 37 in 7291e44
const { protocol, hostname, port, pathname } = parse( | |
next, | |
false /* parseQueryString */, | |
true /* slashesDenoteHost */ | |
); | |
// We should explicitly compare `protocol`, `port` and `hostname` to null to make sure these are not | |
// detected in the URL at all. For example `hostname` can be empty string for Node URL parser, but | |
// browser (because of various bwc reasons) processes URL differently (e.g. `///abc.com` - for browser | |
// hostname is `abc.com`, but for Node hostname is an empty string i.e. everything between schema (`//`) | |
// and the first slash that belongs to path. | |
if (protocol !== null || hostname !== null || port !== null) { | |
return `${basePath}/`; | |
} |
If the ui settings themselves allowed us to provide a custom validation, this would be hugely helpful. If we enforced this same validation when the values are being read, and potentially fell back to the default if it's invalid, it'd make this much easier. I explored adding server-side validation to the ui settings when implementing #15342 but it was pulled out for reasons I decided to exclude from the PR...
As a potential aside, I don't think that we should be adding a defaultRoute
method to the SpacesClient
. Before the addition of this method, the SpacesClient
is only responsible for enforcing the business logic for accessing Spaces themselves. Adding default route logic to the SpacesClient
doesn't really fit the responsibilities of this class. It also forces us to make changes so that we can pass the namespace to the uiSettingsService
, as opposed to relying on the space restrictions that the default wrapped SOC enforces.
@@ -95,6 +95,7 @@ const cspRules = (settings, log) => { | |||
|
|||
const deprecations = [ | |||
//server | |||
rename('server.defaultRoute', 'uiSettings.overrides.defaultRoute'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL about uiSettings.overrides
. I really like how you're taking advantage of this.
@@ -62,6 +62,24 @@ describe('server/config', function () { | |||
}); | |||
}); | |||
|
|||
describe('server.defaultRoute', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
Co-Authored-By: Brandon Kobel <[email protected]>
…spaces/defaultRoute
💔 Build Failed |
💚 Build Succeeded |
💔 Build Failed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is working great! The additional validation is fantastic.
💚 Build Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM.
One UX suggestion: when the server.defaultRoute
setting is specified in the kibana.yml, it might be clearer if the text in Advanced Settings explained which config field overrides this value. Not sure how much work it would be customize that message though.
I like the idea, but I do think it'd be quite a bit of work to do this correctly |
Hi, in Kibana UI (kibana version 7.6.2) have changed the defaultRoute from /app/kibana to /app/canvas |
Hi @kumar716, this isn't the appropriate forum for troubleshooting. Please start a topic on our discussion boards describing your problem, and we'll be more than happy to help you out there. It's hard to say what the problem is without seeing more information. I'd ask to double check your user's privileges (if security is enabled), and to ensure that the Canvas application hasn't been disabled in your current space. |
thanks @legrego , opening a thread in the discussion boards |
Summary
This deprecates the
server.defaultRoute
kibana.yml
setting (#46787) in favor of an Advanced Setting controllable through the UI. By making this an advanced setting, it inherently becomes space-aware, so users can specify a custom default route per space.Transition
If
server.defaultRoute
is specified inkibana.yml
, it will be mapped to theuiSettings.overrides.defaultRoute
setting. This setting tells the UI Settings Service that thedefaultRoute
setting is locked, and cannot be edited via the UI. From a migration perspective, this is functionally equivalent for users upgrading in a minor release: the setting is only controllable via theyml
file.Functionality
Users who wish to take advantage of the space-aware routes simply need to remove the
server.defaultRoute
setting from theiryml
file, if set. If unset, the advanced setting defaults to/app/kibana
, which was the previous default value forserver.defaultRoute
.If the specified default route (via advanced settings) is invalid (must be a relative path), then the "fallback" default route will be used, which is the advanced setting default of
/app/kibana
.Caveats
This PR does not address users with insufficient access. If a default route is set for a space, and the user does not have access to that route, then the page will load with an error message.
This PR does not address default routes which point to disabled features or non-existent locations. Users will be met with an error message.
I think these caveats are acceptable for now, because both of these conditions are possible today using just
server.defaultRoute
, and the security team has roadmap items to address these conditions in the future.Examples
No
server.defaultRoute
set. Default behavior:Set
server.defaultRoute
. Locked down behavior:Resolves #26126