feat: Implement grant deletion provider api #524
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| | AssignmentType::GroupProject | ||
| | AssignmentType::UserDomain | ||
| | AssignmentType::UserProject => { | ||
| db_assignment::Entity::delete_many() |
There was a problem hiding this comment.
all those fields are part of the composed PK. It is better to access it this way. Reason is that when some of the filter parameters here are wrong we may end up deleting what we should not
src/assignment/types/assignment.rs
Outdated
| #[derive(Builder, Clone, Debug, Deserialize, PartialEq, Serialize, Validate)] | ||
| #[builder(build_fn(error = "BuilderError"))] | ||
| #[builder(setter(strip_option, into))] | ||
| pub struct AssignmentRevoke { |
There was a problem hiding this comment.
please implement the From for AssignmentRevoke. I think this is going to be more comfortable to use it this way (check the assignment and pass it down to the revoke), but honestly I doubt whether we need AssignmentRevoke at all (it's same except few optional fields) and we should just use the Assignment directly?
There was a problem hiding this comment.
During implementation, I also had doubts about the necessity of AssignmentRevoke.
Then I realized that the AssignmentCreate struct is almost the same as Assignment.
So I kept the same approach for AssignmentRevoke but use Assignment directly look more clear. I will update PR accordingly
There was a problem hiding this comment.
create/update is a slightly different usecase. Usually they look very similar, but have differences (i.e. some attributes are not updatable)
|
|
||
| policy | ||
| .enforce( | ||
| "identity/project/user/role/check", |
There was a problem hiding this comment.
that is definitely wrong - check policy is pretty permissive while role assignment/revokation is intended to be used by admin/domain_manager only (similar to the grant policy). I would need to implement this policy first
konac-hamza
force-pushed
the
feature/grant-deletion
branch
2 times, most recently
from
5f9d1f0 to
0f30fea
Compare
gtema
left a comment
gtema
left a comment
There was a problem hiding this comment.
after analysis of the python keystone I see few things that need to be addressed somehow (maybe consciously not implemented):
- python code handles also the inherited deployment revocation automatically: https://opendev.org/openstack/keystone/src/branch/master/keystone/api/projects.py#L567 I do not like that personally, but the compatibility we may need to implement it the same way
- python code returns 404 when the assignment was not existing. In the other providers we currently check for affected rows and raise not found when no rows were affected (https://opendev.org/openstack/keystone/src/branch/master/keystone/api/projects.py#L567).
| ), | ||
| security( | ||
| ("X-Auth-Token" = [])), | ||
| tag="Role Assignment" |
There was a problem hiding this comment.
the openapi tag should match the one in the create assignment, it influences how endpoints are grouped
Add policy to revoke role from user
Define AssignmentNotFound error type
konac-hamza
force-pushed
the
feature/grant-deletion
branch
from
0f30fea to
ac579ad
Compare
2 participants
No description provided.