Some resources, such as Invites, should be openable by their public URL, but should not be visible in public indexes.
If you open the Invites collection, you should not see Invites that are created in private for specific users. But if someone opens the Invite URL, they must not get a 403.
So how do we deal with this? What changes do we need in the Authorization model?
Add a readOnOpen permission
We have a read permission. We could add a readOnOpen permission. When performing a Query (e.g. when opening a collection, or performing a fulltext search) we check for show, not readOnOpen. However, if we directly open the resource, we will check readOnOpen, which also is true when read is true.
Alternative names:
read-on-open
read-no-index
read-undiscoverable
open
hidden-read or read-hidden
Add an index permission
We add canIndex check in the back-end, which works similar to canRead and canWrite. They iterate over parents and use hierarchy to check if an item can be indexed.
Alternative names for this permission: find, search, index
Some resources, such as Invites, should be openable by their public URL, but should not be visible in public indexes.
If you open the
Invitescollection, you should not see Invites that are created in private for specific users. But if someone opens the Invite URL, they must not get a403.So how do we deal with this? What changes do we need in the Authorization model?
Add a
readOnOpenpermissionWe have a
readpermission. We could add areadOnOpenpermission. When performing a Query (e.g. when opening a collection, or performing a fulltext search) we check forshow, notreadOnOpen. However, if we directly open the resource, we will checkreadOnOpen, which also is true whenreadis true.Alternative names:
read-on-openread-no-indexread-undiscoverableopenhidden-readorread-hiddenAdd an
indexpermissionWe add
canIndexcheck in the back-end, which works similar tocanReadandcanWrite. They iterate over parents and use hierarchy to check if an item can be indexed.find,search,index