Parse Cloud Code Function won't allow Queries, or any object manipulation through cloud code.

[malcolm-dane]

New Issue Checklist

• [X ] I am not disclosing a vulnerability.
• [X ] I am not just asking a question.
• [ X] I have searched through existing issues.
• [X ] I can reproduce the issue with the latest version of Parse Server.

Issue Description

Repeated errors in cloud code function using queries. Setting no user in the fields, using master key etc doesn't allow for queries,object manipulation etc. Throws error: Parse error: TypeError: Cannot read property 'protectedFields' of undefined {"code":1,"stack":"Error: TypeError: Cannot read property 'protectedFields' of undefined\n at /app/node_modules/parse-server/lib/Controllers/DatabaseController.js:1170:21\n at processTicksAndRejections (internal/process/task_queues.js:95:5)"}

Steps to reproduce

I had the latest Parse Server, dropped it down to a few months old, and still the bug was there. Create cloud function to Query an Object and return an array etc. Manually created mongoatlas entries and tried to query them via cloud function, these items had no permissions set. master key was set to be used, and user set to false.

Actual Outcome

I have gotten several errors similiar to this or like this one:

error: Parse error: TypeError: Cannot read property 'protectedFields' of undefined {"code":1,"stack":"Error: TypeError: Cannot read property 'protectedFields' of undefined\n at /app/node_modules/parse-server/lib/Controllers/DatabaseController.js:1170:21\n at processTicksAndRejections (internal/process/task_queues.js:95:5)"}

Expected Outcome

For it to atleast return something retrieved from the backend

Environment

Heroku 20
Parse Server 4.10.0 -> latest build.
Updated Node, downgraded node etc. Didn't go too long ago in version numbers.

Server
"parse": "3.4.0",
"parse-server": "4.10.0"

• Parse Server version: 4.10 but also latest
• Operating system: `Ubuntu'
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): heroku

Database

• System (MongoDB or Postgres): atlas
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): Atlas

Client

• SDK (iOS, Android, JavaScript, PHP, Unity, etc): REST

Logs

error: Parse error: TypeError: Cannot read property 'protectedFields' of undefined {"code":1,"stack":"Error: TypeError: Cannot read property 'protectedFields' of undefined\n at /app/node_modules/parse-server/lib/Controllers/DatabaseController.js:1170:21\

[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]

Under "Steps to reproduce" could you please provide a 1. 2. 3. instruction for others to reproduce the issue? And even better, if you could provide a PR with a failing test, it would be even easier to understand.

[malcolm-dane]

I'll do it this weekend. It seems specific to the REST API.

[jonas-db]

I'm experiencing the same error in my jasmine test suite on the latest beta where I start/stop the parse server for every test.. it seems something is not reset/set correctly when the server is reinitialized. The first test always works fine, other tests usually fail with following error. Running each test separate makes all tests pass so it is not a test problem.

[Debug] ParseError: TypeError: Cannot read property 'protectedFields' of undefined
    at /Users/abc/server/node_modules/parse-server/src/Controllers/DatabaseController.js:1337:27
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at Object.getAuthForSessionToken (/Users/abc/server/node_modules/parse-server/src/Auth.js:88:16) {
  code: 1
}

EDIT: adding delay of 5seconds after the parseServer.handleShutdown(); seems to make the tests pass in most cases..

Maybe this is related?: #7525

[mtrezza]

That's interesting, so these are flaky tests? We do have some flaky tests in Parse Server, but it's also not uncommon for all tests to pass. Or are you talking about your own custom tests?

Maybe this is related?: #7525

May well be, depending on the test.

[malcolm-dane]

It occurs for me in regular use. Specifically with cloud functions. I can't figure it out.

…

On Wed, Dec 22, 2021, 6:05 PM Manuel ***@***.***> wrote: That's interesting, so these are flaky tests? We do have some flaky tests in Parse Server, but it's also not uncommon for all tests to pass. Or are you talking about your own custom tests? — Reply to this email directly, view it on GitHub <#7728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXJOVU2X4I3IWVVSNWMTH3USJKUPANCNFSM5I42E4CA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jonas-db]

I did some further digging.. and these are some observations. What do you think @mtrezza?
(and yes it's my own test suite, based on: #7527 (comment))

in my case the error comes from the fact that:

DatabaseController#filterSensitiveData returns undefined for const perms = schema.getClassLevelPermissions(className); where className is either _Session or _User

parse-server/src/Controllers/DatabaseController.js

Line 136 in 191d80b

const perms = schema.getClassLevelPermissions(className);

Usually this function returns something alike (eg for the _user):

{
  find: { '*': true },
  count: { '*': true },
  get: { '*': true },
  create: { '*': true },
  update: { '*': true },
  delete: { '*': true },
  addField: { '*': true },
  protectedFields: { '*': [ 'email' ] }
}

but since it is now undefined, it triggers an error at the following line:

parse-server/src/Controllers/DatabaseController.js

Line 202 in 191d80b

perms.protectedFields &&

The condition should include && perms because otherwise perms.protectedFields will trigger an error because perms is undefined.

if (!(isUserClass && userId && object.objectId === userId)) {
    protectedFields && protectedFields.forEach(k => delete object[k]); // fields not requested by client (excluded),
    //but were needed to apply protecttedFields

    perms.protectedFields && perms.protectedFields.temporaryKeys && perms.protectedFields.temporaryKeys.forEach(k => delete object[k]);
  }

If I extend the condition as follows:
if (!(isUserClass && userId && object.objectId === userId) && perms) ,
then the test case fails with:

error: Invalid session token {"code":209,"stack":"Error: Invalid session token\n at Object.getAuthForSessionToken (/Users/jonas/git/judica/server/node_modules/parse-server/src/Auth.js:100:11)\n at processTicksAndRejections (internal/process/task_queues.js:97:5)"}

Although my user is created and logged in (they have an id + sessiontoken).. I believe this error is not representative (just like the original error) and the issue lies somewhere in the code path above..

const registration = await Parse.User.signUp(email, "test", attributes); // AS_MASTER
        console.log(">>>> registration")
        console.log(registration.id,registration.get('sessionToken'))
        expect(registration.get('sessionToken')).to.not.be.undefined
        expect(registration.id).to.not.be.undefined

        const user = await Parse.User.logIn(email, "test");
        console.log(">>>> user")
        console.log(user.id,user.get('sessionToken'))
        expect(user.get('sessionToken')).to.not.be.undefined
        expect(user.id).to.not.be.undefined

        return user

So the question remains why schema.getClassLevelPermissions(className); returns undefined in some cases.. and as it occurs randomly it seems like a timing issue...

The SchemaController.schemadata is the following when the error occurs:

SchemaData {
  __data: {},
  __protectedFields: { _User: { '*': [Array] } }
}

but otherwise it is:

SchemaData {
  __data: {
    _User: {
      fields: [Object],
      classLevelPermissions: [Object],
      indexes: [Object]
    }
  },
  __protectedFields: { _User: { '*': [Array] } }
}

I also figured that performInitialization is not implemented for the mongodb adapter, while it is for the postgres adapter (where it ensures some schema things...). Maybe it needs to return a promise that waits for the schemas to be inserted instead of the current Promise.resolve()? Although i'm not sure this is related but performInitialization is called by the ParseServer constructor.

parse-server/src/Adapters/Storage/Mongo/MongoStorageAdapter.js

Line 995 in 191d80b

performInitialization(): Promise<void> {

[mtrezza]

Are you only observing this issue in your tests, or in an actual app? The original description by @malcolm-dane did not mention any tests, and they mentioned "It occurs for me in regular use", so I assume it was not test related.

I want to exclude the possibility that this issue is only related to the test setup where a some things are mocked for testing.

[jonas-db]

In my case the tests, but it should not matter because I initialize the parse server just as I do in my real application, no mockups, no other options. The only difference is that in the test it is started sequentially multiple times and therefore things might be slower and the startcomplete callback doesn't seem to trigger correctly. So i still assume some feature might not be initialized even though the callback suggest it is. Let me see if i can make a minimal example

[jonas-db]

I've been narrowing down the issue.. but I need to dig some more. Right now it seems to occur when I have an asyncParse.Cloud.afterSave registered. @malcolm-dane do you have such a trigger as well maybe?

[malcolm-dane]

Yes I do.I haven't tried to debug this yet, with your added notes but I think there is an issue with the returning of an async promise and await. I think the issue is that the async isn't actually async, and certain cloud code functions cause some type of a race condition where the cloud code that is triggered isn't registered to the get/post method that called it. If that makes sense.... I have to look at the notes in my code. There is something weird going on, and I'm not too sure exactly what is causing it.

…

On Fri, Dec 24, 2021 at 5:04 AM jonas-db ***@***.***> wrote: I've been narrowing down the issue.. but I need to dig some more. Right now it seems to occur when I have an asyncParse.Cloud.afterSave registered. @malcolm-dane <https://github.com/malcolm-dane> do you have such a trigger as well maybe? — Reply to this email directly, view it on GitHub <#7728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXJOVROAN4EGEMCDBF3BOLUSRASXANCNFSM5I42E4CA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[malcolm-dane]

Sorry that is the most technical I can get at 6 am here ;). It's something strange like what I just described. I eliminated improper set up of the server(*), and tried all known solutions. It isn't my database configuration and it isn't any unusual middleware. I can't get cloud code interaction with the mongo database to work no matter how I set it up, and the only possible thing I could think of is that the cloud code is being called in an out of order way causing it to throw that error. * There is a dependency, I think it's kerberos, that might be influencing this bug. Do you have that dependency in your build? On Fri, Dec 24, 2021 at 6:01 AM Malcolm Dane < ***@***.***> wrote:

…

Yes I do.I haven't tried to debug this yet, with your added notes but I think there is an issue with the returning of an async promise and await. I think the issue is that the async isn't actually async, and certain cloud code functions cause some type of a race condition where the cloud code that is triggered isn't registered to the get/post method that called it. If that makes sense.... I have to look at the notes in my code. There is something weird going on, and I'm not too sure exactly what is causing it. On Fri, Dec 24, 2021 at 5:04 AM jonas-db ***@***.***> wrote: > I've been narrowing down the issue.. but I need to dig some more. Right > now it seems to occur when I have an asyncParse.Cloud.afterSave > registered. @malcolm-dane <https://github.com/malcolm-dane> do you have > such a trigger as well maybe? > > — > Reply to this email directly, view it on GitHub > <#7728 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACXJOVROAN4EGEMCDBF3BOLUSRASXANCNFSM5I42E4CA> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you were mentioned.Message ID: > ***@***.***> >