Currenlty, I've implemented hierarchy based authorization. It works pretty well, but as an admin, I still can't see everything on the server that I manage. I'm not entirely sure whether this a good or bad thing. For now, at least, it forces me to find better solutions that don't require a brute allowAll / rootPermission setting, but I think at some point I'll want or need a very powerful root permission. There are a couple of ways this could be realized.
Make it a server setting - not an Atomic Data setting
Uses existing logic and settings, since servers already need a default root Agent to sign server side commits.
It won't be transparent to users that admins can see their stuff, since it won't appear in the rights authorization hierarchy. So if they check permissions / share settings, they won't see the admin.
Introduce a Server resource, set a right there
We currently only have Drives. One of the drives is at the root level, which is what is shown when opening atomicdata.dev. Users can create new Drives on that same server. The server itself, though, does not have an identifier. Maybe it should? For this case (root level rights) it kind of makes sense. The drive would no longer be a top-level resource - only servers can be top-level resources. Makes sense, from a technological standpoint. Also, we could use Server resources to find endpoints (which makes more sense then drives, and is cleaner than hard-coding paths).
We could have atomicdata.dev/server, which tells the user:
Which endpoints are supported, where they can be found
Who has access to the server (the admins, discussed above)
The version of the software running on the server (or does this decrease security? Might make is a bit easier to exploit if you know which servers are vulnerable)
Currenlty, I've implemented hierarchy based authorization. It works pretty well, but as an admin, I still can't see everything on the server that I manage. I'm not entirely sure whether this a good or bad thing. For now, at least, it forces me to find better solutions that don't require a brute
allowAll
/rootPermission
setting, but I think at some point I'll want or need a very powerfulroot
permission. There are a couple of ways this could be realized.Also, having this check can improve performance for many requests, because checking rights is expensive!
Make it a server setting - not an Atomic Data setting
Introduce a Server resource, set a right there
We currently only have
Drives
. One of the drives is at the root level, which is what is shown when openingatomicdata.dev
. Users can create new Drives on that same server. The server itself, though, does not have an identifier. Maybe it should? For this case (root level rights) it kind of makes sense. The drive would no longer be a top-level resource - only servers can be top-level resources. Makes sense, from a technological standpoint. Also, we could use Server resources to find endpoints (which makes more sense then drives, and is cleaner than hard-coding paths).We could have
atomicdata.dev/server
, which tells the user: