-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accept context via header X-Parse-Cloud-Context #7437
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7437 +/- ##
==========================================
+ Coverage 93.92% 93.95% +0.02%
==========================================
Files 181 181
Lines 13252 13267 +15
==========================================
+ Hits 12447 12465 +18
+ Misses 805 802 -3
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One argument for transmitting context
in the HTTP body (as it is currently done) instead of header is the size limitation of headers. RFC does not impose a size limitation, but practically the limit in most implementations is much lower for header than for body.~~
At this point I don't think this PR is beneficial. Let's discuss in #7438 (comment) but I wanted to make a note here so the PR doesn't get merged by mistake before the discussion in concluded.
As discussed in #7438 (comment), context transmission via header and body are both valid approaches. It can be considered a feature or at least expected behavior that header values can be overridden with body values as described in #7438 (comment).
Since we allow to override header values with body values, should we add a separate test case for that? I don't know whether other parameters have a test case for override, but it would at least document that behavior if we add a test case for context override. And it would probably fix the coverage fail. |
I can add this later today. I think the coverage fail is codecov has some probability of error in its line of code detection. The commit before this was +2/-2 for lines and passed. |
These get hit when you don't provide provide an parse-server/src/middlewares.js Lines 60 to 115 in 9ea355b
the
Because of what I mentioned above, I believe this PR can be merged without the additional test. |
My comment about codecov can be seen by observing the actual codecov: https://app.codecov.io/gh/parse-community/parse-server/compare/7437/diff#diff-c3JjL21pZGRsZXdhcmVzLmpz There's no delta... |
Are you referring to a test using the REST API? Couldn't you write a test using the JS SDK, saving a |
I'm not sure what you mean by this. Isn't this already done in this test and the tests after it?: https://github.com/cbaker6/parse-server/blob/a1be895cc55519586d2dab9f25a0b7616c3bb54c/spec/CloudCode.spec.js#L2839-L2847 Which ends up passing _context in the JS SDK: I can add another test that checks if options overrides the _context property set on an object, but this wouldn't have anything to do with the header: it('context options should override _context object property when saving a new object', async () => {
Parse.Cloud.beforeSave('TestObject', req => {
expect(req.context.a).toEqual('a');
expect(req.context.hello).not.toBeDefined();
expect(req._context).not.toBeDefined();
});
Parse.Cloud.afterSave('TestObject', req => {
expect(req.context.a).toEqual('a');
expect(req.context.hello).not.toBeDefined();
expect(req._context).not.toBeDefined();
});
const obj = new TestObject();
obj.set('_context', { hello: 'world' });
await obj.save(null, { context: { a: 'a' } });
}); |
No, because it doesn't test overriding.
This is the test I was thinking about. It would test that the context in body overrides the context in header. Since this seems to be expected behavior, I think it would be good to test it.
Wouldn't |
src/middlewares.js
Outdated
@@ -35,7 +35,7 @@ export function handleParseHeaders(req, res, next) { | |||
dotNetKey: req.get('X-Parse-Windows-Key'), | |||
restAPIKey: req.get('X-Parse-REST-API-Key'), | |||
clientVersion: req.get('X-Parse-Client-Version'), | |||
context: {}, | |||
context: req.get('X-Parse-Cloud-Context') == null ? {} : JSON.parse(req.get('X-Parse-Cloud-Context')), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we wrap JSON parsing into a try catch and throw an error if necessary? A malformed JSON string would throw an exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added this
This wouldn't set context in the header and therefore wouldn't override it, this is because JS uses this to set _context during a save here: https://github.com/parse-community/Parse-SDK-JS/blob/e6f15fdc09429a2c456ec6387d365914af8a8988/src/RESTController.js#L230-L234. From what I can see, JS doesn't seem to use headers at all and instead modifies the body for appId, context, etc. But I think I have a simple mod that will improve the code and test the overriding. |
I assume this would be a separate PR in the JS SDK. But wouldn't that be the behavior we aim for? The |
…ing body with json string
I didn't intend to create another PR for the JS SDK and not sure if that behavior should be changed since I'm not one of the maintainers of JS nor do I use it directly. Instead, on the server-side,
|
src/middlewares.js
Outdated
@@ -454,3 +469,8 @@ function invalidRequest(req, res) { | |||
res.status(403); | |||
res.end('{"error":"unauthorized"}'); | |||
} | |||
|
|||
function malformedContext(req, res) { | |||
res.status(500); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error is caused by a developer mistake, so it should be a 4xx response code.
I suggest 400 Bad Request
:
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to 400
. I'm assuming you only meant the status change?
@cbaker6 Is this ready for review / merge? I've lost track of this. Looking over it, it looks good to merge to me, just maybe add a few words to the change log entry so readers understand what this change is? |
Yes, this is ready to go |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks for this PR! Let's wait for a 2nd review approval...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me
* master: (55 commits) Accept context via header X-Parse-Cloud-Context (parse-community#7437) [Snyk] Upgrade ws from 7.4.6 to 7.5.3 (parse-community#7457) fix: upgrade @apollographql/graphql-playground-html from 1.6.28 to 1.6.29 (parse-community#7473) fix: upgrade @apollographql/graphql-playground-html from 1.6.27 to 1.6.28 (parse-community#7411) fix: upgrade graphql from 15.5.0 to 15.5.1 (parse-community#7462) [Snyk] Security upgrade parse from 3.2.0 to 3.3.0 (parse-community#7464) fix: upgrade apollo-server-express from 2.25.1 to 2.25.2 (parse-community#7465) fix: upgrade graphql-tag from 2.12.4 to 2.12.5 (parse-community#7466) fix: upgrade graphql-relay from 0.7.0 to 0.8.0 (parse-community#7467) Add MongoDB 5.0 support + bump CI env (parse-community#7469) changed twitter API endpoint for oauth test (parse-community#7472) add runtime deprecation warning (parse-community#7451) bumped node (parse-community#7452) fix: upgrade apollo-server-express from 2.25.0 to 2.25.1 (parse-community#7449) fix: upgrade subscriptions-transport-ws from 0.9.19 to 0.10.0 (parse-community#7450) fix: upgrade mongodb from 3.6.8 to 3.6.9 (parse-community#7445) fix: upgrade mongodb from 3.6.7 to 3.6.8 (parse-community#7430) fix: upgrade apollo-server-express from 2.24.1 to 2.25.0 (parse-community#7435) fix: upgrade ldapjs from 2.2.4 to 2.3.0 (parse-community#7436) fix: upgrade graphql-relay from 0.6.0 to 0.7.0 (parse-community#7443) ...
Thanks for opening this pull request!
|
🎉 This change has been released in version 5.0.0-beta.1 |
🎉 This change has been released in version 5.0.0 |
New Pull Request Checklist
Issue Description
Related issue: Currently
context
is setup to accept an object in the header, but no header is available. This allows client SDK's to add context via a header instead of injecting_context
in the body of JSON object, forcing the parse-server to have to delete it in middleware. Close #7438Approach
Add a new header for content called
X-Parse-Cloud-Context
.TODOs before merging