Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I set out to convert
test_permissions.py
to pytest format, and to remove its dependency on our legacy JSON test fixtures, swapping in our pytest test fixtures instead.I did that, but it got a little more complicated 😅.
This test module loads (nearly) every page in the app, as all our different kinds of users, and makes sure people have permission to see everything they should be able to see, and can't see anything else.
But, it turns out that the original code doesn't test every combination: it does not test what happens if registrar users visit pages associated with other registrars.
Switching to the pytest fixtures called that to attention: the original fixtures were carefully crafted so that the sponsorship and org being tested were associated with the same registrar, whereas the pytest fixtures don't do this by default. Instead of more carefully invoking the pytest fixtures to recreate that situation, I instead decided to, instead, include the missing combinations.
That revealed that we have been handling a lack of permission differently, on different pages here. While it's true that sometimes, if a user should not have access to a particular page, you might want to return 404 instead of 403 to prevent them from discovered something they shouldn't know... in this case, we were returning 403 when a user categorically couldn't see a page (for instance, if a regular user tried to visit a registrar-only page), but at the same time, we were sometimes returning 404 when a user should visit some pages of a particular kind, but not others (for instance, if a registrar user tried to view a page associated with a different registrar)... but not always.
This PR makes the behavior of all the pages consistent: 404 means something legitimately does not exist, 403 means you aren't allowed to see it. I did that because... that was the easiest way to get the tests passing lol!!! If we want something different or more nuanced, I propose we handle it in a separate PR.