Open armonge opened 5 years ago
afaik, the response for the password authorizer is correct, it should return the token id as principal id...
Sorry, I meant usageIdentifierKey
. That is used to identify which token is used:
The output is actually correct, the fact that you get a Forbidden
instead of Unauthorized
means that api gateway actually accepted the response as well...
You can check if this is not a problem with your backend through the "Test" feature in api gateway, there you can see if the problem is still there when access the backend directly, as this bypasses the custom authorizer.
Interestingly enough, the API gateway and the application work correctly (minus auth of course) when i remove the serverless-basic-authentication plugin. I also tested using the "Test" feature and serverless-basic-authentication enabled, the API Gateway response is the one i'm expecting from my backend
Also, even with serverless-basic-authentication enabled the backend does produce the expected result when using the x-api-key header.
http https://something.execute-api.eu-west-1.amazonaws.com/dev/ x-api-key:good-pass
The issue only happens with 'Basic Auth'
i am having similar issue. with plugin attached, all existing endpoints that have private: true
in function definition return {message: null}
after 30 seconds, and all inexisting endpoints return this interesting message:
{"message":"Authorization header requires 'Credential' parameter.
Authorization header requires 'Signature' parameter.
Authorization header requires 'SignedHeaders' parameter.
Authorization header requires existence of either
a 'X-Amz-Date' or a 'Date' header.
Authorization=Basic Zm9vYmFyOg=="}
i have decrypted this base64 string Zm9vYmFyOg==
and it is foobar:
- i definitely have no such string in my codebase.
I'm trying to use the plugin for some simple auth in a quick flask project. However for some reason i can't get the basic auth to work. For now it's only working when using the
x-api-key
headerInterestingly seems like there is a change when using a wrong password, meaning the plugin is indeed checking for the password
In the case i use a correct password the response changes from "Unauthorized" to "Forbidden"
This are the logs i'm getting from the basic_auth lambda
And this is the result i get when using
x-api-key
With the corresponding logs:
The only difference i can find is the
principalId
valueFor reference here's my serverless.yml