Simplify Embeded Password Reset Azure B2C Custom Policies

Question

I need to use custom policies to create authentication and password reset flow for my project. I started using the Azure B2C embedded password reset. For the password reset flow, here is the result

Is it possible to either :

• remove the third step as show in the below picture. The email is still verified but the user does not need to know about it.
• or to automate the transition between step 2 and 4 using javascript. In this scenario, how do I know on which screen I am to trigger the javascript allowing this automation. Can I get the "claim" from javascript code ?

Thank you for your help

Answer 1

Looking over your question and the options you've selected for reducing the steps in the Password Reset flow looks a lot like what I solved over here. The TechnicalProfiles and the like involved were used as is from samples so I've included the JS I used and an explanation of what it eliminated.

Fixing this was more challenging than I expected or encountered with other JS customizations. As the selected answer suggests, each step in the process does not guarantee a page load occurs and the buttons are re-used throughout steps so you can't just hide the ones that "are pointless" because they aren't pointless in future steps. The most reliable way I could find was to monitor the aria-hidden attribute and alter the page at that point.

I'm using a custom ContentDefinition with the DataUri set to urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.8 but it would likely work with previous page versions as long as the IDs remained the same as 2.1.8 -- I'm not using jQuery, but I'm using browser APIs that are not available in older browsers.

I have a helper function that creates the aria-hidden observer:

    const createObserver = (name, onVisible, onHidden) => {
      let MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver

      let elem = document.getElementById(name)

      if (!!(elem)) {
        let observer = new MutationObserver(function (mutations) {
          mutations.forEach(function (mutation) {
            if (mutation.type == "attributes") {
              if (mutation.target.getAttribute('aria-hidden') == "true") {
                if (!!onHidden) {
                  onHidden()
                }
              } else {
                onVisible()
              }
            }
          });
        });
        observer.observe(elem, { attributes: true, attributeFilter: ['aria-hidden'] });
        return observer;
      }
      return undefined;
    }

Then I subscribe to it for a few fields in order to tweak the page:

    const inputEmailObserver = createObserver('email_intro', () => {
      document.getElementById('continue').style.display = "none";
    });
    const verifyCodeObserver = createObserver('email_info', () => {
      document.getElementById('continue').style.display = "none";
      document.getElementById('email').disabled = true;
    });

    const verificationSuccessObserver = createObserver('emailVerificationControl_but_change_claims', () => {
      document.getElementById('continue').style.display = "inline";

      // There's a pointless page that shows up after you've verified your e-mail
      //   so to avoid the confusion, continue is clicked for the user, taking them
      //   to the password reset page
      document.getElementById('continue').click();
    });

The changes center around the behavior of the Continue button. It doesn't really have a reason to exist the way we wanted the flow to work (I can't see a use for it most of the time, but I could be missing something). The only time it doesn't return an error message, its purpose is to take the user to the "Set a New Password" after they have completed verifying their e-mail, so it's not even doing that step when you click Continue.

The first observer removes the Continue button from the first step. This leaves the "Send Verification Code" button and the e-mail input in the UI.

The second observer hides the Continue button for the second step and disables the ability to alter the e-mail address after "Send Verification Code" is clicked.

The last observer causes the Continue button to be clicked for the user after the user's verification code has been confirmed valid, eliminating the need to click the Continue button.

Answer 2

You can use JavaScript mutator function. Use it to detect that the Continue button has changed property (become enabled), and then trigger a function to hide the Change button and perform a click event on the Continue button.