Clients aren't allowed to perform the find operation on the installation collection. (Code: 119, Version: 1.12.0)

[drorsun]

Hi,
I am opening this issue as a similar one (issue #1671) was closed without providing a solution.
We are running with latest parse server 2.2.7 and iOS SDK 1.12.0.
We are getting this error on the find operation:

Clients aren't allowed to perform the find operation on the installation collection. (Code: 119, Version: 1.12.0)

The code under enforeRoleSecurity method at node_modules/parse-server/lib/rest.js is:

function enforceRoleSecurity(method, className, auth) {
    if (className === '_Installation' && !auth.isMaster) {
        if (method === 'delete' || method === 'find') {
            var error = 'Clients aren\'t allowed to perform the ' + method + ' operation on the installation collection.';
            throw new Parse.Error(Parse.Error.OPERATION_FORBIDDEN, error);
        } 
    }
}

@brianyyz Had the same issue. If Solved for you I will be glad to learn how.

[brianyyz]

This may be because you're running withe latest parse.com IOS SDK which is at 1.12.0 and not the most current open source project SDK version which is 1.13.0

I am running the parse.com IOS SDK. I'll test using the current open source version and update this issue (was on holiday this weekend).

[brianyyz]

I tested with the parse.com IOS SDK (1.12.0) and with the latest release from Github for ParseUI-IOS and Parse-SDK-iOS-OSX (1.13.0) and the result is the same. Same outcome as @drorsun.

2016-05-09 09:34:26.326 ShareRides[99436:5768861] [Error]: Clients aren't allowed to perform the find operation on the installation collection. (Code: 119, Version: 1.13.0)

Client find on _Installation was a very useful and valid use case on parse.com typically to manage subscription channels specific to devices. I hope is a bug and not a change to parse-server.

[gfosco]

It seems unwise to allow clients to query the installation class. It would be better to have a cloud function do this with the master key...

[brianyyz]

@gfosco But isn't the point that this was permitted behaviour on the hosted parse.com and now on the new parse-server it is no longer permitted? If this has been an explicit change then we will have to change our apps as you've outlined above to retrieve device channel subscriptions via a cloud code function using master key. If it wasn't explicit then it feels like a bug.

[drorsun]

Here is a copy of the log from our parse-server for the request and response with this error. (I removed real IPs and app ids etc).

{"level":"verbose","message":"GET /parse/classes/_Installation/aJ3oRYc9yq { host: 'my.parse.server',\n  'x-real-ip': '11.11.11.11',\n  'x-forwarded-for': '11.11.11.11, 11.11.11.11',\n  accept: '*/*',\n  'accept-encoding': 'gzip, deflate',\n  'accept-language': 'en-us',\n  'user-agent': 'Yokee/1.0.36 CFNetwork/672.0.8 Darwin/14.0.0',\n  'x-parse-app-build-version': '1.0.36',\n  'x-parse-app-display-version': '4.0.7',\n  'x-parse-application-id': '###########',\n  'x-parse-client-key': '############',\n  'x-parse-client-version': 'i1.12.0',\n  'x-parse-installation-id': 'a8c65b5b-c7b1-45ab-9aca-e4f019ec9e5f',\n  'x-parse-os-version': '7.0.3 (11B511)',\n  'x-parse-session-token': 'r:5a5f254a7a5e2c855d7c8e6953dce775',\n  'x-forwarded-port': '443',\n  'x-forwarded-proto': 'https' } {}","timestamp":"2016-05-10T03:49:58.630Z"}
{"code":119,"message":"exception:","level":"verbose","timestamp":"2016-05-10T03:49:58.631Z"}

Hope it helps to understand the issue.

[brianyyz]

For further perspective on this issue - I am running an app on parse.com in which the client makes extensive use of the _Installation for two main purposes:
First, the push notification channels to which the user's device is subscribed are stored in the channels field. The client updates its own channel array via the app settings scene.
Second, the installation for a device holds a pointer to the _User which is used to manage users with multiple devices each of which could have different notification preferences.
The use case of storing channel on _Installation seemed like a recommended approach for parse.com and it is not working on parse server current build.
I'm quite new to parse-server github - can someone suggest next steps please? I'm happy to contribute if I can.

[alioguzhan]

Having the same issue. I believe that enforeRoleSecurity check for Installation class is unnecessary. Like @brianyyz mentioned, Installation queries from clients are useful for push handling. And i can't see any risk for letting clients query the Installation class. If i am missing something, please let me know. @gfosco

Since, migrating push handling to cloud code will take too much time for my app, i am going to wait for this issue for final decision.

[brianyyz]

Bump. Bug or Restriction?

This is a blocker for my app. I'm working around it for now by allowing clients to find on _Installation by overriding the enforeRoleSecurity method in node_modules/parse-server/lib/rest.js but if I need to change my approach to _Installation from the parse.com implementation will need a steer on where parse-server will go on this.

[drew-gross]

If there is a difference in behaviour between api.parse.com and Parse Server then that is a bug. But api.parse.com also doesn't allow clients to perform the find operation on _Installation:

(that was from dashboard.parse.com)

[brianyyz]

My IOS client uses PFInstallation.currentInstallation().fetchInBackgroundWithBlock from an authenticated PFUser to bring back the channels array on _Installation. On api.parse.com this call has always worked. On Parse Server I get back 119.

Happy to provide any needed trace or code or logs.

[drew-gross]

Yes, please set verbose: true in your Parse Server and include the exact request and response, which will show up in the logs.

[brianyyz]

verbose: GET /parse/classes/Installation/V3fDpD8PZ6 { host: 'localhost:1337',
accept: '/_',
'x-parse-session-token': 'r:bc157d87...',
'x-parse-application-id': 'zeZm...',
'x-parse-client-key': '9tnUS...l',
'x-parse-installation-id': '72878a6d-7b5f-42a1-bda2-4d395fe14df6',
'accept-encoding': 'gzip, deflate',
'x-parse-os-version': '9.3 (15E65)',
'accept-language': 'en-us',
'x-parse-client-version': 'i1.13.0',
'user-agent': 'ShareRides/15 CFNetwork/758.3.15 Darwin/15.4.0',
connection: 'keep-alive',
'x-parse-app-build-version': '15',
'x-parse-app-display-version': '0.8' } {}
verbose: exception: code=119, message=Clients aren't allowed to perform the find operation on the installation collection.

[drew-gross]

Hmm, that appears to be a get operation. If Parse Server is interpreting get as find that is definitely an issue. I will look into it.

[brianyyz]

A bit of history research to hopefully help move this along.

The change to rest.js that prevents clients from doing a find on _Installation was introduced as a fix to 1372 by @flovilmart in commit 5773143

I agree (for what that's worth) with the intent of the fix but a specific client must be able to retrieve its _Installation objects.

In the meantime I've just hacked rest.js to remove the check for the find operation but still think this is a change to api.parse.com behaviour that blocks app functionality as outlined above.