## Summary
This PR makes `security` a required field for route registration. To
incorporate the new required filed, changes has been made:
1. **Test file updates**. A lot of the updates made in this PR were made
in tests.
2. **Versioned route security configuration**. For the versioned route
`security` config has been lifted up to the top-level definition:
Before
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
...
}, handler)
.addVersion({
version: 1,
validate: false,
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
});
```
After
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
...
}, handler)
.addVersion({
version: 1,
validate: false,
});
```
3. **Type adjustments for route wrappers**. Type changes has been made
in:
-
`x-pack/solutions/observability/plugins/infra/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/metrics_data_access/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/synthetics/server/routes/types.ts`
-
`x-pack/solutions/observability/plugins/uptime/server/legacy_uptime/routes/types.ts`
Security was made an optional field for the wrappers defined in those
files, since the default security is provided in the wrapper itself and
then passed down to the core router.
### 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
- [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)
__Closes: https://github.com/elastic/kibana/issues/215331__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
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>
