Prevent creating legacy URL conflicts #113335
Labels
enhancement
New value added to drive a business result
Feature:Saved Objects
Feature:Security/Sharing Saved Objects
Platform Security - Sharing Saved Objects feature
impact:low
Addressing this issue will have a low level of impact on the quality/strength of our product.
loe:small
Small Level of Effort
Team:Core
Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Team:Security
Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Note: this enhancement was discussed and approved via an internal RFC dated Sep 23, 2021. The executive summary of the RFC is shown below.
Problem statement
To support the Sharing Saved Objects effort (#27004), we need to regenerate many saved object IDs. That has several knock-on effects, one of which is that existing “deep link” URLs would break. We mitigated this by introducing legacy URL aliases (hereinafter “aliases”); consumers use these by using the new Saved Objects Client (SOC) resolve API to fetch a saved object (hereinafter “object”), which checks for any aliases. The resolve API has three potential outcomes, and the “conflict” outcome is more problematic than originally anticipated, which is the reason for this RFC.
The original implementation assumed that 1. The likelihood of creating a conflict scenario is extremely low, and 2. Only deep links would be impacted by encountering a “conflict” outcome as a result. However, as consumers have started changing their code to handle the breaking changes before the 8.0 release (#100489), we have discovered that the likelihood of conflict scenarios is probably greater than anticipated, and the impact will be much broader than just deep links.
Further exacerbating the impact: we intentionally did not design any user interface for managing aliases. So if a user gets into a situation where an alias conflict occurs, the only way they can fix the conflict is to use an HTTP API call to disable the alias.
Goals
The goal of this RFC is to reduce the risk of catastrophic problems and support issues for our users post-8.0 upgrade. We will do this by greatly reducing (eliminating?) the likelihood of conflict scenarios.
Proposal
To that end, this RFC proposes that we change the SOC create and bulkCreate APIs to check for problematic aliases as a preventative measure, and throw an error in those situations. This will allow Kibana to fail fast, fully preventing these conflict scenarios from occurring with organic usage of Kibana’s APIs.
The text was updated successfully, but these errors were encountered: