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
After some discussion we came up with the following:
Container, folder and file creation will result in an authz hierarchy tree, that mimics the filesystem structure. For example, a container X owns some folders (absolute paths), that each own some files. File creation API should adapt, so that no extra reconstructing job (like authz reconstruct indexes) is needed for projects that already use storage authorization
Upon file creation, we should check if user has permission for 'edit' action in given scope and also in given container and/or folder. To check the latter correctly, we should either:
a) constrict users to create files only in shallow file paths
b) find if the nested path is already stored in conduit and check access, otherwise find each subfolder and check access (I think we will come up with a better version of this solution)
Default container should not be owned
We should remove container creation logic from Client API
We will create personal user folders and use them as default when folder is not given in file creation
Checklist
Suggestion
The storage module currently implements authorization optionally, and only for files. It needs to be expanded providing authorization in:
The text was updated successfully, but these errors were encountered: