Provide more error details when calling `checkSession()`

Describe the problem you’d like to have solved

I want a more precise error to be returned from the checkSession() helper on the frontend. Right now it just returns a generic error, and doesn’t say why the session failed to be checked.

This has important implications for my app, where we are using the checkSession() function to decide if we should automatically log out a user. In particular, we cannot distinguish if it failed because the user’s internet connection cut, or if it really received a 401 when calling /api/auth/me. As a result, we’ve been logging people out even when we don’t need to, causing a degraded experience.

Describe the ideal solution

Ideally we’d have an enum of values that says exactly what the error was:

enum CheckSessionErrorType {
  NETWORK_REQUEST_FAILURE,
  SESSION_EXPIRED,
  INTERNAL_SERVER_ERROR,
  // ...
}

And then we can act based on that. Another option is to have the checkSession() function return more details of why checking the session failed. For example, A) if the fetch itself ran into a network error; B) what the status code was when the session check failed, C) any details from the body. This is not as good since it would tie us to whatever the scheme for fetching the data is at the time of integration, whereas a thorough enum would put the burden of keeping it up-to-date in the library, which makes more sense to me.

Alternatives and current work-arounds

• Just call /api/auth/me ourselves and forego the checkSession() helper.
• as @adamjmcgrath described, checkwindow.navigator.onLine before logging people out

Additional information, if any

In our application, we use Auth0 to handle authentication, and Hasura to access data on our database, via Webhook Authentication. What that means is, our Hasura server will forward the user’s headers when they made the API request to a webhook on our server, and our server will respond with headers that Hasura can use to authenticate the user.

The problem is that if the session is expired, then the webhook will just return that the user isn’t logged in at all. Then, Hasura will try to execute an API call that requires authentication, but will have no credentials, so it will fail. But the way that Hasura fails is not to return a 401 or something similar, but instead to say that the API endpoint that the user wished to use literally doesn’t exist.

The result is that on Hasura’s end, we don’t have a clear way to distinguish if the invocation was bad, or if the session expired. So we end up needing to check it ourselves. That’s why we turned to checkSession(), but it turns out that checkSession() can return failures that don’t actually indicate session expiry, hence this problem.

[adamjmcgrath]

HI @osdiab - correct, this got fixed in 1.8

[osdiab]

I just saw that this PR happened: https://github.com/auth0/nextjs-auth0/pull/639

I’m guessing that if I do a version bump this might not happen anymore. is that the case?