aws-sam-cli: sam local start-api Missing Authentication Token for root path '/'

By adding a root endpoint and another separate proxy endpoint to the SAM template I was able to get it to work:

...
Resources:
  MyFunction:
    Properties:
      CodeUri: MyFunction
      Events:
        RootEndpoint:
          Properties:
            Method: any
            Path: /
          Type: Api
        EverythingElse:
          Properties:
            Method: any
            Path: /{proxy+}
          Type: Api
      Handler: app.lambda_handler
      Runtime: python3.7
    Type: AWS::Serverless::Function

It seems like this convention of configuring multiple events for the same handler is done this way in other frameworks such as Zappa and Serverless (see the serverless.yml from this link).

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)

@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.

Well in fairness, they have done ALOT of work and if I had to pick, I’d say I appreciate the effort being able to run Ruby on Lambda and other things vs something I can hack locally that is not an issue when deployed. That said, would be nice to see fixed.

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

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

CONFIRMED! Setting static_url_path=None in local_apigw_service.py does allow /{proxy+} to work. I have confirmed with Flask that these two options are incompatible. I think it is important that local development allow root proxy and serving static files from root needs to be re-considered. What do other’s think?