Another option would be to just check the is_superuser attribute of the user.
In this way we'd have a safety-check that if deploy the fractal-data app and link it to an existing fractal-server instance we'd not automatically expose folders to all users.
What I propose is the following:
Deny authorization for any user who is not a superuser.
Deny authorization for any path which is not relative to a known folder. E.g. we can say that all relevant zarrs will be in ~/zarrs_for_testing/, and that's were we'll place our zarrs (directly or via mount points).
Side note: if/when we implement teams or roles in fractal-server (e.g. one team per cluster service user), that could become the first version of an authorization filter.
In https://github.com/fractal-analytics-platform/fractal-data/pull/3, I (provisionally) removed the authorization mechanism - to make testing easier.
Another option would be to just check the
is_superuserattribute of the user. In this way we'd have a safety-check that if deploy the fractal-data app and link it to an existing fractal-server instance we'd not automatically expose folders to all users.What I propose is the following:
~/zarrs_for_testing/, and that's were we'll place our zarrs (directly or via mount points).Side note: if/when we implement teams or roles in fractal-server (e.g. one team per cluster service user), that could become the first version of an authorization filter.