Permission denied when run query as a specific document in fuana shell

Help
,
1

Hello,

I created this UDF getLadder and had given it the Admin role, then I assigned the call privilege for loggedIn role in order to call the getLadder function.
When I call the function getLadder within fauna shell as a loggedIn role, it returns the result perfectly fine, however, if I try to run query as a specific document (a user that has the loggedIn role) , I always ended up having the permission denied error message.
Could anyone help me to figure out what did I do wrong?

Thanks in advance!

2

When I call the function getLadder within fauna shell as a loggedIn role

Can you elaborate on what this means? The wording implies that you made the role, itself, an identity document. That’s certainly possible, but quite unusual. Or did you mean that you used the “Run As” feature in the Dashboard Shell? (fauna shell is the Node.js-based CLI, and it doesn’t have “Run As”)

Can you share the loggedIn role refinition? Get(Role('loggedIn'))

Can you share the process you used to acquire the secret for the user that is a member of the loggedIn role?

3

Sorry about the wording, I meant that I used the Run As feature in the Dashboard shell :slight_smile:

When I run as loggedIn role, there’s no problem getting the result, but if I run as specify a document from users collection (given an user id), I’ve only got permission denied, "Insufficient privileges to perform the action.".

here’s the definition of loggedIn role

  ref: Role("loggedin"),
  ts: 1652971953190000,
  name: "loggedin",
  privileges: [
    {
      resource: Collection("notions"),
      actions: {
        read: true
      }
    },
....
    {
      resource: Ref(Ref("functions"), "getLadder"),
      actions: {
        call: true
      }
    },
....
  ],
  membership: [
    {
      resource: Collection("users"),
      predicate: Query(
        Lambda(
          "ref",
          And(
            HasCurrentToken(),
            Equals(
              Select(["data", "type"], Get(CurrentToken()), false),
              "access"
            )
          )
        )
      )
    }
  ]
}

hope I have made my questions more clear, thank you :slight_smile:

4

The error comes from attempting to get the token. When using a token’s secret to authorize a query, there is only one implicit privilege: the identity can read/write its own identity document. No other privileges are available, including the ability to read the token associated with the identity.

You would have to provide a privilege to read the Tokens() collection. Alternatively, you could store the access type on the identity document itself, but that might not be what you want.

The reason that using “Run As” with the loggedIn role works is that a scoped key is being used to implement the feature. The secret being used has the admin role, and overlaying the loggedIn role’s privileges doesn’t remove access to read Tokens().

5

When you use the Get(CurrentToken()), you get the actual Token returned. Is that what you want? When you create the Token, are you adding data to it?

Or is CurrentIdentity() what you want? Doing Get(CurrentIdentity()) will return the user document.

It depends on where this type field exists. On the Token or the user Document.

6

Thank you for your answer, following your suggestion, I have provided the privilege to read tokens() collection for the loggedIn role, and I can get the result from the getLadder function correctly if I ran the query in the dashboard shell as a loggedIn user with its secret, however, when I tried to query it in graphQL playground (providing the header with the same secret), I still get the permission denied error :confused:

7

Can you confirm whether CurrentToken or CurrentIdentity is the Reference that you need?

8

Yes, I believe it’s CurrentToken that we need here, since we want to check if the user is currently logged in (thus has the loggedIn role), and the type field exists on the Token.
What confused me is, the loggedIn role has the privilege to call the getLadder UDF, and the UDF has been assigned to a role that has access to all the indexes and collections/functions needed, in theory, the query should work just fine?

9

I think the root problem is that CurrentToken does not work on keys scoped to documents, but even if it did it wouldn’t have the data you are looking for.

Like @ewan said, Run as works on scoped keys. Without run as, the webshell uses an admin key that on your root database then scoped to the current db. Run as > Specify a document further scopes the key to a specific document.

You can observe the keys used by reviewing your browser’s network tab. For example, here is the authorization header from a query I ran as a user Document.

image

Also, you should not need to include additional permissions to execute FQL within the Role predicates. Role predicates are executed with essentially admin permissions (can only read).

By added read permission to tokens() of your loggedIn Role, you are allowing your users to paginate and view every token in your DB, which doesn’t sound like what you would actually want.

10

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.