Aggregate query does not honor sessionToken option if passed

[obermillerk]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and the Parse JS SDK.

Issue Description

Aggregate query does not honor the sessionToken option.

When passing a sessionToken it should only return objects that are readable by the user with that session token. Instead, the ACLs are ignored and all objects are returned.

Specifically, I have a query that is retrieving all objects of a certain class. A non-aggregate query could use the session token to only return objects the user has read permissions for. In the aggregate query, all objects are returned regardless of permissions.

I know that aggregate queries are different from normal queries and it may be impossible for you to support this option, but if that is the case the sessionToken should not be listed as an option for the aggregate function on the docs for Parse.Query (https://parseplatform.org/Parse-SDK-JS/api/master/Parse.Query.html#aggregate).

Steps to reproduce

• Create a user and create some Parse Objects that the user has exclusive read and write access to in the ACL
• Create a Cloud function that runs an aggregate query for these Parse Objects and returns all of them
• Log in as a second user and run the aggregate query

Actual Outcome

The objects owned by the first user are returned as part of the results for the second user's query.

Expected Outcome

The objects owned by the first user should be excluded from the second user's query. Only objects the second user has read access to should be returned.

Environment

Server

• Parse Server version: 4.5.0
• Operating system: Windows 10, I think also linux on our deployed server
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): local (and deployed)

Database

• System (MongoDB or Postgres): MongoDB
• Database version: 4.2.6
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): local (and deployed)

Client

• Parse JS SDK version: 3.3.0

Logs

[mtrezza]

While this is theoretically possible, it requires an enormous effort to parse the MongoDB aggregation syntax and interpret it correctly. It essentially requires to replicate the whole MongoDB aggregation parser in Parse Server. Given the versatility of aggregation and implied complexity, I would consider this highly unfeasible. Maybe consider aggregation queries as a form of "direct access" to the database that circumvents any Parse Server checks - and for that matter even most MongoDB Node.js driver checks.

I'm closing this for now, we can always re-open if someone really wants to pick this up and start working on it.

[REPTILEHAUS]

Just FYI maybe worth updating the docs as it says here its possible to use https://parseplatform.org/Parse-SDK-JS/api/master/Parse.Query.html#aggregate

[mtrezza]

Would you want to open an issue or even just a quick PR?

[REPTILEHAUS]

@mtrezza I can indeed, where do i find these docs ? I had a look around and found this repo but dont see anything related to the page i posted above https://github.com/parse-community/docs

Also if i remove the only valid option for aggregate(pipeline, options) should i just remove the options entirely from aggregate ?

[mtrezza]

This is created in the Parse JS SDK API docs, as you can see in the URL, Parse-SDK-JS:

https://parseplatform.org/Parse-SDK-JS/api/master/Parse.Query.html#aggregate

I wonder whether the option should actually be removed. Maybe the docs mean that the session token makes a ParseUser and/or the session token available in a Cloud Code trigger? But not sure if there are any triggers for aggregate queries? If so, we may only need to add a note that ACL / CLP are not applicable to aggregate queries. I think a look into the JS SDK and server code could give more insight here.

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[mtrezza]

Reopened, because the docs need to be adapted.