What are the role limitations associated with calling v4 UDFs with v10 syntax?

[Darryl_Naidu]

I am trying to use old v4 UDFs in wrapped v10 queries (using below syntax) and struggling to understand how user defined roles are viewed through this approach.

let num = Increment(1)
num

When the ‘Client’ role is assigned to the v4 UDF (see below)

role: Role("Client"),

When attempting to call the function, simulating the key (i.e. Role = Client) in the v10 shell, I receive the following:

However when the ‘admin’ on no role is assigned to the v4 UDF (see below)

role: Role("admin"),

or

role: null,

The v10 query can be executed by the ‘admin’ Built-in Role.

What am I missing? Can the v4 UDF in a v10 query wrapper only be referenced by Built-in Roles?

[ptpaterson]

Can you please share the UDF definition?

[Darryl_Naidu]

Thanks @ptpaterson,

The issue is not confined to one UDF though an example UDF is below:

{
  name: "FindAllAllergens",
  role: null,
  body: Query(
    Lambda(
      [],
      Filter(
        Union(
          Select(
            ["data"],
            Paginate(Distinct(Match(Index("allAllergens"))), { size: 100000 })
          )
        ),
        Lambda("i", IsString(Var("i")))
      )
    )
  )
}

The v10 call used is below:

let num = FindAllAllergens()
num

[ptpaterson]

@Darryl_Naidu

{
  name: "FindAllAllergens",
  role: null,

The role field is null for this UDF, so whatever context is calling FindAllAllergens must have the permission to read both the allAllergens Index and the source Collections for that index (presumably something like Allergens).

You will need to assign a Role defined using FQL v4 to provide access to the v4 Index. Roles written with v10/FSL cannot refer to v4 Indexes.

You can either assign the v4 Role directly to the Function, or you can assign membership so that callers’ tokens are assigned the v4 Role.

Does Role("Client") provide read access to allAllergens Index and the source collection? Does it include a membership definition?

[Darryl_Naidu]

@ptpaterson

provide read access to allAllergens Index and the source collection? Does it include a membership definition?

Thanks @ptpaterson. This works and I was able to solve the calling of the native v10 function I had created. I hadn’t assigned read access to the Collection containing the Index the UDF referred to.

Could you elaborate on the comment below:

You will need to assign a Role defined using FQL v4 to provide access to the v4 Index. Roles written with v10/FSL cannot refer to v4 Indexes.

You can either assign the v4 Role directly to the Function, or you can assign membership so that callers’ tokens are assigned the v4 Role.

Specifically, if a v4 UDF refers to a v4 Index, does that mean it cannot be called with a v10 Role or have I just misinterpreted what you had written above. Alternatively, can I assign a v10 Role membership to a v4 Role to permit calling of a v4 UDF given I can’t assign permission for the v10 Role to read a v4 index?

Also, the comment below may create a slight problem for me in the migration of UDFs from v4 to v10:

must have the permission to read both the allAllergens Index and the source Collections for that index (presumably something like Allergens

My intention was to eliminate direct access to Collections for client and other externally oriented Roles. This was possible in v4 as it didn’t require that the Role had access to the Collection, just the Index referenced by the UDF. In v10, is there some way to limit the Role’s access to the Collection to that obtained through the UDF with Memberships or Membership predicates?

[ptpaterson]

@Darryl_Naidu

Could you elaborate on the comment below:

You will need to assign a Role defined using FQL v4 to provide access to the v4 Index. Roles written with v10/FSL cannot refer to v4 Indexes.

You can either assign the v4 Role directly to the Function, or you can assign membership so that callers’ tokens are assigned the v4 Role.

Specifically, if a v4 UDF refers to a v4 Index, does that mean it cannot be called with a v10 Role or have I just misinterpreted what you had written above. Alternatively, can I assign a v10 Role membership to a v4 Role to permit calling of a v4 UDF given I can’t assign permission for the v10 Role to read a v4 index?

The simplest way to define what is needed is this: You must have read privileges to a v4 Index in order to read the index. Full Stop.

So, how can you read that v4 Index? The only way to assign privileges to a v4 Index is to use a v4 Role. v10 Roles cannot reference v4 Indexes. That means either:

1. the caller must have a v4 Role with read privileges for the Index, or
2. the UDF must be assigned a v4 Role with read privileges for the Index.

Consider these situations

The caller has a v10 Role, but UDF has no Role. Access denied

[role: v10_Role]      [role: null]
   some token    --->    v4 UDF    -X->  v4_Index

The caller has a v10 Role, and the UDF has a v4 Role without access. Access denied

[role: v10_Role]      [role: v4_Role_wo_access]
   some token    --->            v4 UDF           -X->  v4_Index

We can see that the ONLY way we can ever read from a v4 Index using FQL v10 is to assign the UDF a Role that can read it.

The caller has a v10 Role, and the UDF has a Role with access. Access granted

[role: v10_Role]      [role: v4_Role_with_access]
   some token    --->            v4 UDF            --->  v4_Index

[ptpaterson]

@Darryl_Naidu

Also, the comment below may create a slight problem for me in the migration of UDFs from v4 to v10:

must have the permission to read both the allAllergens Index and the source Collections for that index (presumably something like Allergens

My intention was to eliminate direct access to Collections for client and other externally oriented Roles. This was possible in v4 as it didn’t require that the Role had access to the Collection, just the Index referenced by the UDF. In v10, is there some way to limit the Role’s access to the Collection to that obtained through the UDF with Memberships or Membership predicates?

This is a great benefit to assigning a Role to the UDF and a narrower permission to the caller. You can give the UDF permission to read the documents, process what you need to, then only return what is acceptable to you.

[Darryl_Naidu]

Thanks so much for explaining this. I get the use of Roles in UDFs now. I had previously seen it as constraining the availability of the UDF to certain caller Roles rather than providing access to the UDF. This makes sense as UDF access permissions are assigned explicitly to the Role.