LiveQuery WebSocket server ignores enableAnonymousUsers and CLP

[ruimgoncalves]

LiveQuery WebSocket server ignoresenableAnonymousUsers = false setting and allows an anonymous user to connect and subscribe to queries even if sessionTokenis not passed.

The LiveQuery server should prevent clients from connecting if this setting is turned off, and make both servers work consistently. This also prevents the need of setting ACL on each document if the intent is only check for current logged-in users and thus reducing the servers overhead.

I also unchecked the GameScore class public read and write operations in CLP via the Parse Dashboard, so I expected the server to block read operations from unknown users. Then I read the LiveQuery docs and it does not take into account CLP. I think it could be interesting to have less granular security management in some scenarios, like this one.

Steps to reproduce

1. Install latest version, git clone https://github.com/ParsePlatform/parse-server-example.git and npm install
2. Create a GameScore class with some fields, like [playerName, score, cheatMode], goto security (CLP) and uncheck Public Read and Write.
3. Change the server index.js file

var api = new ParseServer({
  databaseURI: databaseUri || 'mongodb://localhost:27017/dev',
  cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js',
  appId: process.env.APP_ID || 'myAppId',
  masterKey: process.env.MASTER_KEY || 'masterKey', //Add your master key here. Keep it secret!
  //clientKey: process.env.CLIENT_KEY || 'clientKey',
  serverURL: process.env.SERVER_URL || 'http://localhost:1337/parse',  
  enableAnonymousUsers : process.env.ENABLE_ANON_USERS || false,
  allowClientClassCreation: process.env.CLIENT_CLASS_CREATION || false,
  verbose : process.env.VERBOSE || 1,
  liveQuery: {
    classNames: ["GameScore"] // List of classes to support for query subscriptions
  }
});

1. Create an empty html file add this javascript script

Parse.initialize("myAppId");
Parse.serverURL = 'http://localhost:1337/parse';
console.log("Current user", Parse.User.current());

let query = new Parse.Query('GameScore');
query.find().then((data, err)=>{
   console.log("Find = ",data, err);
});

let subscription = query.subscribe();
subscription.on('open', () => {
   console.log("Connection Open");
});

Parse.LiveQuery.on('error', (error) => {
   console.error("Connection Error", error);
});

Expected Results

The logs messages should be

Current User, null
Connection Error ...

The connection should be rejected and a console message should be Connection Error. The client should not receive additional messages from the ws server.

Actual Outcome

Instead you get in the browsers console the log message

Current User, null
Connection Open

As proof, open chrome dev tools -> network, filter by WS (websocket) connections and open the row with the parse name, then select the frames tab, you get data frames every time the subscribed data is changed. So to test this open Parse Dashboard and create, delete or edit documents in the GameScore collection.

Environment Setup

• Server
  • parse-server version : 2.2.22
  • Operating System: Windows 10.0.14393
  • Hardware: Intel i7 64x, 8G ram
  • Localhost with Node 6.7.0
• Database
  • MongoDB version: 3.0.0
  • Storage engine: { storage: { dbPath: "./db", journal: { enabled: true }, mmapv1: { smallFiles: true } } }

Logs/Trace

verbose: Current clients 0
verbose: Current subscriptions 0
verbose: REQUEST for [GET] /parse/classes/GameScore: {
  "where": {
  },
} method=GET, url=/parse/classes/GameScore, host=localhost:1337, connection=keep-alive, content-length=177, pragma=no-cache, cache-control=no-cache, origin=http://localhost:1337, user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36, content-type=text/plain, accept=*/*, referer=http://localhost:1337/public/test.html, accept-encoding=gzip, deflate, ,pt;q=0.8,en-US;q=0.6,en;q=0.4, 
error: Error generating response. ParseError {
  code: 119,
  message: 'Permission denied for action find on class GameScore.' } code=119, message=Permission denied for action find on class GameScore.
verbose: Request: %j op=connect, applicationId=myAppId
info: Create new client: 1
verbose: Push Response : "{\"op\":\"connected\",\"clientId\":1}"
[object Object]
verbose: Request: %j op=subscribe, requestId=1, className=GameScore, 
verbose: Push Response : "{\"op\":\"subscribed\",\"clientId\":1,\"requestId\":1}"
verbose: Create client 1 new subscription: 1
verbose: Current client number: 1

[flovilmart]

enableAnonymousUsers=false actually don't prevent anyone to fetch data from parse-server. This feature actually let users to have a session without being explicitly signed in through email and password, setting it to off, just prevents sessions to be created.

[ruimgoncalves]

Hi @flovilmart, thanks for your reply, so how does one prevent anonymous users from fetching data? Should I change the title?

[flovilmart]

so how does one prevent anonymous users from fetching data

At the moment, there is no straightforward way of achieving that, you can use a mix of Roles, ACL's and CLP.

There is this PR #893 that would give a 'false sense of security' unless you restrict who can signup / disable signup altogether.

[TimNZ]

I had a quick look through LiveQuery src, and it seems class level permissions are not checked, only object ACL.

Is CLP checks going to be implemented?

I have classes with CLP of 'requiresAuthentication' for everything, so subscribed clients who are not yet signed in are getting subscription events.

[flovilmart]

Yes, you are right, they are not implemented yet, i’ll Have a look to implement them.

[TimNZ]

Thanks. I'd give it a go and do a pull , but I'm time challenged, and would want to maintain the code structure and style which is a learning curve.

For example, would you put CLP check in matchesACL(), or a new function matchesCLP(), and then have a parent function hasAccess() that calls matchesACL() and matchesCLP(), requiring a refactor of all calls to matchesACL()

[flovilmart]

@TimNZ I'm having a look right now and the biggest challenge would be to refactor the CLP logic so it can be shared with the liveQuery. Contrary to ACL's where we can match the ACL against any user / session token, the CLP's are stored in the schema, and we may not want to get it from the schema all the times.

I'd add a new method, matchesCLP, before matchesACL. In parse-server, CLP's must pass before we even consider looking into the ACL's. See SchemaController.validatePermissions

The easiest way to get a schemaContoller is through the DatabaseController

Because we have the AppId, if ParseLiveQueryServer is sharing the parse-server instance, that helps, otherwise we need to provide a way to load a databaseController on it, or an access to the shared SchemaCache :)

For now we don't have 'readOnly' SchemaController that would be driven only by the cache, but that could be an idea, for example if you use a distributed cache like Redis.

As you see it's not all trivial :)

Last resort solution, it the regular REST API to load the schema (which I would not recommend)

Another thing we could do, it provide the CLP object, when we emit the object in ParseCloudCodePublisher

This way, the LiveQueryServer may take the decision it want. (that may be actually the best solution).

A small refactor on the SChemaController to make the validatePermissions static, so you can pass a schema / list of classLevelPermissions to test against would probably be needed, but that's minor.

[TimNZ]

Ok. Definitely leaving it to the expert.

But I'm launching next week, so of course I expect you to make this your #1 priority :) [jokes]

[flovilmart]

Haha, yeah it's kinda a rabbit hole, but I'll try solution 2 as it's been obviously badly overlooked.

[flovilmart]

@TimNZ, what’s your particular use case for classLevel permissions? I believe pointer permissions right? Because liveQuery is only about reads. Do you expect with find disabled to not propagate the objects?

[TimNZ]

Yes. If a client doesn't have permissions to a class/object, they shouldn't be getting any notifications (and a copy of the object) of them.

I'm using JS client in browser extensions and Electron apps.

It's not a big deal, I'm going to create a 'broadcast' class that is the only class enabled for live queries that has basic details for doing subsequent query on other classes for via queries.

But even then I don't want non authenticated clients getting subscription notifications until they have authenticated - e.g. requiresAuthentication = true.

I can not subscribe the client till they are authenticated, but if someone is bored they could simply copy my JS code and get subscription events using visible App ID and JS keys.
Would they, very unlikely, nothing interesting in what I'm going to push without access to other classes.

But to me it is obvious that the server should be enforcing the security model consistently.

[TimNZ]

Whatever implementation/options enables the above works for me.
Having a 'requiresAuthentication = true' or 'enableAnonymousClient = false' option on the LiveQuery Server would do the job as well.