-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Problem with OPTIONS requests #400
Comments
I'm having the same problem after upgrading AWS SAM to v0.3.0. My |
@charsleysa What do you mean by "but it's not returning the configuration specified in my template file"? I did a quick test with a function defined through an Events structure for only options and see the data being displayed that was returned from the Local Lambda Function. |
@jfuss well I saw some code related to CORS in the rewrite so I assumed there was support for CORS because for the I have CORS configured in my template but the result being returned by the SAM CLI API Gateway does not contain any Headers which match my CORS configuration. As mentioned above, this issue doesn't seem to affect all functions, in fact it seems to only affect the first function defined in the template. All other functions defined in the template execute the Lambda when an |
@charsleysa How did you validate that the wrong local Lambda was being called? Did you see unexpected results or just looking at output? If you are looking at the output logs, what you are seeing is expected. Logs are printed before the log for the request. Flask logs the request after it is handled. Not sure what you are referring to about code related to CORS. We don't currently parse any data for CORS, even though it is in the object: https://github.com/awslabs/aws-sam-cli/blob/develop/samcli/commands/local/lib/sam_api_provider.py#L443 Options works but only returns the data that is returned from the Local Lambda, which is expected. We currently do not support CORS (neither did version previous to 0.3.0). Please follow #323 for CORS support. |
@jfuss thank you for confirming that there is no CORS support. This means there is a bug in the execution of my Lambda as my handler is never executed. If you take a look at the debug details from my original post you will see the following line: The response received by the browser was an empty 200 with no CORS Headers. EDIT: |
@charsleysa Have you had any luck with this issue? I'm still struggling with it--it's simply not obeying most of my |
@hobotroid still no luck. Haven't managed to figure out why some work and some don't, it feels random but it's not because it only affects specific functions but when I check their config I can't find anything that could be causing it. This new version is definitely a pain as another feature that 0.2.x had (and seems like it was undocumented) is no longer available (the feature was passing CloudFormation parameter values to the start API command). |
@charsleysa Yes, I spent hours trying to get all my OPTIONS rules to work. But at best I could get 75%. It has something to do with the path parsing, but I still can't figured out exactly what. |
@hobotroid Again there is no CORS support currently. OPTIONS behaves the same as GET or any other of the HTTP verbs. If this is not the case, please give us more details so we can reproduce. As it stands, I have not been able to observe any incorrect behavior, that is when I return a proxy response from a lambda through an OPTIONS verb, I get the correct response as the caller. @charsleysa Make sure the debugger is setup correctly. If you are using VS code, you need to be setting the debugger to legacy, if I recall correctly. If you are seeing issues with the debugger, please file a separate issue. As for the CloudFormation Parameter values, are you are needing/wanting to override values in the Env Vars? If so, you can still pass |
@jfuss I have the debugger setup correctly. As I mentioned in my previous posts, when I make From my template, the I can see no reason why both endpoints are not responding the same as they should. I will update the title of this issue to better reflect the problem. |
Thanks @jfuss! Yeah, I'm simply trying to do custom responses to I have multiple |
Finally, got the root cause here. This is a bug on our end and was pretty difficult to find. I pulled the head of master locally (equivalent to 0.3.0) and after some long digging found this while inspecting the Flask
You can see OPTIONS is getting added to every request but there are many rules for each endpoint. The many rules is fine (just caused by the way we define a route). The interesting thing is, why does OPTIONS get appended to every route. Well in Flask 0.8, a There are a couple things, I think we need to do here:
@charsleysa I apologize for not going deeper into this originally. The reason I didn't catch this in the first place was due to not completely keeping the template the same (I scoped this down to make it easier for me to understand but didn't keep the Updating Labels to reflect current state. |
Great find @jfuss! I was able to narrow down the bug to a single AWSTemplateFormatVersion : '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Globals:
Function:
Runtime: nodejs6.10
Timeout: 10
Resources:
VerifyUserFunction:
Type: AWS::Serverless::Function
Properties:
Handler: handlers/VerifyUser.handler
Policies: AmazonDynamoDBFullAccess
Events:
VerifyUser:
Type: Api
Properties:
Path: /users/verify/{token}
Method: GET
VerifyUserOptionsFunction:
Type: AWS::Serverless::Function
Properties:
Handler: handlers/Options.handler
Policies: AmazonDynamoDBFullAccess
Events:
verifyUserOptions:
Type: Api
Properties:
Path: /users/verify/{token}
Method: OPTIONS The |
@jfuss thanks for your work in finding the problem! That definitely was a hidden one. @hobotroid thanks for your help as well! |
@jfuss Out of curiosity, is there a workaround for this that I can use until the fix comes out? Some way to just force all |
+1. Reverting to an older version of |
Reopening. This will be addressed in #468 |
This was released as apart of v0.4.0 Closing |
I am using sam 0.5.0, and I am getting
|
Same here, getting
|
I think the previous flask fix regressed. Getting automatic OPTIONS again in 0.6.1 |
Re-opening. @mohammedzamakhan, @skix123, or @meza: We haven't change anything with Flask or the |
Not sure if this is relevant or not but I landed on this issue from and I didn't know if this merits a new issue so I'm adding it here (apologizes if it's not relevant) I was getting this issue when running
My template looks like this: AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
visitor-forms
Handles the submission of the "forms" droplet in any site
Resources:
VisitorFormsFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: .
Handler: index.handler
Runtime: nodejs8.10
Events:
Submission:
Type: Api
Properties:
Path: /
Method: post
Outputs:
VisitorFormsApi:
Description: "API Gateway endpoint URL for Prod stage for VisitorForms function"
Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/VisitorForms/"
VisitorFormsFunction:
Description: "VisitorForms Lambda Function ARN"
Value: !GetAtt VisitorFormsFunction.Arn
VisitorFormsFunctionIamRole:
Description: "Implicit IAM Role created for VisitorForms function"
Value: !GetAtt VisitorFormsFunctionRole.Arn
Even though my sam version matches last release, I figured I'll do the ol' reinstall to see if that fixes it, ... which it appeared to do so. Looks like new version of Flask was pulled down
I thought this might help with issue |
@andres-lowrie For whatever reason, the Flask version of 1.0.2 wasn't getting picked up. This is something wrong with the installation on your system. If you are currently using pip to install, I would uninstall the CLI ( |
Ty.. will do |
Hi, I've got the same issue. Getting 403 for OPTIONS requests to my graphql endpoint for sam local. Is there any work around for this at the moment? CLI version 0.10.0 |
@rayhaanq Give this a try in your cloudformation
|
@cl0ckwork awesome, this worked. I just set up another function for options to return a success response. Thanks |
Finally make it work after a long day suffer from this issue. It's a good idea to write another lambda for options method which response successful pre-light check. I didn't notice that AWS has mentioned it in their docs |
yeah but requests are too slow in local |
Tracking issue for CORS is #323. See that issue for more details. The original request here was Flask responding to OPTIONS requests which was solved and release: #400 (comment) There was addition reports of Flask still responding here: #400 (comment) but no response from those parties. Closing at this looks to be solved and other comments relate to CORS support, which has it's own issue |
@jfuss I've still got this problem with sam 0.22.0 (from brew) and a CDK-generated template. See my repro repo. SAM shows that the lambda is not executed for an OPTIONS request, but is for a GET:
|
Though #1434 seems to reproduce it more easily. Should have checked for more recent issues first. I'll follow that issue. |
Description:
Trying to access my API from a test app in my browser and the
OPTIONS
request is being handled by SAM CLI API Gateway but it's not returning the configuration specified in my template file.The weird part is that if I try to access a different endpoint from the same template it executes the lambda function (as expected since that's what SAM Local did).
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
Mac
Output of
sam --version
:SAM CLI, version 0.3.0
Optional Debug logs:
Template file for reference
The text was updated successfully, but these errors were encountered: