Human readable dashboard urls

[stacey-gammon]

This feature proposal stems from #11338 but has some key differences (we are not suggesting editable object ids). In order to keep the conversation focused on this particular implementation, I'm starting a new issue.

Goal

Allow users to share dashboards with human readable urls.

Feature proposal: custom urls

Allow users to assign a new property to a dashboard called customUrl*. In the Share menu, instead of the UUID, use a new url with the customUrl property.

• Naming not set in stone. Suggestions welcome.

Addressing the potential issues

Background: Why human editable ids will not happen

First, some background. It's important to understand the reasons we don't want to allow human editable ids (the original proposal in #11338), so we can see which, if any, of those reasons apply to using a custom url property on dashboards.

Exposing private ids through nested relationships
One of the big security issues with allowing human assigned ids is that they would be leaked from nested parent/child relationships. For example, User A has access to Dashboard my-dash which contains Visualization my-secret-vis-id-ssn-123-45-6789. User A does not have access to the underlying visualization, but because they have access to a dashboard that contains it, they can see the visualization ids.

Conclusion: This will not be a problem with this proposal because we will continue to use the uuids for internal object references.

Guessability of objects with ids
User A creates private dashboard with ID my-dash. User B attempts to create a private dashboard with ID my-dash but receives an error because that id is already taken. Now User B knows about the existence of dashboard my-dash.

Conclusion: The custom url proposal does suffer from the same problem, but I think we can live with this and not consider is a security issue.

Broken links

User A creates public dashboard with custom url my-dash. User A shares the url. User A later changes their custom url to my-pretty-dash.

Do we need to concern ourselves with the fact that those original shared links are now broken? I say no, as long as we communicate this.

Wrong links

User A creates public dashboard with id my-dash. User A shares the url. User A later changes their custom url to my-pretty-dash. User B now comes along and creates a public dashboard with custom url my-dash. Now the old urls User A shared aren't broken but will load up User B's dashboard instead.

Do we need to concern ourselves with this use-case? I don't think it's that bad as long as it's communicated, but we have the option of not allowing these custom urls to be edited once they are assigned. Users could get around this by cloning the dashboard and assigning a new short url if they wanted to, but it would make the use case less frequent.

Race conditions

We could put this logic on the Kibana server to minimize race conditions, but someone could still give two dashboards the same custom url by modifying the .kibana index directly. I think we can live with this.

Open questions

Is this a replacement for "short urls"?

@jbudz proposes this in a comment on the original issue:

Allowing for a human readable name in the kibana url shortener layer seems like a more appropriate place for this to me. Bonus points for it being able to include url state and avoiding all the complexity of supporting titles and ids, and allowing for links to be updated transparently, and covering all kibana apps.

I don't think we should do this because:

• Short urls are never retired (Shortened url documents do not get removed from kibana index when dashboard is deleted #10450)
• We may want to deprecate them at some point Deprecate Short Urls for unsaved objects #12365
• If we implement Don't store unmodified state from a saved object in the url #14455 (don't store unmodified state in the url), then our shared view only urls will be much shorter.
• Read only users can't create short urls

If we store this as a property on the dashboard itself, it won't suffer from those issues. Potentially there would be a race condition where two dashboards end up with the same id, however. Even if we put this logic on the Kibana Server to minimize that, someone could still modify the .kibana index directly.

cc @epixa @elastic/kibana-sharing

[barnab5012]

Hi,
to fix this you can :

• export your dashboard from the management/saved Objects interface from kibana
• change the id field with the name you want in the json file
  [
  {
  "_id": "AWFRIAE56ulZCOCgOFX9",
  "_type": "dashboard",
  "_source": {
  "title": "demo",
• import your dashboard in kibana

[alexfrancoeur]

I was speaking with a user yesterday and this came up again. I don't want really want to add more input boxes to the current sharing view, but I'm wondering if it's worth adding a human readable option that generates a URL with the title as the parameter: #14760

[sgarg7]

has the idea of adding the dashboard title to the generated url been considered? eg

http://log-stg.factset.io/search/v6/app/kibana#/dashboard/d1fe7f10-f655-11e8-bcb7-292b9a197a7b/my-dashboard-title

this would let Kibana use the distinct IDs(to resolve to a distinct dashboard) and add a human readable part which will be nicer when pasting links.

[sgarg7]

Is this feature being considered? This is one of the things that is noticeably missing when moving from Kibana v3 to v6.

[ThomThomson]

Closing this because it seems like mostly users are content with the two current workarounds:

1. Create a human readable id by exporting the dashboard, manually editing the id, then re-importing it.
2. Using the title shortcut from the listing page to open a dashboard by title: dashboards#/list?title={yourtitle}. This will automatically find the dashboard with the specified title and open it.