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
@bourgeoa and @Otto-AA, I've run into a fairly big problem and would appreciate your thoughts.
There are several major problems with how solid-file-client handles methods when the access role is submitter (agent has Append but not Read access).
Currently a submitter can not use our createFolder() method at all because the first thing the method does is check if the parent container exists, i.e. it tries to read, then fails before it even finds out if the container exists.
Currently a submitter will also not be able to use the default for either postFile() or createFolder(), both of which call postItem which defaults to createPath=true. In order to check if we need to create a path, we need to read, so they fail for the submitter but not the poster or writer.
We could fix this by adding flags but that gets very messy to explain. So I am thinking of leaving createFile() as it is (an alias for putFile()) and leaving createFolder() as it is - requires Read access and succeeds with noop if it pre-exists. And inventing submitFile() and submitFolder() which only require Append without Read and do straightforward POST of the item with no checking for pre-existing parents or items.
So the access section would look like this:
Viewers (Read access)
readFile
readFolder
readHead
itemExists
getItemLinks
Submitters (Append access)
submitFile
submitFolder
Posters (Append and Read access)
createFolder
Editors (Write access)
patchFile
createFile
methods that delete/copy/move, when withAcl=false option is set
Owners (Control access)
any ACL action
methods that delete/copy/move, with or without withAcl=false option
The text was updated successfully, but these errors were encountered:
I think the submitFile and submitFolder methods are a good solution for this. Maybe also add in the documentation the required permissions for each method/option.
You could also consider, that createFolder catches a 403 on the head method and then blindly tries to create a folder. But this should only be done if the options are correct for that (ie createPath: false and maybe a specfic merge option depending on how Solid merges the Append request). But I would prefer the submitFile and submitFolder options.
@bourgeoa and @Otto-AA, I've run into a fairly big problem and would appreciate your thoughts.
There are several major problems with how solid-file-client handles methods when the access role is submitter (agent has Append but not Read access).
Currently a submitter can not use our createFolder() method at all because the first thing the method does is check if the parent container exists, i.e. it tries to read, then fails before it even finds out if the container exists.
Currently a submitter will also not be able to use the default for either postFile() or createFolder(), both of which call postItem which defaults to createPath=true. In order to check if we need to create a path, we need to read, so they fail for the submitter but not the poster or writer.
We could fix this by adding flags but that gets very messy to explain. So I am thinking of leaving createFile() as it is (an alias for putFile()) and leaving createFolder() as it is - requires Read access and succeeds with noop if it pre-exists. And inventing submitFile() and submitFolder() which only require Append without Read and do straightforward POST of the item with no checking for pre-existing parents or items.
So the access section would look like this:
The text was updated successfully, but these errors were encountered: