diff options
author | Stephen Finucane <stephen@that.guru> | 2019-09-21 19:06:14 +0100 |
---|---|---|
committer | Stephen Finucane <stephen@that.guru> | 2019-09-21 19:30:21 +0100 |
commit | ab35df8c33a178b3b2349c1e4727393b94f5e916 (patch) | |
tree | 0a7750e4638e31e0a42a8416a8a99f503a0809a0 /lib | |
parent | 319b6f9d750c220d47c1044246d4e97fd500c6d4 (diff) | |
download | patchwork-ab35df8c33a178b3b2349c1e4727393b94f5e916.tar patchwork-ab35df8c33a178b3b2349c1e4727393b94f5e916.tar.gz |
Fix issue with delegation of patch via REST API
There have been reports of people being unable to delegate patches to
themselves, despite being a maintainer or the project to which the patch
is associated.
The issue is a result of how we do a check for whether the user is a
maintainer of the patch's project [1]. This check is checking if a given
'User.id' is in the list of items referenced by
'Project.maintainer_project'. However, 'Project.maintainer_project' is a
backref to 'UserProfile.maintainer_projects'. This means we're comparing
'User.id' and 'UserProfile.id'. Boo.
This wasn't seen in testing since we've had a post-save callback [2] for some
time that ensures we always create a 'UserProfile' object whenever we create a
'User' object. This also means we won't have an issue on deployments initially
deployed after that post-save callback was added, a 'User' with id=N will
always have a corresponding 'UserProfile' with id=N. However, that's not true
for older deployments such as the ozlabs.org one.
[1] https://github.com/getpatchwork/patchwork/blob/89c924f9bc/patchwork/api/patch.py#L108-L111
[2] https://github.com/getpatchwork/patchwork/blob/89c924f9bc/patchwork/models.py#L204-L210
Signed-off-by: Stephen Finucane <stephen@that.guru>
Closes: #313
Reported-by: Bjorn Helgaas <helgaas@kernel.org>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions