-
Notifications
You must be signed in to change notification settings - Fork 89
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
feat(backend): start of handling grant token rotation more gracefully #2887
Conversation
✅ Deploy Preview for brilliant-pasca-3e80ec canceled.
|
*/ | ||
exports.up = function (knex) { | ||
return knex.schema.alterTable('grants', function (table) { | ||
table.dropUnique(['authServerId', 'accessType', 'accessActions']) |
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.
Dropping the unique constraint on authServerId accessType and accessActions such that we can properly soft delete grants (see migration below)
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.
seems similar to this case? #2863 (comment)
So could we use a partial unique index (where deletedAt
is not null)?
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 don't think this unique constraint is very useful to begin with, particularly because order matters in accessActions
array, meaning [Create, Read] is different from [Read, Create], even though they are the same in terms of how we deal with them in code
grantService: Promise<GrantService> | ||
authServerService: Promise<AuthServerService> |
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.
weren't included before, adding here so we get proper types
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.
easy to miss this
getOrCreate(options: GrantOptions): Promise<Grant | GrantError> | ||
delete(id: string): Promise<Grant> |
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.
still unused
}) | ||
.whereNull('deletedAt') | ||
.andWhere('authServer.url', options.authServer) | ||
.andWhere('accessActions', '@>', options.accessActions) // all options.accessActions are a subset of saved accessActions |
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.
e.g. if we have [AccessActions.Create, AccessActions.Complete, AccessActions.Read]
and we are trying to getOrCreate a grant with [AccessActions.Create]
we will properly return it, but if one of the elements in the requested list doesnt exist, we will not be able to fetch it
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.
It looks like this differs slightly from the getGrant
which finds one that has strictly equal accessActions
. Its not quite clear what the ramifications of this will be. Can you speak to this difference? ie that its intentional, working as intended, etc.
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.
before, if we already had a grant for [Read, Create]
and then we were trying to getOrCreate a grant with [Read]
, it would fail to get the existing one, even though the existing grant has the sufficient access requirements
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 suppose we're getting rid of the getGrant
here then (in subsequent PR)? looks like its unused but if we keep it for some reason I guess we should update to filter out by deletedAt
(and maybe this same accessActions
where clause). But I imagine we can just remove it.
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.
Yes exactly, will be removing the unused methods
20c21b2
to
9dcbf78
Compare
9dcbf78
to
b21d89e
Compare
@@ -0,0 +1,19 @@ | |||
/** |
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.
nit: why not combine this migration with drop_unique_grants
?
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.
Yup, makes sense for this one, let me do that
).resolves.toEqual({ ...existingGrant, authServer }) | ||
}) | ||
|
||
test('gets existing grant (requested actions are a subset of saved actions)', async () => { |
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.
Would be necessary to create another test (or modify this one) to ensure that it can retrieve existing grants that have (Read/List)-All rights when (Read/List) is requested?
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 point, maybe during create if ReadAll/ListAll is requested, we can also manually add the corresponding Read/List as well
5a69214
to
4bff426
Compare
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
Changes proposed in this pull request
getOrCreate
anddelete
methods tobackend
grant service:getOrCreate
method:delete
methoddeletedAt
field to the grants table to allow soft deletion, as well as dropping the unique constraint onauthServerId
accessType
andaccessActions
such that we can properly soft delete problematic grantsContext
Checklist
fixes #number