Enable Serverless API protections dynamically #97079
Conversation
This commit changes the method for enabling Serverless API protections (see elastic#93607) from a system property to a runtime property. Within this project there is no external way to configure this property - it must be controlled by a plugin - but the RestController has been changed to dynamically adapt to a change in that property.
tvernum
added
>enhancement
:Core/Infra/REST API
|
Hi @tvernum, I've created a changelog YAML for you. |
|
This is draft (no tests, and probably breaks existing tests) but it works in local testing, so I wanted to put it up for a first pass review in case someone hates the direction. |
|
This PR is ready for review now |
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
There was a problem hiding this comment.
LGTM
As commented on the other PR, there is a way to register a setting update listener without registering the setting itself. This would be my personal choice of implementation. But since the whole thing is temporary, the difference likely does not really matter.
|
|
||
| package org.elasticsearch.rest; | ||
|
|
||
| public class ServerlessApiProtections { |
There was a problem hiding this comment.
Nit: Should we just call it ApiProtections?
There was a problem hiding this comment.
I don't mind. I made it explicit because the annotation is @ServerlessScope, so it's not intended to ever be a generic API protections facility.
I'm going to leave it as-is, mostly because I don't like the idea of having a setting in server that isn't registered. |
|
@elasticsearchmachine run elasticsearch-ci/part-3 please. |
This commit changes the method for enabling Serverless API protections (see #93607) from a system property to a runtime property.
Within this project there is no external way to configure this property - it must be controlled by a plugin - but the RestController has been changed to dynamically adapt to a change in that property.