You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now our testing for permissions consists of two methods: a full check on all urls in test_urls_auth.py, or ad-hoc permissions tests scattered around our testing files. The problem with the former is that it only checks for authentication, ensuring endpoints require a valid login.gov account before providing access. It doesn't check specific access controls (permission restrictions) beyond that. The latter, on the other hand, is not systemic in any way and likely has large gaps.
This is an opportunity to improve our test coverage. We should implement a system where all endpoints are checked for access controls against some central source of truth. This should ideally be done in a way that will automatically cover any new urls we create, so that tests cannot pass if access controls on all urls don't match the source of truth.
Acceptance criteria
New unit tests are added that check that the correct permissions are required to access all django admin, including analytics, pages mentioned in urls.py and the "domain/" pages
all urls in urls.py are checked
a developer would get python-test errors if a new url is added whose permissions are not explicitly set in the unit test(s) (such as a central source of truth used by the unit tests)
Limiting scope to the admin pages (including analytics) and domain pages due to the sheer number of urls we have. Follow on tickets would build on this for the other pages
Additional context
The approach chosen should be expandable in the future as we will build on this.
Ideally, we would have a central source of truth is created where all access controls for all urls are listed in some format. New test(s)would then check access controls against the central source of truth. Then, if If a url is not found in the source of truth the test should fail, to enforce that all urls should be in the source of truth.
Our recent permissions audit should provide an excellent starting point for the central source of truth. Once that is created in some machine-readable format, it should be possible to loop through urls.py and check every view there against the source of truth.
Issue description
Right now our testing for permissions consists of two methods: a full check on all urls in test_urls_auth.py, or ad-hoc permissions tests scattered around our testing files. The problem with the former is that it only checks for authentication, ensuring endpoints require a valid login.gov account before providing access. It doesn't check specific access controls (permission restrictions) beyond that. The latter, on the other hand, is not systemic in any way and likely has large gaps.
This is an opportunity to improve our test coverage. We should implement a system where all endpoints are checked for access controls against some central source of truth. This should ideally be done in a way that will automatically cover any new urls we create, so that tests cannot pass if access controls on all urls don't match the source of truth.
Acceptance criteria
Limiting scope to the admin pages (including analytics) and domain pages due to the sheer number of urls we have. Follow on tickets would build on this for the other pages
Additional context
The approach chosen should be expandable in the future as we will build on this.
Ideally, we would have a central source of truth is created where all access controls for all urls are listed in some format. New test(s)would then check access controls against the central source of truth. Then, if If a url is not found in the source of truth the test should fail, to enforce that all urls should be in the source of truth.
Our recent permissions audit should provide an excellent starting point for the central source of truth. Once that is created in some machine-readable format, it should be possible to loop through urls.py and check every view there against the source of truth.
link to slack thread
Links to other issues
No response
The text was updated successfully, but these errors were encountered: