Feature `directAccess` without tests

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 version of Parse Server.

Issue Description

The directAccess feature defaults to being enabled since Parse Server 6. This was a decision made after the feature has been in an experimental state for years (introduced in 2017) and used by developers in production environments. The goal was to make the feature broadly available to mature it faster and fix any bugs reported.

However, it seems that the feature itself is not tested - at all - in our CI. In fact, not a single test runs with directAccess enabled. The test suite does not allow to use the ParseServerRESTController because the test helper always sets the normal REST controller:

https://github.com/parse-community/parse-server/blob/4b3ce20300b05b015b48efeb82d693200159911f/spec/helper.js#L169

This overrides the server config for tests which is deliberately set to enable direct access:

https://github.com/parse-community/parse-server/blob/4b3ce20300b05b015b48efeb82d693200159911f/spec/helper.js#L109

So even if calling await reconfigureServer({ directAccess: true }); in a test, the normal REST controller will be used.

That override was added in https://github.com/parse-community/parse-server/pull/8232. From the past discussions around officially releasing the directAccess feature it seems this was added to make the tests pass, as the refactor would have been to vast to run all the tests once with directAccess enabled and once with directAccess disabled.

The fact that the tests run without directAcess enabled while at the same time directAcess is enabled by default in Parse Server is a contradiction that can easily lead to - especially Cloud Code related - bugs not being discovered by the CI. For example https://github.com/parse-community/parse-server/issues/8806.

Removing the REST controller override to run tests with directAccess: true causes 403 tests to fail, see https://github.com/parse-community/parse-server/pull/8807.

Solution

We should probably run the CI with directAccess enabled and disabled. Running every CI job twice would consume a lot of resources. Instead, depending which of the two the CI should focus on, at least 1 job could run with directAccess enabled and the rest of the jobs with directAccess disabled, or vice-versa.

Start in spec/helper.js at the directAccess configuration and REST controller override, then inspect src/ParseServerRESTController.js. Reproduce the 403 failures described in pull request 8807 and review issue 8806 for an affected case. Done means CI exercises directAccess-enabled and disabled configurations without masking the selected mode, with the relevant tests passing.