Skip to content
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

Updating the lambda handler to handle invalid JSON body #3108

Closed

Conversation

danperkins
Copy link

@danperkins danperkins commented Jul 30, 2019

We hit this recently after posting our service endpoints for external security testing. Instead of the lambda throwing exceptions and those getting wrapped in 502 - Internal Server Error responses I updated the handler to return a more helpful 400 response.
***Related to #727
Not every handler seems to deal with this the same way, so I just added a unit test that some error code in the 400-500 range should be returned instead of getting an unhandled exception. This seems to work in every scenario except that in the azure test I had to specifically handle parsing the body - I'm guessing that azure is going to take care of this on their side since this code was written specifically for the unit test

@apollo-cla
Copy link

@danperkins: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

@danperkins danperkins force-pushed the lambda-safe-json-parsing branch from 9bffdda to babc688 Compare July 30, 2019 16:09
@danperkins danperkins force-pushed the lambda-safe-json-parsing branch from babc688 to 47dfb1d Compare July 30, 2019 16:26
@@ -25,9 +25,12 @@ const createAzureFunction = (options: CreateAppOptions = {}) => {
req.on('data', chunk => (body += chunk));
req.on('end', () => {
const urlObject = url.parse(req.url, true);
try {
body = JSON.parse(body);
} catch (e) {}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should something be logged here for debugging purposes? Maybe at a low log level?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only saw one other place in the tests where console logs are being used and it seemed to be more for debugging a failed 'expect' validation. I don't think it makes sense to add logging for a case that will always be hit for a specific test case

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I misunderstood what was happening. I did not realize this was a testcase. 🤦‍♂

@dsanders11
Copy link

@danperkins, @mdlavin, how will this interact with #1739? I don't think that's close to being merged (it's stalled out), but there's a comment (https://github.com/apollographql/apollo-server/pull/1739/files#r267636555) that mentions that for file uploads to be implemented for apollo-server-lambda it'll need to be able to handle non-JSON payloads.

Could this be tweaked to only try parsing the body as JSON if the Content-Type header is application/json? For now it could also return an error if it's a different Content-Type, but this would leave a cleaner hook for file upload when it comes to apollo-server-lambda.

@danperkins
Copy link
Author

@dsanders11 should be pretty easy for that branch to pull in this change - they would just wrap the JSON.parse call in a try/catch like I did here. They even already have the code pulled out of the runHttpQuery call just like in this branch

@abernix abernix closed this Jun 24, 2020
@abernix abernix reopened this Jun 25, 2020
@abernix abernix changed the base branch from master to main June 25, 2020 09:04
@jbszczepaniak
Copy link

Is there any update on this issue? I would love that to be merged!

@glasser
Copy link
Member

glasser commented Oct 4, 2022

The Lambda handler was completely rewritten in AS3 last year (it no longer parses its own JSON), and support for Lambda will be maintained by the community rather than in core starting with AS4 (currently Release Candidate), so this no longer applies. Sorry for the delay!

@glasser glasser closed this Oct 4, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants