Skip to content
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

Closed
rpattcorner opened this issue Nov 10, 2020 · 3 comments
Closed

/signoff logs and debugging #94

rpattcorner opened this issue Nov 10, 2020 · 3 comments

Comments

@rpattcorner
Copy link
Contributor

rpattcorner commented Nov 10, 2020

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:

  1. App or user hits the /signout URL
  2. Cloudfront intercepts and sends request to the lambda@edge configured for the /signout Behaviour
  3. Lambda@edge neuters/kills authentication cookies and invokes logout on Cognito
  4. Cognito app client finds the signout URL and redirects there (actually set to the front page of the app)
  5. CheckAuth or ParseAuth (I forget which) intercept the redirect, fail because neutered cookies, and send to Cognito login

What we see is:

  • App signs in successfully
  • App signs out by redirecting to the /signout behaviour configured in CloudFront, e.g. var url = "https://"+host+'/signout'; window.location = url
  • Cloudfront points at a versioned lambda@edge for signout. The console shows no versioning on that lambda, which may just mean that versioning on the edge doesn't show in the GUI ... or it may be a problem
  • In the App we get a confusing range of failures from a CSP fail referencing a nonexistent Cognito image to (when allowing that in policy) a CORB block Cross-Origin Read Blocking (CORB) blocked cross-origin response https://auth-2dc...
  • A simple refresh brings up Cognito authentication screen and all is well

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.

@rpattcorner
Copy link
Contributor Author

rpattcorner commented Nov 11, 2020

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

@ottokruse
Copy link
Collaborator

You captured the signout chain correctly. Allow me to add more detail to a few things:

  1. App or user hits the /signout URL
  2. Cloudfront intercepts and invokes the lambda@edge function configured for the /signout behaviour
  3. That lambda@edge function returns a response to the user's browser that (1) clears the cookies, nuking the auth tokens, (2) redirects to the Cognito sign-out URL, so the user is also signed out from Cognito (see below) and (3) includes in the URL query parameters a "logout_uri"
  4. Cognito signs the user out, validates that the "logout_uri" matches one of the configured ones for the App Client, and redirects to this logout_uri (which can be the root of the Auth@Edge app, which would trigger sign-in again)

About signing out from Cognito

You need to do this for 2 reasons:

  • You need to void the refresh token at Cognito so it can no longer be used to acquire new ID and Access tokens with
  • If you sign-in successfully through the Cognito hosted UI, it remembers you signed in there for a while (1 hour from the top of my head) and will sign you in again without asking for credentials in that hour. So if you want to sign out you should tell Cognito to sign you out (so that Cognito will ask your credentials again next time)

About accessing Lambda@Edge logs

This 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.

@rpattcorner
Copy link
Contributor Author

@ottokruse Many thanks for this! Great to get some clarity on the logs and the signout chain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants