- Newest
- Most votes
- Most comments
-
Authorizer not triggered on
$connect
route: For WebSocket APIs, the custom authorizer only runs on the$connect
route. Make sure you have explicitly set theAuthorizationType
andAuthorizerId
on the$connect
route. If it's missing or misconfigured, the authorizer won’t be triggered. -
route.request.querystring.token
not passed in test: When usingwscat
to connect, you must include the token in the URL query string exactly as defined inIdentitySource
. For example:wscat -c "wss://MY_API.execute-api.REGION.amazonaws.com/STAGE?token=eyJraWQiOi..."
If the query param is missing or misnamed, the authorizer won't be called and the connection may be allowed.
-
IAM permissions for
InvokeFunction
: You have theAWS::Lambda::Permission
block set up, but double-check that!Ref AuthFunction
is actually resolving to the correct function name and that it includes the full ARN (especially if you're referencing it from another region or stack). -
Check deployment and stage configuration: Sometimes changes don’t propagate unless you redeploy both the API and the stage. Try running:
sam deploy --guided
and ensure the deployment updates are actually applied to the correct stage.
-
CloudWatch logging not showing anything: This suggests that the authorizer lambda isn't being invoked at all. Reconfirm the
$connect
route is configured with the authorizer and redeploy. Also, verify that logging is enabled for the WebSocket API stage. -
Fallback approach: If you're still running into a wall and are short on time, placing the token verification logic inside the
$connect
lambda function is a reasonable workaround. You can manually decode and validate the JWT there using a library likepython-jose
.
Relevant content
- asked 2 years ago
- asked 2 years ago
- AWS OFFICIALUpdated 4 months ago