Skip to content
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

Merged
merged 38 commits into from
Oct 2, 2019

Conversation

legrego
Copy link
Member

@legrego legrego commented Sep 3, 2019

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 in kibana.yml, it will be mapped to the uiSettings.overrides.defaultRoute setting. This setting tells the UI Settings Service that the defaultRoute 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 the yml file.

Functionality

Users who wish to take advantage of the space-aware routes simply need to remove the server.defaultRoute setting from their yml file, if set. If unset, the advanced setting defaults to /app/kibana, which was the previous default value for server.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

  1. 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.

  2. 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:

# Unset default route
# server.defaultRoute: '/app/kibana'

image

Set server.defaultRoute. Locked down behavior:

server.defaultRoute: '/app/canvas'

image

Resolves #26126

@elasticmachine

This comment has been minimized.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@fbaligand
Copy link
Contributor

I would love this feature!

@legrego
Copy link
Member Author

legrego commented Sep 4, 2019

@kobelb
@elastic/kibana-platform

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!

@legrego legrego added discuss Feature:Security/Spaces Platform Security - Spaces feature Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v7.5.0 v8.0.0 labels Sep 4, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💔 Build Failed

@kobelb
Copy link
Contributor

kobelb commented Sep 11, 2019

ACK: Will be reviewing first-thing tomorrow, time got away from me today.

@elasticmachine
Copy link
Contributor

💔 Build Failed

Copy link
Contributor

@kobelb kobelb left a 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:

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'),
Copy link
Contributor

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', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💔 Build Failed

@legrego legrego mentioned this pull request Oct 1, 2019
7 tasks
Copy link
Contributor

@kobelb kobelb left a 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.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@legrego legrego requested a review from joshdover October 1, 2019 21:32
Copy link
Contributor

@joshdover joshdover left a 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.

@legrego
Copy link
Member Author

legrego commented Oct 2, 2019

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

@kumar716
Copy link

kumar716 commented Mar 9, 2022

Hi, in Kibana UI (kibana version 7.6.2) have changed the defaultRoute from /app/kibana to /app/canvas
-- but accessing the url via https://host:port/app/canvas is resulting in this message on the screen "Application Not Found
No application was found at this URL. Try going back or choosing an app from the menu."
-- & while accessing url via https://host:port I get the proper landing page but the url is defaulted to https://host:port/app/kibana instead of https://host:port/app/canvas...
-> Can you please help me achieve this path/Route/uri modification to /app/canvas as this is our requirement, how to achieve this Please

@legrego
Copy link
Member Author

legrego commented Mar 9, 2022

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.

@kumar716
Copy link

kumar716 commented Mar 9, 2022

thanks @legrego , opening a thread in the discussion boards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Security/Spaces Platform Security - Spaces feature release_note:deprecation release_note:enhancement Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v7.5.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Space specific default routes
6 participants