UnauthorisedError behaviour is different between my two tenants

Help
1

My existing tenant A redirect users to the tenant defined error page. my new test tenant just passes the error back to the calling application. I can’t find how I managed the change the behaviour in the exisiting tenant.

Can someone please advise how you change the behaviour of a new UnauthorisedError in terms of where it redirects users too please. Thanks

3

Hi @james.daniels,

Happy cake day!

Can you DM me the tenant names?

Thanks,
Dan

4

Hi Dan,

So I worked this out. I had put logic into the original tenants first party connect app to handle the redirection on an error response from the Auth0 /Authorise endpoint.

I’ve kind of gone full circle don’t feel like I have found a good solution to the problem I am trying to solve. Could you add any thoughts?

Essentially, I want a better User experience on first login when they haven’t yet verified their email

  • Users sign up using the Universal Hosted Lock (Classic)

  • This triggers the first login which will always fail because…

  • A rule asserts that the user has not verified and therefore throws a Unauthorized error.

  • this is passed back to the calling app

We have multiple Apps and therefore multiple “entry” points for users to first sign up. Given the way it works today I must test and cater for each app route that a user could sign up from.

I’d prefer that after sign-up the user is sent to a holding page. Informing them they are not yet verified and to click “continue” once they have clicked the verification link sent to them.

Is there any clean easy way to have this type of generic error/holding page all within the Auth0 tenant?

5

There is no hosted error page for this error. How are you forcing email verification? Through a rule like this?

6

Yes that’s right.

I’m trying to find a way where the kick back from that rule doesn’t become the calling Apps concern and can be managed centrally in Auth0.

I tried instead changing that rule to a redirect to a page I hosted that essentially told the user they needed to verify and a continue button that called the /continue endpoint.

However I assumed that would run all rules again and if they still weren’t verified it would just redirect again. Alas it seems to only permit 1 redirect per authentication attempt so it ignores the second rule evaluation. Dead end on that one.

1 Like
7

@james.daniels,

That would have been my next suggestion. Let me check with the team and see how this is usually handled.

I’ll update here with their response.

8

Okay I checked with a solutions architect and they said the redirect should be the way to go. Are you experiencing a situation where the rule is being skipped?

9

What I’ve found is consistent with this Redirect Users from Within Rules

Where it says

You can redirect a user once per authentication flow. If you have one rule that redirects a user, you cannot invoke a second rule to redirect the user at a later time.

So:

  1. Users Hits our application. Application redirects user to /authorise
  2. User Signs up and begins a authentication flow
  3. Rule fires and asserts that user is not yet verified and makes the redirect
  4. User lands on holding page that says they need to verifiy and once done click continue
  5. User doesn’t verifiy and just clicks continue
  6. User is sent to the /continue endpoint
  7. Rules fire again but it appears to ignore the rule that says if not verified then redirect to holding page because I think we are still part of the same authentication flow.
  8. User is now logged in to our application.

Does that match with what the architect expects?

10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.