Human readable dashboard urls #15023
Description
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