- Newest
- Most votes
- Most comments
-
Authorizer not triggered on
$connectroute: For WebSocket APIs, the custom authorizer only runs on the$connectroute. Make sure you have explicitly set theAuthorizationTypeandAuthorizerIdon the$connectroute. If it's missing or misconfigured, the authorizer won’t be triggered. -
route.request.querystring.tokennot passed in test: When usingwscatto 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::Permissionblock set up, but double-check that!Ref AuthFunctionis 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 --guidedand 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
$connectroute 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
$connectlambda function is a reasonable workaround. You can manually decode and validate the JWT there using a library likepython-jose.
answered a year ago
Relevant content
asked 3 years ago
asked 3 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 10 months ago
