## Summary
Due to the much slower rate of versioning public APIs we have decided to
remove the Elastic-Api-Version body and header information from the spec
entirely.
This also cleans up the spec when rendered on our hosted OAS docs.
Removes:
1. `Elastic-Api-Version` from the request/response bodies for all public
APIs
2. `Elastic-Api-Version` header parameter from all public APIs
Docs for internal APIs will still have this included as they always
require a version environments.
## To revewers
Important changes are all in `packages/kbn-router-to-openapispec` and
`src/core/server/integration_tests/http/oas.test.ts`, the rest is very
minor or generated/snapshotted changes.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
**Reviewers: Please test the code paths affected by this PR. See the
"Risks" section below.**
Part of work for enabling "high contrast mode" in Kibana. See
https://github.com/elastic/kibana/issues/176219.
**Background:**
Kibana will soon have a user profile setting to allow users to enable
"high contrast mode." This setting will activate a flag with
`<EuiProvider>` that causes EUI components to render with higher
contrast visual elements. Consumer plugins and packages need to be
updated selected places where `<EuiProvider>` is wrapped, to pass the
`UserProfileService` service dependency from the CoreStart contract.
**NOTE:** **EUI currently does not yet support the high-contrast mode
flag**, but support for that is expected to come in around 2 weeks.
These first PRs are simply preparing the code by wiring up the
`UserProvideService`.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [X] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [medium/high] The implementor of this change did not manually test
the affected code paths and relied on type-checking and functional tests
to drive the changes. Code owners for this PR need to manually test the
affected code paths.
- [ ] [medium] The `UserProfileService` dependency comes from the
CoreStart contract. If acquiring the service causes synchronous code to
become asynchronous, check for race conditions or errors in rendering
React components. Code owners for this PR need to manually test the
affected code paths.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1082
Selects certain Sass files to replace with styles declared with Emotion.
This PR does not include any changes that would be noticeable by
end-users. It changes the internals to use a different technology for
styling components.
~~Some `className` attributes have been kept, because they are
referenced in JS and tests.~~ Update: all classNames that are no longer
needed for styling purposes have been removed.
* If the className was needed for tests, it has been replaced with a
test-subj.
* If the className was used as a selector in production code, it has
been replaced with alternative JS.
## References
1. https://emotion.sh/docs/globals
2. https://emotion.sh/docs/best-practices
3.
https://github.com/elastic/eui/discussions/6828#discussioncomment-10825360
---------
Co-authored-by: Jatin Kathuria <jatin.kathuria@elastic.co>
## Summary
resolves https://github.com/elastic/kibana/issues/159454
Remove experimental message from saved objects import and export apis.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
We've had some questions around legacy migrations that are flagged as
deprecated in the type. This updates the typescript doc comment to
hopefully clarify that.
## Summary
Removed `security` property from `route.options` types, `security`
should exist only as a top level property.
Fixed routes with incorrect config accordingly.
## Routes Impacted
Routes with disabled authorization (impact can be considered negligible)
```
/internal/entities/managed/enablement
/internal/entities/managed/enablement
/internal/entities/managed/enablement
/internal/entities/definition
/internal/entities/definition/{id}
/internal/entities/definition/{id?}
/internal/entities/definition/{id}/_reset
/internal/entities/definition/{id}
/api/streams/_enable
/api/streams/_resync
/api/streams/{id}/_fork
/api/streams/{id}
/api/streams/{id}
/api/streams/{id}
/api/streams
```
Routes with authorization (will be backported to `8.17.0`)
```
/internal/product_doc_base/status
/internal/product_doc_base/install
/internal/product_doc_base/uninstall
```
__Fixes: https://github.com/elastic/kibana/issues/201347__
## Summary
This PR is part of the Kibana Sustainable Architecture effort.
The goal is to start categorising Kibana packages into _generic
platform_ (`group: "platform"`) vs _solution-specific_.
```
group?: 'search' | 'security' | 'observability' | 'platform'
visibility?: 'private' | 'shared'
```
Uncategorised modules are considered to be `group: 'common', visibility:
'shared'` by default.
We want to prevent code from solution A to depend on code from solution
B.
Thus, the rules are pretty simple:
* Modules can only depend on:
* Modules in the same group
* OR modules with 'shared' visibility
* Modules in `'observability', 'security', 'search'` groups are
mandatorily `visibility: "private"`.
Long term, the goal is to re-organise packages into dedicated folders,
e.g.:
```
x-pack/platform/plugins/private
x-pack/observability/packages
```
For this first wave, we have categorised packages that seem
"straightforward":
* Any packages that have:
* at least one dependant module
* all dependants belong to the same group
* Categorise all Core packages:
* `@kbn/core-...-internal` => _platform/private_
* everything else => _platform/shared_
* Categorise as _platform/shared_ those packages that:
* Have at least one dependant in the _platform_ group.
* Don't have any `devOnly: true` dependants.
### What we ask from you, as CODEOWNERS of the _package manifests_, is
that you confirm that the categorisation is correct:
* `group: "platform", visibility: "private"` if it's a package that
should only be used from platform code, not from any solution code. It
will be loaded systematically in all serverless flavors, but solution
plugins and packages won't be able to `import` from it.
* `group: "platform", visibility: "shared"` if it's a package that can
be consumed by both platform and solutions code. It will be loaded
systematically in all serverless flavors, and anybody can import / use
code from it.
* `group: "observability" | "security" | "search", visibility:
"private"` if it's a package that is intented to be used exclusively
from a given solution. It won't be accessible nor loaded from other
solutions nor platform code.
Please refer to
[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)
for any related questions.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR introduces the first internal version of the new theme
`Borealis` and ensures that:
- themes can be switched between "Amsterdam" and "Borealis"
- theme-specific Sass files are available and can be loaded with
`KBN_OPTIMIZER_THEMES=experimental`
- legacy JSON variable usage accounts for both themes
- static template styles account for both themes
## Running locally
```yml
// kibana.dev.yml or kibana.yml
uiSettings.experimental.themeSwitcherEnabled: true
```
Start kibana
```
KBN_OPTIMIZER_THEMES='v8light,v8dark,borealislight,borealisdark' yarn start
or
KBN_OPTIMIZER_THEMES=experimental yarn start
```
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: Tomasz Kajtoch <tomasz.kajtoch@elastic.co>
## Summary
Closes#192233
Just in time for Thanksgiving - a full buffet of FIPS testing fixes
Usage of non-compliant algorithms manifest as runtime errors, so it is
imperative that we attempt to run all tests possible with Kibana in FIPS
mode. However, several overrides are needed to run Kibana in FIPS mode,
resulting in setup that make it impossible to run.
## In this PR
- Enable Unit tests for FIPS pipeline
- Enable Integration Tests for FIPS pipeline
- Enable Full FTR suite for FIPS pipeline (smoke test had originally run
a subset)
- Skip tests that break with overrides
- Fix/change tests to work in FIPS mode to maximize coverage
- Examine necessity of MD5 when installing from source (TBD based Ops PR
feed back, see self review below)
- Remove md5 from es_file_client options
## Latest Successful FIPS Test Run
https://buildkite.com/elastic/kibana-fips/builds/268
---------
Co-authored-by: Brad White <Ikuni17@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Larry Gregory <larry.gregory@elastic.co>
Closes https://github.com/elastic/kibana/issues/199361
While investigating, I found that fetching DOM element with id
`app-fixed-viewport` is a common pattern. I created the hook
`useAppFixedViewport` to consolidate this logic into a single location.
The hook only performs the DOM look-up on first render and then avoids
the DOM look-up on each additional render.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/158027
## Summary
Simply dedupes references to objects if they are part of the
missing_references in the copy saved objects to SO endpoint
### Notes
- Update forEach over SOs to a regular for loop since we had a couple of
early exit scenarios
- Checks against the set for references already added to the missing
list and adds only if not present
------
**Old response: Note the duplicate references**
<img width="400" alt="Screenshot 2024-11-14 at 01 52 54"
src="https://github.com/user-attachments/assets/67078080-e39d-43b2-bf7c-7abb76866fa4">
**New response**
<img width="800" alt="Screenshot 2024-11-14 at 01 50 41"
src="https://github.com/user-attachments/assets/776db189-af8c-4522-bb03-f8efbb7cdcd9">
### Release note
Dedupe results from copy saved objects to spaces API when object
contains references to other objects.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This makes pattern schema validation stricter by avoiding unrestricted
matching, enforces realistic timezone constraints, and sets an upper
bound to the date format string.
| Characteristic | Before | After |
----|----|----|
| Optional Groups | Capturing groups for optional sections. |
Non-capturing groups for optional sections.|
|Timezone Validation | Allows any characters except }. | Restricts to
A-Za-z/_+-.|
|Clarity | More complex and verbose. | Cleaner, more restrictive, and
simpler.|
|Performance | Captures unnecessary groups. | Limits captures to needed
named groups.|
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
- Exposes the interfaces that define the format of the response of the
`/api/status` endpoint.
- Moves them from `@kbn/core-status-common-internal` to
`@kbn/core-status-common`.
- Removes the former package, as it no longer contains anything.
- Fixes some of the illegal dependencies uncovered by
https://github.com/elastic/kibana/pull/199630.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds basic support for theme switching to test experimental
themes internally. It defines a new `theme:name` setting which is
read-only (and thus hidden) by default, and needs
`uiSettings.experimental.themeSwitcherEnabled: true` config setting to
become visible. The implementation and the way the theme switcher
feature is enabled will likely change in the upcoming weeks when we iron
out the details, but the way it works right now is sufficient for
testing and that's what the immediate goal is.
Please note this PR includes mostly setup work, and no additional themes
have been added here. To make reviewing slightly easier, these will be
added separately.
The feature and settings should be undocumented for the time being and
disabled by default.
---
As you might notice, there's a new setting added despite already having
`theme:version`. We decided to introduce a new setting instead of
resurrecting an existing one for better naming and flexibility and to
reduce the risk of breaking things that might still use the old setting
value (hardcoded to `v8` at the moment). The current plan is to remove
`theme:version` in 9.0.
The theme_loader got refactored to only bundle active themes coming from
`KBN_OPTIMIZER_THEMES` (defaulting to `v8light` and `v8dark`) instead of
`ALL_THEMES` that would significantly increase bundle sizes even when
the experimental themes were not enabled. Considering there's a SASS to
CSS-in-JS migration happening right now, we don't need to worry about
Kibana bundles growing in size when a new theme is officially added.
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
- [ ] This will appear in the **Release Notes** and follow the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Clint Andrew Hall <clint.hall@elastic.co>
Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
## Summary
This PR introduces a Core API to check whether a given application has
been registered.
Plugins can use this for their _App Links_, without having to depend on
the referenced plugin(s) anymore.
This way, we can get rid of some inter-solution dependencies, and
categorise plugins more appropriately.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
> In https://github.com/elastic/kibana/issues/117241 we're surfacing
usage of APIs marked as `deprecated: true` in the Upgrade Assistant to
help users prepare for a major upgrade. While internal APIs aren't
really deprecated in the same sense we are making a breaking change by
blocking external integrations with these APIs. Since this could be
equally disruptive to users depending on these APIs it would help our
users to surface such usage in the UA too.
The `api` deprecations now have two sub types:
1. routes deprecations `options.deprecated: { … }`
2. access deprecations `options.access: 'internal'`
This PR adds the second `api` deprecation subtype. The reason i kept one
`api` deprecation type and i didnt create a new type is that they have
exactly the same registration process but are triggered by different
attributes. The `api` deprecation is fully managed by the core team
internal services and are configured by the user through the route
interface so it makes sense to keep them as one type. I also can see us
adding more subtypes to this and just piggybacking on the current flow
instead of duplicating it everytime.
**Checklist**
- [x] Create deprecation subtype
- [x] Example plugin
- [x] Surface the deprecation in UA
- [x] Api access deprecation copy (@florent-leborgne )
- [x] Update README and code annotations
- [x] Unit tests
- [x] Integration tests
Closes https://github.com/elastic/kibana/issues/194675
### Design decisions:
If the API has both route deprecation (`options.deprecated: { … }` ) AND
is an internal api `options.access: 'internal'`
The current behavior i went for in my PR:
I show this API once in the UA under the internal access deprecation.
While showing the route deprecation details if defined. This seems to
make the most sense since users should stop using this API altogether.
### Copy decisions:
@florent-leborgne wrote the copy for this deprecation subtype.
<img width="1319" alt="image"
src="https://github.com/user-attachments/assets/9a32f6d1-686a-4405-aec6-786ac5e10130">
<img width="713" alt="image"
src="https://github.com/user-attachments/assets/1304c98d-4c64-468e-a7d6-19c1193bf678">
## Testing
Run kibana locally with the test example plugin that has deprecated
routes
```
yarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples
```
The following comprehensive deprecated routes examples are registered
inside the folder:
`examples/routing_example/server/routes/deprecated_routes`
Run them in the dev console to trigger the deprecation condition so they
show up in the UA:
```
GET kbn:/api/routing_example/d/internal_deprecated_route?elasticInternalOrigin=false
GET kbn:/internal/routing_example/d/internal_only_route?elasticInternalOrigin=false
GET kbn:/internal/routing_example/d/internal_versioned_route?apiVersion=1&elasticInternalOrigin=false
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of preparing for 9.0 release we monitor test logs to surface
deprecated ES usage in Kibana. This PR ensures that all Jest integration
test are surfacing these logs by default.
fix https://github.com/elastic/kibana/issues/197721.
The route deprecation field changed from a boolean to an object, where
the object contains information that is used in deprecation issues that
the Upgrade Assistant shows.
This PR makes the necessary changes in the deprecated Saved Objects HTTP
APIs.
This PR also includes a release notes entry for the API deprecations
that was missing.
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### How to test this:
- Pull PR, run es against a trial license and start kibana as usual.
- Make a curl request to Kibana to get the config saved object:
```
curl --location 'localhost:5601/abc/api/saved_objects/config/9.0.0' \
--header 'Content-Type: application/json' \
--header 'Accept-Encoding: gzip, deflate, br' \
--header 'kbn-xsrf: kibana' \
--header 'Kbn-Version: 9.0.0' \
--header 'Authorization: Basic ZWxhc3RpYzpjaGFuZ2VtZQ=='
```
- Navigate to Upgrade Assistant and observe Kibana has at least 1
deprecation warning.
- View Kibana's warnings, you should see a warning entry for `The "GET
/api/saved_objects/{type}/{id}" route is deprecated`
- click on the deprecation and you should see more detail about the
deprecated API that's been used in the flyout:
- resolve the deprecation warning
- Kibana should continue to issue requests to the deprecated SO HTTP
APIs because these APIs have not been removed yet.
### Risk Matrix
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| End user concern from the deprecation warning that says the routes
have been deprecated | Low | Low | The APIs have been deprecated since
8.7 and recommends using public APIs instead. |
### For maintainers
- [x] This will appear in the **Release Notes** and follow the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes a regression by adding back the functionality that was originally
introduced in https://github.com/elastic/kibana/pull/162404: skipping
migrations (transform and forwardCompatibilitySchema) when the fields
option is specified
In working on this we uncovered some problem scenarios we previously
hadn't thought through (will create separate issues for these):
1. Even if we can't reliably run the transform part of migrations on a
partial document we should still run the `forwardCompatibilitySchema` so
that unknown fields from future versions are dropped.
However, we realised most teams missed the detail in our
[docs](https://github.com/elastic/kibana/blob/main/docs/developer/architecture/core/saved-objects-service.asciidoc?plain=1#L429-L457)
that call out that forwardCompatibilitySchemas shouldn't assert on data
but only drop unknown fields. This means if we would run the
forwardCompatibilitySchema today it would most often fail on partial
documents.
3. When `fields` contain an encrypted field but not all AAD fields,
encryption would fail and log an error (potentially triggering
serverless alerts).
## Summary
- [x] Add `deprecate` Type to the API Deprecations reasons.
- [x] Add a `message` optional field that is surfaced in the UA
- [x] Add IDE documentation in the autocomplete for all deprecation
fields.
- [x] Updated README and example plugin for the `deprecate` type
- [x] Update copy for `deprecate`.
Closes https://github.com/elastic/kibana/issues/197721
## Testing
Run kibana locally with the test example plugin that has deprecated
routes
```
yarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples
```
The following comprehensive deprecated routes examples are registered
inside the folder:
`examples/routing_example/server/routes/deprecated_routes`
Run them in the dev console to trigger the deprecation condition so they
show up in the UA:
```
GET kbn:/api/routing_example/d/deprecated_route
```
<img width="628" alt="image"
src="https://github.com/user-attachments/assets/3c0e1829-9a07-49bd-94a3-398514f448e2">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
Saved objects declared as `hidden` can only be accessed with a client
that explicitly includes hidden types.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
---------
Co-authored-by: Alejandro Fernández Haro <afharo@gmail.com>
Closes https://github.com/elastic/kibana/issues/194692
## Summary
Allow consumers of ESOs to explicitly opt out of the strict highly
random UID requirements while registering the ESO type
### Description
The `getValidId` method was updated to allow consumers of Encrypted
Saved Objects to explicitly opt-out of the enforced random ID
requirement.
This change is added during ESO registration - consumers can now pass a
new field to opt-out of random UIDs.
Additional changes
- Updated canSpecifyID logic:
- The canSpecifyID condition now also checks if enforceRandomId is
explicitly set to false.
This opt-out approach allows specific ESOs to bypass the random ID
enforcement without affecting the default behavior, keeping it secure by
default.
During the registration phase of the saved object, consumers can now
specify if they'd like to opt-out of the random ID
```
savedObjects.registerType({
name: TYPE_WITH_PREDICTABLE_ID,
//...
});
encryptedSavedObjects.registerType({
type: TYPE_WITH_PREDICTABLE_ID,
//...
enforceRandomId: false,
});
```
### Release notes
Improves Encrypted Saved Objects (ESO) ID validation by adding an
enforceRandomId parameter, allowing consumers to opt out of the default
random ID requirement for specific use cases.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
- [ ] This will appear in the **Release Notes** and follow the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Jeramy Soucy <jeramy.soucy@elastic.co>
## Summary
Hello, this is a follow up PR to #192234 . The previous PR added
simplistic logging to the saved objects importer. The goal now is to
enhance the logs with information on the saved objects being imported,
how they are imported, and by displaying any errors.
#### `import_saved_objects.ts`:
- Logs specific types being imported
- Logs size limit and overwrite status
- Logs Success/Fail messages
#### Changes to `saved_objects_importer.ts`:
- Passes the logger to `importSavedObjectsFromStream`
- Removes "starting import"
#### Changes to `import_saved_objects.test.ts`:
- Updates it for the new logger parameter
#### Changes to `import.test.ts`:
- Uses the mock logger provided by core, instead of using a custom one
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
- [ ] This will appear in the **Release Notes** and follow the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
## Summary
This PR aims to improve the message shown to users when Kibana can't be
started due to disabled DOM storage (#121189).
The visuals here follow the same pattern as other fatal errors (see
#186609)
The `isDomStorageDisabled` check has to be done before `CoreService`
gets instantiated because of issues described below.
Closes: #121189
## The issue
What actually happens when you disable all cookies in a browser? Aside
from cookies, the browser disables the whole DOM storage -
`localStorage` and `sessionStorage`. Trying to access those will result
in an error.
`getSessionId`3bc5e2db73/packages/core/analytics/core-analytics-browser-internal/src/get_session_id.ts (L17)
and
`isSidenavCollapsed$`3bc5e2db73/packages/core/chrome/core-chrome-browser-internal/src/chrome_service.tsx (L91)
Both of those try to access either `localStorage` or `sessionStorage`
and both of those are triggered when you create an instance of
`CoreSystem` which gets instantiated in `kbn_bootstrap`
6ef0369746/packages/core/root/core-root-browser-internal/src/kbn_bootstrap.ts (L42)
Trying to access DOM storage in `CoreSystem` will cause it to throw an
error and this means that
`FatalErrorService`6ef0369746/packages/core/fatal-errors/core-fatal-errors-browser-internal/src/fatal_errors_service.tsx (L32)
will never instantiate and the
`failure`6ef0369746/packages/core/rendering/core-rendering-server-internal/src/bootstrap/render_template.ts (L68)
function which styles the errors and makes them visible will never
trigger and all the user will see is permament `Loading Kibana` spinner.
Wrapping `getSessionId` and `isSidenavCollapsed$` in `try-catch` block
allows `FatalErrorService` to work properly, which will catch an
unhandled exception (`Detected an unhandled Promise rejection.`) with an
error about `sessionStorage` being disabled, which gets thrown by
`LicensingPlugin` (and possibly in other places). This is not an actual
solution though - this behavior would happen again if another line of
code trying to access DOM storage gets added to `CoreSystem`.
I think it would be best to handle this directly in `kbn_bootstrap.ts`
by some check like the one below:
```javascript
const isDOMStorageDisabled = () => {
try {
const key = 'kbn_bootrasrap_domStorageEnabled';
sessionStorage.setItem(key, 'true');
sessionStorage.removeItem(key);
return false;
} catch (e) {
return true;
}
};
const domStorageDisabled = isDOMStorageDisabled()
/*
...some additonal logic
*/
```
This would then require some error displaying logic that doesn't use
`FatalErrorService`.
Looking for some feedback on how to properly solve this.
## Summary
This PR adds support for explicit indication whether endpoint is
restricted to superusers only.
Moved `api/encrypted_saved_objects/_rotate_key` endpoint to the new
configuration.
__Relates: https://github.com/elastic/kibana/issues/196271__
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Release note
Introduced explicit configuration for routes that require superuser
access. Moved `api/encrypted_saved_objects/_rotate_key` endpoint to the
new configuration.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
# Summary
Adds a new API deprecations feature inside core.
This feature enabled plugin developers to mark their versioned and
unversioned public routes as deprecated.
These deprecations will be surfaced to the users through UA to help them
understand the deprecation and address it before upgrading. This PR also
surfaces these deprecations to UA.
Closes https://github.com/elastic/kibana/issues/117241
1. Core service to flag deprecated routes
2. UA code to surface and resolve deprecated routes
## Flagging a deprecated Route
### The route deprecation option
We have three types of route deprecations:
- `type: bump`: A version bump deprecation means the API has a new
version and the current version will be removed in the future in favor
of the newer version.
- `type: remove`: This API will be completely removed. You will no
longer be able to use it in the future.
- `type: migrate`: This API will be migrated to a different API and will
be removed in the future in favor of the other API.
All route deprecations expect a documentation link to help users
navigate. We might add a generic documentation link and drop this
requirement in the future but for now this is required.
### Deprecated Route Example
Full examples can be found in the `routing_example` example plugin
located in this directory:
`examples/routing_example/server/routes/deprecated_routes`
```ts
router[versioned?].get(
{
path: '/',
options: {
deprecated: {
documentationUrl: 'https://google.com',
severity: 'warning',
reason: {
type: 'bump',
newApiVersion: '2024-10-13',
},
},
},
},
async (context, req, res) => {
...
```
## Surfaced API deprecations in UA
The list of deprecated APIs will be listed inside Kibana deprecations
along with the already supported config deprecations.
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/5bece704-b80b-4397-8ba2-6235f8995e4a">
Users can click on the list item to learn more about each deprecation
and mark it as resolved
<img width="1476" alt="image"
src="https://github.com/user-attachments/assets/91c9207b-b246-482d-a5e4-21d0c61582a8">
### Marking as resolved
Users can click on mark as resolved button in the UA to hide the
deprecation from the Kiban deprecations list.
We keep track on when this button was clicked and how many times the API
has been called. If the API is called again the deprecation will
re-appear inside the list. We might add a feature in the future to
permenantly supress the API deprecation from showing in the list through
a configuration (https://github.com/elastic/kibana/issues/196089)
If the API has been marked as resolved before we show this in the flyout
message:
> The API GET /api/deprecations/ has been called 25 times. The last time
the API was called was on Monday, October 14, 2024 1:08 PM +03:00.
> The api has been called 2 times since the last time it was marked as
resolved on Monday, October 14, 2024 1:08 PM +03:00
Once marked as resolved the flyout exists and we show this to the user
until they refresh the page
<img width="1453" alt="image"
src="https://github.com/user-attachments/assets/8bb5bc8b-d1a3-478f-9489-23cfa7db6350">
## Telemetry:
We keep track of 2 new things for telemetry purposes:
1. The number of times the deprecated API has been called
2. The number of times the deprecated API has been resolved (how many
times the mark as resolved button in UA was clicked)
## Code review
- [x] Core team is expected to review the whole PR
- [ ] Docs team to review the copy and update the UA displayed texts
(title, description, and manual steps)
- [x] kibana-management team is expected to review the UA code changes
and UI
- [ ] A few teams are only required to approve this PR and update their
`deprecated: true` route param to the new deprecationInfo object we now
expect. There is an issue tracker to address those in separate PRs later
on: https://github.com/elastic/kibana/issues/196095
## Testing
Run kibana locally with the test example plugin that has deprecated
routes
```
yarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples
```
The following comprehensive deprecated routes examples are registered
inside the folder:
`examples/routing_example/server/routes/deprecated_routes`
Run them in the console to trigger the deprecation condition so they
show up in the UA:
```
# Versioned routes: Version 1 is deprecated
GET kbn:/api/routing_example/d/versioned?apiVersion=1
GET kbn:/api/routing_example/d/versioned?apiVersion=2
# Non-versioned routes
GET kbn:/api/routing_example/d/removed_route
POST kbn:/api/routing_example/d/migrated_route
{}
```
1. You can also mark as deprecated in the UA to remove the deprecation
from the list.
2. Check the telemetry response to see the reported data about the
deprecated route.
3. Calling version 2 of the API does not do anything since it is not
deprecated unlike version `1` (`GET
kbn:/api/routing_example/d/versioned?apiVersion=2`)
4. Internally you can see the deprecations counters from the dev console
by running the following:
```
GET .kibana_usage_counters/_search
{
"query": {
"bool": {
"should": [
{"match": { "usage-counter.counterType": "deprecated_api_call:total"}},
{"match": { "usage-counter.counterType": "deprecated_api_call:resolved"}},
{"match": { "usage-counter.counterType": "deprecated_api_call:marked_as_resolved"}}
]
}
}
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
