-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for custom alert ids #89814
Conversation
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
throw new Error( | ||
'Predefined IDs are not allowed for saved objects with encrypted attributes, unless the ID has been generated using `SavedObjectsUtils.generateId`.' | ||
throw Boom.badRequest( | ||
'Predefined IDs are not allowed for saved objects with encrypted attributes unless the ID is a UUID.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@elastic/kibana-security, I thought of making the error message more generic when it is returned by an HTTP call (ex: when creating an alert). Let me know your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with the text change. Is this something you expect end users to organically encounter in the UI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something you expect end users to organically encounter in the UI?
I don't think UI but I can see 3rd party developers/users encountering this when calling our HTTP API. I wasn't sure if mentioning SavedObjectsUtils.generateId
in the error message would make sense to them or if it was better to say any UUID? I'm good either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think your text change makes sense, and I have no problems with API consumers seeing this updated message. I just wanted to make sure the "normal" UI-based experience wouldn't encounter this 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, good to know 🙂 I can't guarantee what solutions will build on top, but I agree this shouldn't be encountered in the UIs.
@@ -323,8 +324,8 @@ function getValidId( | |||
// and not being used to get around the specified ID limitation | |||
const canSpecifyID = (overwrite && version) || SavedObjectsUtils.isRandomId(id); | |||
if (!canSpecifyID) { | |||
throw new Error( | |||
'Predefined IDs are not allowed for saved objects with encrypted attributes, unless the ID has been generated using `SavedObjectsUtils.generateId`.' | |||
throw Boom.badRequest( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than directly coupling to Boom
, can we instead throw a Saved Objects Error? If you pull this function up into the class, then you'll have access to errors
, so you can do something like:
throw this.errors.createBadRequestError('Predefined IDs are not allowed...')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, I went ahead and fixed that within c79ff9b.
throw new Error( | ||
'Predefined IDs are not allowed for saved objects with encrypted attributes, unless the ID has been generated using `SavedObjectsUtils.generateId`.' | ||
throw Boom.badRequest( | ||
'Predefined IDs are not allowed for saved objects with encrypted attributes unless the ID is a UUID.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with the text change. Is this something you expect end users to organically encounter in the UI?
I didn't see any explicit uuid validation in our code, so I assume the SO client enforces that the id is a suitable UUID? For some reason, I didn't think those were restricted to be UUIDs - I can see that if I create an index pattern, it allows you to provide an id, and then uses whatever you give it. Eg, I just created an index pattern with id |
The enforcement comes from the ESO plugin to ensure the ids are long enough for AAD and not as easy to guess. See (+ fn comment above): https://github.com/mikecote/kibana/blob/alerting/custom-ids/x-pack/plugins/encrypted_saved_objects/server/saved_objects/encrypted_saved_objects_client_wrapper.ts#L325 |
Ah, makes sense. I guess we should doc that, which makes me realize we need a doc update anyway for the new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but noted in a non-review comment that we need to update the docs, and should mention the UUID-conformance validation on that field.
@pmuellr agreed, I left a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
* Add support for custom alert ids * UUID v4 also supported * Change ESO custom id error message * Update api integration test * Use errors.createBadRequestError
Resolves #50210
In this PR, I'm adding support for custom uuid v1/v4 ids to the
AlertsClient
as well as the create HTTP API.Example of new route option:
POST /api/alerts/alert/5031f8f0-629a-11eb-b500-d1931a8e5df7
will now use5031f8f0-629a-11eb-b500-d1931a8e5df7
as the alert id and return 409 if a document with this id already exists.Notes for doc
Document the limitation of ids that can be accepted including the new optional
/{id?}
addition to the API.