There are certain scenarios for Search with Permissions that can't be solved with ListObjects or by running check for every result from a local DB query. In that document we describe an "Option 2" but we don't provide the specific steps on how to solve it.
For example, consider the following model:
model
schema 1.1
type user
type group
relations
define member : [user]
type document
relations
define owner : [user]
define viewer : [user, group#member] or owner
If there are millions of documents, retrieving from OpenFGA the documents the user can view would not be a feasible solution. OpenFGA can't return the IDs ordered/filtered by the criteria the application needs, so even of we could paginate over the list, you won't be able to properly present the data to the user. The pages won't be ordered or filtered in the way you want.
We think OpenFGA can help you generate a document_viewers table with a user_id, document_id schema, that has a record for every user/document. You can join that table with your table when resolving queries.
This demo of the March community meeting shows a possible approach we can take. We are exploring other paths to help you generate this table.
However, if you have 1 million documents in the system that the members of the 'everyone' group can view, each time you add a member to the 'everyone' group, you need to add 1 million records to the document_viewers table, which might not be feasible.
Another approach we are exploring, and that can be combined with the solution described in the community meeting, is to provide the AST of a query your can run in your application, on your own tables.
There are certain scenarios for Search with Permissions that can't be solved with ListObjects or by running
checkfor every result from a local DB query. In that document we describe an "Option 2" but we don't provide the specific steps on how to solve it.For example, consider the following model:
If there are millions of documents, retrieving from OpenFGA the documents the user can view would not be a feasible solution. OpenFGA can't return the IDs ordered/filtered by the criteria the application needs, so even of we could paginate over the list, you won't be able to properly present the data to the user. The pages won't be ordered or filtered in the way you want.
We think OpenFGA can help you generate a
document_viewerstable with auser_id, document_idschema, that has a record for every user/document. You can join that table with your table when resolving queries.This demo of the March community meeting shows a possible approach we can take. We are exploring other paths to help you generate this table.
However, if you have 1 million documents in the system that the members of the 'everyone' group can view, each time you add a member to the 'everyone' group, you need to add 1 million records to the
document_viewerstable, which might not be feasible.Another approach we are exploring, and that can be combined with the solution described in the community meeting, is to provide the AST of a query your can run in your application, on your own tables.