opened
tgjorgoski
username_0
## What did you implement:

Closes #3129

Explanation of the issue:
In  the `authorizer` section of the `http` event, the `arn` parameter serves double role:
-If it refers to arn of a lambda, then it is assumed that the lambda is a custom authorizer
-if on another hand it refres to arn of a cognito user pool (which is checked by parsing the arn), it is assumed that we want the default cognito pool authorizer.
So, when someone tries to use Fn::Import or Ref , it is impossible for the parser to figure out which of those two is the case

## How did you implement it:

I added possibility for the user to specify `poolarn` parameter. So they can explicitly state that they want to use Default Cognito Authorizer. and beside the hardcoded arn, now they can use  Fn::Import or Ref. 

## How can we verify it:

Export Cognito Pool Arn as part of another cloud formation stack , for example with name `Example-UserPool`.
After that in the serverless.yml use something like the following configuration:
 ```
  functionX:
    handler: handler.functionX
    events:
      - http:
          path: functionx
          method: get
          integration: lambda
          cors: true
          authorizer:
            poolarn:
              "Fn::ImportValue": Example-UserPool
            name: RandomAuthorizerName
            claims:
              - email
```
Observe that the Default Authorizer is properly set for the functionx endpoint.

## NOTE

I didn't write the tests yet, because I'm not sure if this way of fixing the problem is acceptable. 
If it is acceptable, I will go ahead and write the tests.
Also there will be need to update the documentation.

## Todos:

- [ ] Write tests
- [ ] Write documentation
- [x] Fix linting errors
- [ ] Make sure code coverage hasn't dropped
- [x] Provide verification config / commands / resources
- [x] Enable "Allow edits from maintainers" for this PR
- [x] Update the messages below

***Is this ready for review?:*** YES
***Is it a breaking change?:*** NO
Allow "Fn::ImportValue" to specify the pool for API GW Default Authorizer (Fixes #3129)
issue
created
eahefnawy
username_1
Hey @username_0 thanks for jumping into this. I'm a little worried about merging this PR because imo the fix seems fragile and might affect other more critical parts of the code, and it'd take a substantial amount of effort to come up and maintain a better solution.

The usecase itself is very specific and doesn't seem to serve a big pool of users, while at the same time complicates the config file, which is something we always strive to avoid (we strive for simplicity). We kept it open for a while for feedback, but it seems it's not an issue for a big majority of the users. So I'm gonna close this PR. I hope you understand 😊
comment
created
tgjorgoski
username_0
I was experimenting with the configuration myself, so I needed it. Not glad that I will have to keep separate fork for this, but I do understand your logic.
comment