Deprecate Short Urls for unsaved objects

[stacey-gammon]

We have an issue with our short url service in that they are kept around perpetually with no easy way to delete them (more details here: #10450). Short urls are stored in the .kibana index with only the original url and the short url - no connection to the original saved object (if indeed it was generated from a saved object).

If we want to continue to allow users to create short urls from unsaved objects, then I don't see any way to handle this situation, short of a new management screen to give control to the users for which urls to delete.

The other option is to stop allowing users to create short urls for unsaved objects. We have two ways to implement this:

1. Remove short urls entirely, since the url for sharing saved objects with all saved edits, is already short enough.

2. Allow sharing unsaved edits to a saved object, but the object will have to have an id associated with it.

I'm in favor of 2. because we'll have a way to cleaning up urls when their associated object is deleted, and I think 1 is too limiting (just see how many +1s there were on #1553)

There are still some cons with this route:

• long urls can still be used to share unsaved urls, but users run into issues with sharing long urls:
  • Use more aggressive URL encoding #2815 Less aggresive url encoding means some applications can't interpret these urls.
  • IE url length limitations restricts users from opening long urls in IE, so there would no longer be a way around this by using short urls (for urls not associated with a saved object).
• read only users won't be able to use short urls at all.

What this means for 6.0

If we decide to go the route of requiring short urls to be associated with a saved object, we need to do a couple things in 6.0:

• Add a deprecation warning when a short url that is not associated with an object is used.
• Adjust the kibana index to store the id of the object associated with the short url.
• Adjust the UI to restrict short url generation when the object is unsaved.
• Continue to support existing urls until some time in the future.

In addition we may want to see if we can fix #2815 with better encoding so sharing long urls is more stable.

cc @uboness @alexfrancoeur @kobelb @nreese

[stacey-gammon]

Summary of the meeting:

We cannot remove short url support without one of the following things happening:

1. Dropping support for IE11 which is not an option right now
2. Changing the way we store state in the URL.

We decided on the later since this will solve all our problems and allow us to remove short url support. This will be a significant amount of work however, so for the short term, we are going to let short urls continue their reign, with the only way to delete or manage them being directly through the elasticsearch api.

A new issue for removing the state we store in the url has been filed here: #12369 which is a blocker for this issue

cc @epixa

[stacey-gammon]

This is not going to happen any time soon, if ever. Closing.