Is it possible to have access rules in Fluid Framework?

user_964780 0
Viewed 127

Fluid looks really nice if all collaborators are equal (allowed to change the same resources), but what I don't understand is how the server can prevent certain actions for certain users. As much of the logic as possible is on the client-side right? Maybe I haven't searched good enough, but I couldn't find a resource or readme that explained that part.

Example:
User A can edit the whole markdown document.
User B can edit the whole markdown document.
Both users can lock paragraphs they've created to be read-only, which only they can unlock again.

On the Fluid FAQ it states the following:

Turn-based games?
DDSes can be used to distribute state for games, including whose turn it is. It’s up to the client to enforce the rules of a game so there may be some interesting problems to solve around preventing cheating but the Fluid team has already prototyped several games.

If there is no solution for this problem, please let me know where I should start would I fix this myself. For a fun hobby project, I'm in the middle of deciding to build something new or to use fluid (which can save me a lot of work).

fluid-framework security
1 Answers

Right now, Fluid doesn't have the concept of Access Control, but we could include some related features as DDS features, we could implement some features as server-hosted Fluid Bot filters, and we could implement basic ACLs at the server layer as Storage ACLs.

As DDS Features

I wrote the "OwnedMap DDS" to show this concept, where users reject invalid changes from other users. This could be extended to include your "paragraph lock" concept, but I'm not sure it's rigorously secure.

I think it'd be interesting to build a library of "OwnedDDS" or DDS with filter methods on them to prevent invalid changes".

server-hosted Fluid Bot filters

Another option is to have a server side client, so a non-user client that joins the session that is not a malicious actor. This Bot could validate that changes are legitimate and then "consent" to the changes. This breaks some optimistic insert constraints, but would add more security and is more rigorously secure.

With this approach, you may still need to modify DDSs so that they're consensus based instead of optimistic, but the only consensus would be that the Bot agrees the change is valid.

Storage & Server level ACLs

You could imagine modifications to the routerlicious reference service where you need a user login to access specific containers. This is not as find grained as your request, but would clearly work!

user_96997820
Related