Auth0 Home Blog Docs

Internal Server Error using Lock at June 8 12:04 AM EDT

lock

#1

Hi,
At June 8 12:04 AM EDT a customer reported an Internal Server Error during the logo n process using Lock. Please see screenshot below. Can someone please advise if this is an auth0 issue and what we need to do about it. No errors resulted in our Error Logs so A. we need to ensure it is logged and B. we need to know what caused it and C. we need to know how to handle it nicely for our users and D. we need to determine how to avoid such issues in the future.
The complication here seems to be that this process is owned by Lock, not us.
Kind regards
Mark Easton
www.flowingly.io
![alt text][1]


#2

That screenshot indicates that Auth0 had redirected back to your application as expected (access_token and id_token in the URL hash) - it seems to be an issue in inside your application, rather than an Auth0 issue.

Unfortunately that error does not tell us much. You will need to try reproducing this or obtain additional information from the user about the steps they took, to try reproducing this.


#3

Hi prashant. We use Auth0 Lock. So yes it had redirected back to our application - but our application is Lock. Our own code does not deal with the specific arguments in that query string.


#4

We use Lock on client side.


#5

Hi prashant. We use Auth0 Lock. So yes it had redirected back to our application - but our application is Lock. Our own code does not deal with the specific arguments in that query string.


#6

Even with Lock, your application need to handle the authenticated event:

// Listening for the authenticated event
lock.on("authenticated", function(authResult) {
  // Use the token in authResult to getUserInfo() and save it to localStorage
  lock.getUserInfo(authResult.accessToken, function(error, profile) {
    if (error) {
      // Handle error
      return;
    }
    localStorage.setItem('accessToken', authResult.accessToken);
    localStorage.setItem('profile', JSON.stringify(profile));
  });
});

https://auth0.com/docs/libraries/lock/v10#implementing-lock

In saying that, errors in this would not throw an Internal Server Error for your entire app. Capturing a HAR file would help diagnose this: http://auth0.com/docs/har. Please remove any sensitive info, including passwords, before sending it through.


#7

I appreciate your response. Many thanks.
The http://auth0.com/docs/har link is broken.

Yes we handle the authenticated event - we have a very mature lock-based solution that we have worked with and fine-tuned over the lat year. In this case it had not reached the authenticated event and an Internal Server Error was thrown - not by our server. SO I politely suggest that it was thrown by auth0. We have only had one instance of this Internal Server Error. Roughly at that same time Auth0 was having a technical issue - so I am wondering if that resulted in the Internal Server Error.

Our solution works perfectly well - and so we are unlikely to get a repeat of this issue so we cant offer you data.

Have I got this wrong somehow? I am being asked at my company for answers, in case it should happen again. I have no Internal Server Error in our logs and we had not yet received the authenticated event from Lock (as also evidenced in our logs) and from the URL you can see in the screenshot of the issue the user had, and the lock and auth0 client side code I have looked at, I can see it was in the middle of the authentication process. So it was yet to throw us the authenticated event.

Your thoughts please.


#8