Setting up realm to bring records the user has permission to view

[Chris_Boot1 (Chris Boot)]

Hi,

I have a collection with 1 million records split across 20 organisations which is named people.

I am wanting to configure a mobile application to display the people data the logged in user has permission to. I set up the authentication for the mobile app to “Custom JWT” authentication and setup a claim in the JWT for organisationId. Within Atlas I then use the metadata fields to map the claim to a field.

I now want to setup a rule which will only return the people data for the organisation the user has access to so all permissions are configured on the server side. A concern is that if I set up the query on the app side and someone manages to decompile my app that they could generate a JWT and view any data for any organisation.

I thought the following under the people rules for read access is what I would want but this returns me 0 records (even though there should be about 40k being returned)

{
  "OrganisationId": {
    "$eq": "%%user.data.organisationId"
  }
}

If also tried custom_data and I’ve also tried setting the value manually, all with the same result.

Any assistance here to point me in the right direction would be greatly appreciated.

[Tyler_Kaye]

Hi, can you try just using:

{
  "OrganisationId": %%user.data.organisationId
}

And just to confirm, are you doing this in the document permissions? If this does not work, feel free to send a link to your App Services URL and I can take a look.

[Chris_Boot1 (Chris Boot)]

Hi Tyler,

I did try this but got the following exception - unless I’m looking in the wrong place?

Sorry, not sure how I get my app services URL but I can certainly send this across too.

Thanks

Chris

[Tyler_Kaye]

Sorry, I think you need to place “%%user.data.organisationId” in quotes for it to be a valid value.

[Chris_Boot1 (Chris Boot)]

Hi Tyler,

This didn’t impact anything I still view no information on my local application.

Is there something that should be in the “apply when” area? I did attempt to put this filter in there and then the client application crashed and there was an error log which returned the following:

no applicable role found, denying all access for tables: [“Person”] (ProtocolErrorCode=201)

Thanks

Chris

[Chris_Boot1 (Chris Boot)]

Hi Tyler

The following has come out of the logs:

query references fields that it does not have access to read (ProtocolErrorCode=206)

Whilst the following is displayed in my .net code:

Realms.Sync.Exceptions.SessionException: 'Permission denied (BIND, IDENT, QUERY, REFRESH) Logs:

So to walk through how I’ve set all this up,

I set up my authentication to use a custom JWT:

And then from here configure everything as required:

I’ve already proven off that if the claim doesn’t exist in the JWT that the code throws an exception as expected. I am not sure though on how to see what the values of the claims are for the data mapping. Is there somewhere I can check this within Atlas as I also can’t appear to view this as part of the user object in my .net code.

Checking the applied rules:

That all looks fine to me so in a bit of a cycle of trying / failing to address the issue.

[Tyler_Kaye]

Hi, it sounds like the issue is that the permissions reference the field OrganizationId but that has not been added as a queryable field: https://www.mongodb.com/docs/atlas/app-services/rules/sync-compatibility/#sync-compatible-roles

If you go to the sync config page you can add the field as a global queryable field and that should resolve things.

You can read here why this is required: https://www.mongodb.com/docs/atlas/app-services/sync/configure/sync-settings/#performance-and-storage

[Chris_Boot1 (Chris Boot)]

Hi Tyler,

I’d like to thank you for all your assistance. I have managed to get it working but I’m not sure exactly which bit fixed the problem. I already had collection level queryable fields which I did change to global queryable fields (although I’m still struggling to understand why you would have collection level if only global works).

I’m now going to work backwards to try and understand the changes implemented that got me to that point.

[Tyler_Kaye]

I am glad that this resolved your issues. Collection-Level only applies to the individual collections that they are defined for, so if you had 3 collections and you only defined OrganizationId as a collection queryable field for one of them, then if the rule was referencing a different collection (or if it was a default rule and thus applied to all other collections) then it would not be the case that OrganizationId was queryable on all collections.

Hope that makes sense and happy to answer any other questions.

Best,
Tyler