Setting a role on the UDF vs. the User

[databrecht]

@kgoggin

But, that example assumes that all users can see pretty much everything.

That’s not entirely true of course. The app limits what you can see by using Identity() inside UDFs in combination with the encapsulation of the UDF. You could model your complete security model like that, that’s an option. It’s true that you can follow everyone and get all fweets via another way (tags), thats the nature of the app of course. An example of using roles for example to limit which user can write something (in this case, to change the password) was added on a later commit: Add profile edit · fauna-labs/fwitter@9824df4 · GitHub in a staging branch. It’s not merged yet since there is no article describing it yet. More examples that can be used for your inspiration are coming shortly via the excellent series from Pier: Getting started with FQL, Fauna’s native query language - part 1
part4 (or part5?) introduces roles with a lot of examples iirc.

@kgoggin

Can I assign it to the user document, and then assign no role to the UDF, and the UDF will inherit the user’s role? Or do I need to assign it to the UDF, and then assign I role to the User that just lets them call the UDF? If the latter, I presume something like Identity() will work on the user who’s calling the function, right?

When you assign the role to the user document and then create a token for it, the user will be able to do whatever your UDF is able to do. Which in some cases might defeat the purpose of using a UDF (in case you want to encapsulate some logic that you want to secure as one atomic unit) since a user can perfectly (if you call these from the frontend) go around the UDF and do a custom FQL query. If you are planning to call these from the backend, the only difference is that your backend key is able to do more than it would be able to if you only give the UDF access instead of the user but it comes down to the same thing.

I think it’s more clean personally (but more work) and the secure way in case you want to secure it from the frontend to create a role for your UDF and give your user access to call the UDF but as I said, if you call it from the backend, both options you present above would work.
Identity() will work on the user that is calling the function indeed. There is one caveat: Identity() will stop working in ‘membership’ of a role if you use functions, keep that in mind. We are working on making that more consistent in some way but that will not be available shortly.

Identity() can indeed be used to secure things. Since your user is bound to an identity via the token and your UDF does not take parameters that convey the identity, you could write your custom logic to access data or not straight in the UDF. Roles provide a cleaner separation of concerns (and can be used if you do not like to set up a UDF for everything).

@kgoggin

Also, I’m unsure about how to set up the predicates on my role for Collections vs. Indexes. Assuming I’ve got a few Indexes that all operate on the same Collection, can I set up the role for read on the Collection, and the Indexes will respect that? Or do I need to set a predicate on all the Indexes as well?

Providing reads on a collection does not imply reads on an index, if you are using the index you have to give read access to both the index and the collection.

From another perspective, if you would just access the index (it has values which is essentially a kind of ‘view’) you would be able to without setting read access to the collection. However, the normal read permissions filters out tuples based on the source document visibility. There is an unfiltered_read permission (undocumented? Not sure) that allows you to give access to the index values without requiring access to the underlying source document (aka the collection). The idea is that in the normal case, if you can’t read a document you should not be able to indirectly read a part of it or ascertain existence of it via an index.