Don't require app ID header in request for single-app deployment

[sunshineo]

if x-parse-application-id is provided on the header, it is required to match one of the app(s) for clients always doing HTTP POST instead of proper HTTP calls, _ApplicationId is still required on the post body, it does not need to match if there is only one app, it is required to match one of the apps if there are multiple apps probably also fixed a couple bugs of using req.body as JSON before parse it #6590

[codecov[bot]]

Codecov Report

Merging #6645 (ad6c69f) into master (114d78e) will increase coverage by 0.02%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #6645      +/-   ##
==========================================
+ Coverage   93.85%   93.88%   +0.02%     
==========================================
  Files         169      169              
  Lines       12206    12209       +3     
==========================================
+ Hits        11456    11462       +6     
+ Misses        750      747       -3     

Impacted Files	Coverage Δ
src/middlewares.js	97.65% <100.00%> (+0.03%)	:arrow_up:
src/RestWrite.js	93.81% <0.00%> (ø)
src/Adapters/Storage/Mongo/MongoStorageAdapter.js	93.54% <0.00%> (+0.66%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 114d78e...ad6c69f. Read the comment docs.

[davimacedo]

@sunshineo thanks for the PR. Could you please add some test cases?

[sunshineo]

Is there any pending issues prevent merging this? Thanks

[sunshineo]

Are we still collecting feedback from the community?

[sunshineo]

I just resolved the merge conflicts. Hi @davimacedo @mman @acinader @TomWFox . Could anyone approve this?

[sadortun]

Could you please merge this ? @davimacedo @mman @acinader @TomWFox

EDIT:

If anyone need to bypass the header, this is working prety well

// index.js
const app = express()

// Serve the Parse API on the /parse URL prefix
const mountPath = process.env.PARSE_MOUNT || '/parse'

app.use(`${mountPath}/functions`, (req, res, next) => {
  if (!req.headers['x-parse-application-id']) {
    req.headers['x-parse-application-id'] = config.appId
  }
  next()
})

[mtrezza]

This requires a thorough conceptual review. There has been some effort to remove the app ID in the past, but whether it is feasible or practical to remove it has not been evaluated conclusively.

There is at least one current feature request which seem to require the app ID. Merging this PR seems like an uncoordinated step towards removing the app ID, just because it solves some unspecific problem. Therefore my suggestion is to look at the bigger picture before considering to make a step into a direction without examining the full path.

[sunshineo]

This is not remove. This makes it optional if there is only one app.

[mtrezza]

An optional requirement means it won't be available in certain scenarios instead of being mandatory as it currently is. I don't think it is clear yet what this PR implies, it removes a parameter that is otherwise mandatory throughout the platform.

I suggest to change the first comment of this PR and use the new PR template, so we can further look into this PR. It is not clear what this PR does from the current comment:

ApplicationId is still required on the post body, it does not need to match if there is only one app

Required but does not need to match, does not make sense to me.

[sunshineo]

@mtrezza You do not understand the part because you did not read closely. It is the "_ApplicationId" not "ApplicationId" that you quoted. The dashboard always uses a POST instead of standard http methods to avoid preflight, so it need a "_ApplicationId" in the post body. This PR did not touch that

[mtrezza]

Can you clarify what you mean by "standard http method / proper http calls"? Why is a POST request not a proper http request?

The dashboard always uses a POST instead of standard http methods

Would you mind clarifying your first comment in this PR and use the new PR template - maybe that helps.

[sunshineo]

Dashboard use a special POST to retrieve information. It does not use GET because it want to avoid preflight. That special POST has an "_ApplicationId" in it. This PR did not touch that

I'll switch to the new template when I find some time

[ghost]

Danger run resulted in 1 warning; to find out more, see the checks page.

Generated by :no_entry_sign: dangerJS

[mtrezza]

⚠️ Important change for merging PRs from Parse Server 5.0 onwards!

We are planning to release the first beta version of Parse Server 5.0 in October 2021.

If a PR contains a breaking change and is not merged before the beta release of Parse Server 5.0, it cannot be merged until the end of 2022. Instead it has to follow the Deprecation Policy and phase-in breaking changes to be merged during the course of 2022.

One of the most voiced community feedbacks was the demand for predictability in breaking changes to make it easy to upgrade Parse Server. We have made a first step towards this by introducing the Deprecation Policy in February 2021 that assists to phase-in breaking changes, giving developers time to adapt. We will follow-up with the introduction of Release Automation and a branch model that will allow breaking changes only with a new major release, scheduled for the beginning of each calendar year.

We understand that some PRs are a long time in the making and we very much appreciate your contribution. We want to make it easy for PRs that contain a breaking change and were created before the introduction of the Deprecation Policy. These PRs can be merged with a breaking change without being phased-in before the beta release of Parse Server 5.0. We are making this exception because we appreciate that this is a time of transition that requires additional effort from contributors to adapt. We encourage everyone to prepare their PRs until the end of September and account for review time and possible adaptions.

If a PR contains a breaking change and should be merged before the beta release, please mention @parse-community/server-maintenance and we will coordinate with you to merge the PR.

Thanks for your contribution and support during this transition to Parse Server release automation!