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

sam local start-api Missing Authentication Token #437

Open
0xdevalias opened this Issue May 24, 2018 · 11 comments

Comments

Projects
None yet
6 participants
@0xdevalias

0xdevalias commented May 24, 2018

Description:

When I run sam local start-api -s public/ and try to access my endpoint, I receive a Missing Authentication Token in the browser. This same code runs fine when deployed to lambda, and correctly exposes my endpoint without auth required.

FOO:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub ${AWS::StackName}-FOO
      CodeUri: ./target
      Handler: foo
      Runtime: go1.x
      Tracing: Active
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: "/{proxy+}"
            Method: ANY

Observed result:

Missing Authentication Token

Expected result:

My API is exposed without auth.

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

macOS

Output of sam --version:

SAM CLI, version 0.3.0

@0xdevalias

This comment has been minimized.

0xdevalias commented May 24, 2018

Starting from scratch for debug:

sam init --runtime go1.x
cd sam-app
dep init
GOOS=linux GOARCH=amd64 go build -o hello-world/hello-world ./hello-world
sam local start-api

Attempting to access http://127.0.0.1:3000/ I see Missing Authentication Token (with no endpoint mapped there)
Attempting to access http://127.0.0.1:3000/hello it works as expected.

Changing the HelloWorldFunction to use /{proxy+}:

HelloWorldFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      CodeUri: hello-world/
      Handler: hello-world
      Runtime: go1.x
      Tracing: Active # https://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.html
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: "/{proxy+}"
            Method: ANY
      Environment: # More info about Env Vars: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#environment-object
        Variables:
          PARAM1: VALUE

Now when I access http://127.0.0.1:3000/anythinghere it continues to work as expected.. so I don't think that is my issue.

Edit: Digging a little deeper.. it looks like even if I explicitly set the path to Path: "/" I get the same Missing Authentication Token when trying to access it. I wonder if that is somehow playing into this issue, even when trying to proxy it?

Edit2: Additional context, using https://github.com/gorilla/mux + https://github.com/awslabs/aws-lambda-go-api-proxy internally. When I set the path to Path: "/example" in my main project, that 1 endpoint works properly and doesn't produce Missing Authentication Token. When it is set to proxy though, my code never even gets reached/started. If I set my project to Path: "/a/{proxy+}" and try to access any of the URLs, my code starts correctly (then gets a 404 because that route doesn't exist)

@terrywarwar

This comment has been minimized.

terrywarwar commented Jun 20, 2018

I'm getting the same error with SAM CLI, version 0.4.0. It doesn't look like it's routing to the static files in my case.

2018-06-20 14:50:36 Mounting static files from /Users/terry/go/src/app/public at /
2018-06-20 14:50:36 Mounting SampleFunction at http://127.0.0.1:3000/api/{proxy+} [GET, DELETE, PUT, POST, HEAD, OPTIONS, PATCH]
2018-06-20 14:50:36 You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template
2018-06-20 14:50:36  * Running on http://127.0.0.1:3000/ (Press CTRL+C to quit)
2018-06-20 14:50:42 127.0.0.1 - - [20/Jun/2018 14:50:42] "GET / HTTP/1.1" 403 -
2018-06-20 14:50:42 127.0.0.1 - - [20/Jun/2018 14:50:42] "GET /favicon.ico HTTP/1.1" 403 -
@terrywarwar

This comment has been minimized.

terrywarwar commented Jun 23, 2018

Shouldn't localhost:3000 -> serves the index.html?

@jfuss

This comment has been minimized.

Contributor

jfuss commented Jul 18, 2018

So this is an issue with Flask and how the endpoints are modeled. By default Flask does not resolve the / as apart of the /{proxy+} route. This means we need to handle / (the root path) separately. There maybe a way to configure this behavior by default but haven't investigated that deeply yet.

@terrywarwar

Shouldn't localhost:3000 -> serves the index.html?

Maybe? But SAM CLI can't since we support API to Lambda on the same root path, so there can be path conflicts. Instead, you should just add the /index.html to the path explicitly.

Marking this as a bug

@amcp

This comment has been minimized.

amcp commented Aug 15, 2018

I am getting this issue only on GET calls. POST works fine.

@tomasaschan

This comment has been minimized.

tomasaschan commented Nov 27, 2018

@amcp I'm seeing the opposite; GET works fine, while POST yields this error. None of my paths are /, i.e. I'm GETting and POSTing to e.g. /foo and /bar.

Windows 10, SAM CLI version 0.7.0.

@nealio82

This comment has been minimized.

nealio82 commented Dec 10, 2018

I'm experiencing the same. Using SAM local POST works fine, but GET returns the "missing authentication token" on all catch-all routes, unless I add the first part of the route into the template.yaml config.

eg:

using path: /{proxy+}, method: ANY

GET /api/books, and /api/books/[id] returns missing authentication token

whereas using path: /api/{proxy+}, method: ANY

GET /api/books, and /api/books/[id] work as expected

Both configurations appear to work normally once deployed to the cloud.

I think this is going to become more prevalent as an issue now the runtime API has opened new languages and frameworks up to Lambda, and more people are going to get on-board with developing serverless functions locally, expecting their chosen language / framework to handle routing for them.

MacOS, SAM CLI version 0.8.1

@jfuss

This comment has been minimized.

Contributor

jfuss commented Dec 10, 2018

@nealio82 While the results are the same, your issue is different than the original issue. I commented above on what this issue relates to.

Please open a separate issues so we can track and investigate separately.

@nealio82

This comment has been minimized.

nealio82 commented Dec 10, 2018

@jfuss Ok, shall do :) Although I'm not sure that it is different? Looking at the original bug report by @0xdevalias it looks like the config is almost exactly the same as the config I have, and their experience is the same... (the only difference I can see is that I also have path: / configured in my template.yaml to match the / route, and @0xdevalias doesn't)

@jfuss

This comment has been minimized.

Contributor

jfuss commented Dec 10, 2018

@nealio82 You didn't state anything about a root path (/) being configured. Your statement makes it sound like /{proxy+} is causing other paths not to resolve.

@nealio82

This comment has been minimized.

nealio82 commented Dec 10, 2018

Ah, sorry, I didn't think it was relevant - I was adding context to the fact I'm seeing the same as the OP, and I didn't want to simply add an unhelpful '+1' or 'me too' comment. The root path works OK, as implied by 'GET returns the "missing authentication token" on all catch-all routes'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment