Space specific default routes

[jgough]

Kibana version: 6.5.0

Elasticsearch version: 6.5.0

Server OS version: Docker container

Browser version: Firefox, Chrome

Browser OS version: Windows

Original install method (e.g. download page, yum, from source, etc.): Docker

Describe the bug:
When server.defaultRoute is set then that route may not exist in all spaces, resulting in error messages when changing spaces. This can occur if it is a link to a Dashboard in a space other than the current one.

Steps to reproduce:
In a Kibana installation with multiple spaces and a dashboard in the default space:

1. Add a line to kibana.yml with a default route of a default space dashboard, like so:
   server.defaultRoute: /app/kibana#/dashboard/7e07e754-ef29-434a-a6b4-2a046e5f2b8f
   ^ replace the above with a dashboard GUID from the default space your installation

2. Navigate to the default space

3. Note default route works as expected

4. Navigate to a different space
   Result:

Saved object is missing
Could not locate that dashboard (id: 7e07e754-ef29-434a-a6b4-2a046e5f2b8f)

Expected behavior:
??
Suggest a change of behaviour here, possibly a configurable default route per space, possibly set through the Advanced Settings?

We would like to be able to have each Space have its own main dashboard that users get taken to when switching to the space.

[elasticmachine]

Pinging @elastic/kibana-security

[legrego]

@jgough thanks for the report! I'm switching this to an enhancement instead of bug, since server.defaultRoute is behaving as intended.

I agree with you though that the utility of this feature is diminished when used with Spaces, so I think your idea of an Advanced Setting to configure this would be more appropriate.

[passing]

it doesn't make sense to configure the setting kibana.defaultAppId globally as well, when using spaces.

[legrego]

For space-specific default routes, which would you all prefer?

Option 1: allow this to be specified on the Manage Space screen.

After Feature Controls is implemented, we could allow the default route to be specified here. If we take this approach, then the default route could only be set to a specific application (Discover, Visualize, Dashboard, etc). You wouldn't be able to specify a specific dashboard to load, for example.

Option 2: allow this to be specified via Advanced Settings.

This would behave the same as server.defaultRoute today, where you could specify a specific dashboard to load, if you wanted.

---

Option 1 would allow for a better user experience when configuring this setting, but Option 2 is more flexible/powerful.

[jgough]

Out of these I would personally prefer Option 2 - given that setting a server.defaultRoute is currently a fairly advanced setting in the config I think? Thanks!

[passing]

actually, with the preview here: #20277 I'd expect to be able to choose a default on the same screen where I can toggle the different features.

anyway, there could be an additional "Advanced Setting" to override this, giving the possibility to set a specifc dashboard as default page

[fbaligand]

Definitely for option 2!
Option 1 is not powerful enough!
As @jgough, I currently have a cutom dashboard as home page and I'm very interested for a advanced setting per space!

[legrego]

Giving this some more thought, what would you expect to happen in these scenarios?

Scenario 1

1. Create a new "Marketing" Space
2. Create dashboard in this space
3. Specify this dashboard as the "default route" for this space (however we surface this in the UI)
4. Disable/hide the Dashboard application in the Marketing Space.

This is more applicable if we allow configuration via Advanced Settings. In this case, the advanced settings will have a default route for an application that isn't available in that space anymore. Would you expect them to be taken to the standard Kibana home page instead?

Scenario 2

1. Create a new "Marketing" Space
2. Create dashboard in this space
3. Specify this dashboard as the "default route" for this space (however we surface this in the UI)
4. Configure a user role, which has access to the Marketing space, but does not have access to the Dashboard application.

Kibana will try to navigate this under-privileged user to the dashboard you created in step 2, but since they aren't authorized for the Dashboard application, the request will fail with a 404. Would you expect them to be taken to the standard Kibana home page instead?

[jgough]

@legrego My thoughts: In both those scenarios I wouldn't expect to receive any error when saving the settings, but when the user tried to access the Space I'd expect them to receive error relevant to a person accessing something that they couldn't. I think this would be simplest and in line with most other apps I've used?

So in Scenario 1: "Sorry, this app is disabled" or 404
So in Scenario 2: "You do not have permission to access this page" or 403

Probably wouldn't hurt to have a link to the Kibana home page on those.

That make sense?

[fbaligand]

I agree with @jgough answer.

[jinmu03]

Does the proposed solution has any overlap with #25735?

[kobelb]

Does the proposed solution has any overlap with #25735?

I think once the home page is improved, that it has the potential to reduce the need to specify a default route. However, I still see some utility in allowing this to be specified per space.

[kklmm]

Any ETA update on this feature?

[jinmu03]

Will plan it on our 7.5 roadmap.

[legrego]

I started investigating this a bit today, and I'm not seeing anything too unexpected yet.

We'll have to change an internal service to make this work, but I don't expect this to take a ton of effort.

One thing I haven't addressed yet is the security/feature availability aspect, which we were discussing above. We don't have a great mechanism in place currently to determine if the user will be authorized to access the configured default route, or if the default route points to a disabled feature within the space. In both of these scenarios, the user could be presented with a rather ugly error message. Ideally we would fall back to the default home page.
This might be something we can address as a side effect of #18270, but I'd need to explore that idea further to know for sure.

[fbaligand]

Great!
I would love that feature!