-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
/signoff logs and debugging #94
Comments
Leaving this open in hopes of gathering some more general information on debugging the lambdas and the apparent absence of logs under some conditions. But may have found a specific resolution. There seems to be some chance that unwanted cookie persistence is involved here -- and in a development and testing environment you get a lot of those. I've recently cleared the Cognito Identity id token, which resolves the problem in at least one case. Details in #95 |
You captured the signout chain correctly. Allow me to add more detail to a few things:
About signing out from CognitoYou need to do this for 2 reasons:
About accessing Lambda@Edge logsThis is different from "normal" Lambda. Assuming a lambda with the name "abc" it would normally write to log group "/aws/lambda/abc" in the same region as the Lambda -- but this is not so for Lambda@Edge. So for Lambda@Edge, the link in the Lambda UI that takes you to the log group would actually always show you "The specified log group does not exist" ––as you've found. For Lambda@Edge the log group will be in the region where the Lambda@Edge function was executed (which can be any region on the Globe), and will have a name like so: /aws/lambda/us-east-1.abc The easiest way to locate the right log group and the right region, is to use the CloudFront monitoring dashboard (https://console.aws.amazon.com/cloudfront/v2/home#/monitoring) and navigate to the lambda function logs in the right region, from there. Hope that helps. |
@ottokruse Many thanks for this! Great to get some clarity on the logs and the signout chain |
We're having some problems debugging the /signout functionality, which isn't described quite as thoroughly in the blog as the authorization scenarios.
Let me start with my understanding of the /signout chain, which may be incorrect:
What we see is:
var url = "https://"+host+'/signout'; window.location = url
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://auth-2dc...
The immediate issue is that I can't seem to see the CloudWatch logs for the /signout lambda@edge. The lambda is present in the function list, and accessing its CW logs the easy way via console/monitoring tab/view logs in cloudwatch yields
The specific log group: /aws/lambda/...-LambdaEdgeProte-SignOutHandler-12345 does not exist in this account or region.
A closer look at the CW logs directly specifying the Lambda function name yields some logs but they are old with respect to the run in question and contain only start/end messages anyway.
I've seen the 'logs don't exist' scenario in a few different debug situations and wonder how this happens?
I also note that all of the lambda@edge functions for this application have the same version. We regularly update the lambdas in debugging, usually modifying the CSP headers. Do all the lambdas update in sync with any change to the a@edge?
Looking for hints to debug these kinds of scenarios where a lambda might be the issue but it leaves no logs we can reach to see what happened.
Logged a call with AWS, who believe this is an a@edge issue.
The text was updated successfully, but these errors were encountered: