-
Notifications
You must be signed in to change notification settings - Fork 146
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
Exit staff mode after permission revocation #2355
base: main
Are you sure you want to change the base?
Conversation
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.
Nice 👍
Please check the formatting
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.
naturally, a test would be nice : )
Thanks!
evap/staff/staff_mode.py
Outdated
@@ -52,6 +52,9 @@ def is_in_staff_mode(request): | |||
|
|||
|
|||
def update_staff_mode(request): | |||
if not request.user.has_staff_permission: | |||
exit_staff_mode(request) | |||
return | |||
assert request.user.has_staff_permission |
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 this assertion is no longer needed
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'd move it up to line 33, where I think it would still add value.
The call graphs we can get now are a bit wonky. We can have
enter_staff_mode
-> update_staff_mode
-> finds out that not request.user.has_staff_permission
-> exit_staff_mode
and returns without exception, which is probably never what the initial caller intended?
It seems to me that update_staff_mode
was about "update the timestamp in the session to now()" in the past, now it has changed semantics. Could use a little clean up in general, I think.
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 moved the assertion to line 33
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 agree that, while it's not super urgent, the names could be improved. In general, enter_staff_mode
seems unneeded since #1587. The current update_staff_mode
is more of a try_entering_or_refreshing_staff_mode
. I don't have a strong opinion, but having a "try to enter, but we will check whether you are allowed" as the only way to enter staff mode seems fair to me. Maybe the enter_staff_mode
view should check that entering worked?
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.
Blocking for missing test, since this is authorization logic and we discovered a code path in the issue that we considered not to happen naturally before. Feel free to assign the PR to me if you want me to write the test.
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.
Very cool, thanks! Could you change the title to something more descriptive? The issue number doesn't need to appear, we will always be able to find it through the PR number, which will be automatically included once we merge :)
if not request.user.has_staff_permission: | ||
exit_staff_mode(request) | ||
return |
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.
@richardebeling @Kakadus Should we log something here?
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 both adding and not adding logging.
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 we can only manage one of the two
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.
If you both don't care, I would prefer if we added a small info-level log like "user {} tried to update staff mode session without permission" @ybrnr
Edit: nevermind, @richardebeling convinced me against this afterall
@ybrnr How about "Exit staff mode after permission revocation"? |
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.
Blocking for #2355 (comment)
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.
Nothing to see here
fix #2205