Closed maxachis closed 2 months ago
@josh-chamberlain One interesting wrinkle in all of this is how to design our endpoints when the view permissions between standard and non-standard (i.e. admin or otherwise elevated) users differ for a column.
For example, consider the following column as described in #390:
COLUMN | STANDARD | OWNER | ADMIN |
---|---|---|---|
archive_reason | VIEW | EDIT |
The owner can view it, the admin can view and edit it, and the standard user can do neither.
Here's the issue as it relates to our current design of endpoints:
Basic
authentication can be accessed by any user with their API key, and is intended for endpoints that don't require elevated permissions.Bearer
authentication requires a short-lived JWT, and is used to check to see if users have elevated permissions that enable them to access this endpoint.GET
methods of previous endpoints, such as /agencies
, these are designed to be viewable by standard users, and require only basic auth.So what should these other endpoints, where we're returning data from a table and where the viewable columns differ based on user, look like? There's a few options as I see it:
Basic
endpoint that can look up permissions. Bearer
and look up permissions that wayBearer
and Basic
, where the authorization provided impacts whether it has standard permissions (Basic
) or whether it should be evaluated for elevated permissions (Bearer
).I think 4 makes the most sense, but I wanted to present all options as I see them.
@maxachis ooh, this is a good point + I probably should have seen it coming! Yes, with # 4 you articulated it perfectly. I think the authorization provided goes through the permission checking machine, and impacts what happens (which fields you get back, what actions you can take). You could provide both bearer and basic auth, but if your account has no permissions, you don't get the good stuff.
A number of our tables have columns and views where view and edit access varies depending on the user and their permissions.
Broadly speaking, we have
STANDARD
andADMIN
users, who have eitherEDIT
orVIEW
permissions for each column.Currently, in code we determine who can do what through a number of arrays of varying permutations, which list columns that can or cannot be used. Our current means of organizing them is confusing:
Instead of creating more permutations of arrays, I propose that for each table and view, we have a tabular structure where:
STANDARD
andADMIN
users.While it takes more effort in the short-term than the array pattern, in the long term it will pose less cumbersome and scale more effectively.
This is partly a refactoring job, and partly about making the development of issues such as #390, which involve varying levels of visibility and permissions, more manageable. For the moment, I'll put aside refactoring existing code.
The other component,
check_edit_values_permitted
, will take a dictionary of key-value "edit pairs" (where the key represents the column and the value represents the new value) and checks to see that all values are allowable for editing. This is designed to catch and rejectPUT
requests that include edit values we do not allow that type of user to edit.Implementation Steps
get_permitted_columns
to incorporate thischeck_edit_values_permitted
Reference
https://docs.pdap.io/activities/data-dictionaries/hidden-properties