How to Return to the Signup or Login Screen in Forms

Knowledge Articles
, ,
1

Overview

This article explains how to return to the Universal Login pages from within a Form execution.

Applies To

  • Forms

Solution

Because Forms occur after the user has authenticated or completed the signup - it is not possible to return to the same signup/login screen. Some workarounds are:

Method 1:

Add a custom “Go back” HTML element that provides a hyperlink to a public endpoint on the application that initiated the login/signup.

NOTE: It is important this endpoint does not require authentication. Otherwise, a login loop could occur.

Here is an example:

1.jpeg
1.jpeg1681×1136 78.3 KB

2.jpeg
2.jpeg1140×1320 43.9 KB

This URL should allow the user to return to the Universal Login page.

  • For example, it provides a route capable of triggering a fresh /authorize request with “prompt=login”, to ignore the Auth0 session the user would have made by logging in/signing up and triggering the Form.
  • Optionally, “screen_hint=signup” could also be passed if the user wants to be returned to the signup screen.
  • Alternatively, trigger a logout on Auth0 before allowing the user to make a new /authorize request.
    • This way, the “prompt=login” parameter is not required and would help reduce the chance of a login redirection loop occurring if the application is automatically calling /authorize.

Method 2:

Use a “>> Jump button” to skip to the “ending screen” of the Form’s flow. In the action’s continue function, check if some feature of the forms’ normal processing has not been completed, such as metadata or the user’s email being verified, and if so, call api.access.deny(“”).

For example, editing the template for the “Email OTP verification with SendGrid” to provide a “jump” cancel button. Deny the user access if they have not got email_verified set to true.

3.jpeg
3.jpeg2067×814 77.9 KB

4.jpeg
4.jpeg1561×950 68.8 KB

Action Code triggering the form:

exports.onExecutePostLogin = async (event, api) => {
  const FORM_ID = '<form_ID_here>';

  api.prompt.render(FORM_ID);
}

/**
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onContinuePostLogin = async (event, api) => {
  if (!event.user.email_verified) {
    console.log("Denying user for failing email verification");
    api.access.deny("Email not verified");
  }
}

The application should then be coded to handle the “access_denied” error on its callback endpoint that Auth0 will return when api.access.deny() is called. This could be logging the user out of Auth0 and providing a page where they can start a new /authorize request or triggering a new authorize request with the prompt=login like mentioned above to allow the user to try another signup, depending on your desired UX.

NOTE:

  • Whenever triggering authorize requests automatically, care should be taken to avoid allowing login loops to occur. It is recommended to take the user to a page where they can press a button to start a new login or signup attempt, so it requires some user input and they have a way out of the flow on a public page of the application if they do find themselves stuck in a repeating loop.
  • Forms are triggered in post-login triggers. If this is during a signup attempt, the user will have already made an account in the previous attempt with, for example, an erroneous email address, so this account will persist on the tenant even though the user canceled out of the Forms flow.