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:

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

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

That override was added in #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 #8806.

Removing the REST controller override to run tests with directAccess: true causes 403 tests to fail, see #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.