You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
is the main (only) method we can get user secrets from the database. If the key_id exists, we ensure the user_id matches and key type (if present inside filter) matches the values in the database. We consider it an error if the user or key type is incorrect. We would like to create an audit event if this happens, as this seems important from a security point of view.
There are a couple pieces here to figure out and design:
Should the get_user_secret function itself generate the audit events or should this be up to the caller based on the return value of this function? The former is easier to implement but we would have to pass in the request ID to this function.
It is unclear if our current AuditEvent type is fit for creating this type of events. How exactly should we report a mismatch as an audit event? Currently our audit events only allow us to specify what happened via a ClientAction field or EventStatus. Should we make a new variant under ClientAction? that doesn't quite fit what we want. Or we could add new variants to the EventStatus to report either UsernameMismatch or KeyTypeMismatch? Last option is to re-design our audit event type, as I anticipate this is not the last time we will want to encode events on the server as audit events.
The text was updated successfully, but these errors were encountered:
Our
get_user_secret
function:is the main (only) method we can get user secrets from the database. If the
key_id
exists, we ensure theuser_id
matches and key type (if present insidefilter
) matches the values in the database. We consider it an error if the user or key type is incorrect. We would like to create an audit event if this happens, as this seems important from a security point of view.There are a couple pieces here to figure out and design:
get_user_secret
function itself generate the audit events or should this be up to the caller based on the return value of this function? The former is easier to implement but we would have to pass in the request ID to this function.AuditEvent
type is fit for creating this type of events. How exactly should we report a mismatch as an audit event? Currently our audit events only allow us to specify what happened via aClientAction
field orEventStatus
. Should we make a new variant underClientAction
? that doesn't quite fit what we want. Or we could add new variants to theEventStatus
to report eitherUsernameMismatch
orKeyTypeMismatch
? Last option is to re-design our audit event type, as I anticipate this is not the last time we will want to encode events on the server as audit events.The text was updated successfully, but these errors were encountered: