zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-05-15 00:57:02 +02:00
Code Issues Projects Releases Packages Wiki Activity

Review feedback: updated developer documentation

Browse source
This commit is contained in:
Neil Martinsen-Burrell 2023-06-09 14:17:55 -05:00
parent 45f317d113
commit 2fc070e6c5
No known key found for this signature in database
GPG key ID: 6A3C818CC10D0184
2 changed files with 20 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

22
docs/developer/user-permissions.md
View file

@ -22,12 +22,22 @@ role or set of permissions that they have. We use a `UserDomainRole`
## Permission decorator ## Permission decorator
The Django objects that need to be permission controlled are various views. The Django objects that need to be permission controlled are various views.
For that purpose, we add a very simple permission mixin For that purpose, we have a View subclass to enforce user permissions on a
[`DomainPermission`](../../src/registrar/views/utility/mixins.py) that can be domain called
added to a view to require that (a) there is a logged-in user and (b) that the [`DomainPermissionView`](../../src/registrar/views/utility/permission_views.py)
logged in user has a role that permits access to that view. This mixin is the that can be added to a view to require that (a) there is a logged-in user and
place where the details of the permissions are enforced. It can allow a view (b) that the logged in user has a role that permits access to that view. This
to load, or deny access with various status codes, e.g. "403 Forbidden". mixin is the place where the details of the permissions are enforced. It can
allow a view to load, or deny access with various status codes, e.g. "403
Forbidden".
In addition, we now require all of our application views to have a logged-in
user by using a Django middleware that makes every request "login required".
This is slightly belt-and-suspenders because our permissions view also checks
that the request includes a logged in user, but it avoids accidentally creating
content that is publicly available by accident. We can specifically mark a view
as "not login required" if we do need to have publicly accessible content (such
as health checks used by our platform).
## Adding roles ## Adding roles

4
src/zap.conf
View file

@ -87,6 +87,10 @@
10062 FAIL (PII Disclosure - Passive/beta) 10062 FAIL (PII Disclosure - Passive/beta)
10095 FAIL (Backup File Disclosure - Active/beta) 10095 FAIL (Backup File Disclosure - Active/beta)
10096 FAIL (Timestamp Disclosure - Passive/release) 10096 FAIL (Timestamp Disclosure - Passive/release)
# Our sortable table of domains uses timestamps as sort keys so this appears as
# a false-positive to the OWASP scanner
10096 OUTOFSCOPE http://app:8080
10096 OUTOFSCOPE http://app:8080/
10097 FAIL (Hash Disclosure - Passive/beta) 10097 FAIL (Hash Disclosure - Passive/beta)
10098 FAIL (Cross-Domain Misconfiguration - Passive/release) 10098 FAIL (Cross-Domain Misconfiguration - Passive/release)
10104 FAIL (User Agent Fuzzer - Active/beta) 10104 FAIL (User Agent Fuzzer - Active/beta)