What approach would you recommend for doing the same on 'Cancel'?

[azure-ad-b2c]

What approach would you recommend for doing the same on 'Cancel'?

[JasSuri]

Hopefully i understood, but you could encode something in the state parameter so redirects via your app insert the correct ui_locales parameter. Better posting questions like this on Stackoverflow, unless this was an issue with a specific sample.

[iamalexmang]

I must respectfully disagree with SO, since embedding the password reset in the policy has the mundane solution of handling the AADB2C90118 error code in the app - all first three queries for "stackoverflow AADB2C90118" suggest the same on StackOverflow; and that's quite the opposite from what this fantastic sample does, where the error code no longer gets to be handled in the app code.

Nonetheless, in order for the code sample to be complete, it would in my humble opinion also explain how the 'Cancel' button would be handled via the policies too.

So far, the only workaround I could think of and get to work too (kind of a nasty solution, in my books) was to maintain the ui_locale value in the browser's local storage and use an embedded JavaScript in the custom layout to change the displayed language on either of the policies being triggered based on that value. Undeniably, this will fail if local storage access is disabled by the browser.

The problem I'm trying to elaborate in this issue is that cancelling during the password reset flow redirects the user to the app with AADB2C90091, without thus having any information in the app regarding the chosen language for the B2C user interface.

[JasSuri]

Did you try to encode the ui_locales into a state parameter? We should be returning the state parameter even in the event of an error being returned.

[iamalexmang]

Do you mind elaborating that, please? I’m specifically interested how that would prevent the aforementioned code from being handled in the app (thus completing the sample to fully embed password reset, as the folder name implies). I’d also appreciate elaborating how I could persist in the state parameter the ui_locale change during the password reset without additional JavaScript). Alex Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Jas Suri <[email protected]> Sent: Monday, March 30, 2020 6:38:42 PM To: azure-ad-b2c/samples <[email protected]> Cc: Alex Mang <[email protected]>; Author <[email protected]> Subject: Re: [azure-ad-b2c/samples] What approach would you recommend for doing the same on 'Cancel'? (#51) Did you try to encode the ui_locales into a state parameter? We should be returning the state parameter even in the event of an error being returned. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#51 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABMBPYPBKGWKNSTDYDV2AULRKC4IFANCNFSM4LUE4XWQ>.

[iamalexmang]

To add to why SO is not the solution: a couple of days ago I replied to the most popular existing threads related to "stackoverflow AADB2C90118" which suggest the use of application-handled exception codes and have no mention of the policy-based solution (as per the embedded-password-reset sample). My reply was a reference to this GH repository of samples which nicely explain how to get the password reset link embedded in the sign-up/sign-in policies.
For no apparent reason though, both replies were deleted by a moderator: https://stackoverflow.com/users/100297/martijn-pieters.

[JasSuri]

The MSAL library and OIDC OWIN pipeline allow passing a state parameter. This parameter is sent to B2C in the auth request and returned by B2C back to the app so that you can maintain some state info. Usually you base64 encode your payload and insert as the state parameter. The cancel operation will always return to the app. There is no solution which involves policy configuration to get around it.

If you pass a state parameter, it’ll be returned with the error to the app. Your app can then understand what the ui_locales was set to at the start.

You can try other things like removing the cancel altogether and doing your own custom logic.

To get more help specifically on this, I recommend SO, as this is not an issue with this policy, it is a more generic question.

[iamalexmang]

Do you mind elaborating how the ui interaction result (changing the displayed user interface), which is done outside of our app would be persisted in the state parameter?

[JasSuri]

It wouldn't be, usually the application sends the ui_locales as part of the authentication request, based on what language the user has set in the app, or the app has detected. It sounds like you are doing something different, can you explain in more detail?

[iamalexmang]

Once the user is on the login screen, he/she may change the language. This isn't anything unheard of - frankly, every single application I've come across allows for display language to be switched, even (and especially, in fact) during sign-up, when the user is required to fill in PII data or other sensitive information. Not understanding the meaning of labels or placeholders or, even worse, warnings or error, is critical.
As previously mentioned, a change in the language selection during sign-up, is lost when redirecting the user to the password reset form using the embedded procedure available in the sample previously mentioned.
As also previously mentioned, one workaround for that was to persist in the browser's local storage the change the user did in terms of the UI (whilst in B2C, not the app), so that the language can be pulled when any subsequent policy is invoked --> as per the sample, the password reset policy.
Further, when the user hits the 'Cancel' button, they're taken back to the app. This means that (1) we can't rely on using session storage and go against terms of use and enforce the persistance on the user's HDD of some information without receiving permission to do so. Also, the solution is anything but ideal and having this work out of the box is expected, in my humble opinion. The fact that I can't maintain anything (e.g. state) between the two policies, nor that the underlying password reset policy (which is invoked and embedded in the sign-up policy) reverts to invoking policy (rather than the app) is not ideal either.

[JasSuri]

Currently users can only load the page in the language chosen at the application, by passing the ui_locales parameter. To change the language, you'd have to go back to the application or click cancel and start over.

For you to have the user change the language at the B2C page itself (I presume you are using some of your own custom JS to do so), means B2C must maintain some session state to preserve this across policies.

The only solution here is to set your own cookie, and have your custom javascript use that cookie to persist the setting and modify the language on-the-fly with your javascript in the B2C page for every page load.

We will look at this to determine how this can be better handled for users to change the language on the B2C page itself.

[iamalexmang]

@JasSuri, there are really two distinct problems that we're now elaborating.

1. The password reset policy is embedded. So I don't have to write boiler-plate code. Except that I do, because the embedded policy is not going back to the triggering policy, but to the app. So then how is an embedded policy embedded anymore?

2. The example I gave to support this is with a change done in the sign-in page, which would be handled outside of the app, but in B2C once the UI with the custom layout is rendered. I appreciate this to be a decent ask given its typicality: when a user has to submit a form, may it be sign-up, password reset or tax-return, proper user experience dictates the form is comprehensible.

Currently users can only load the page in the language chosen at the application, by passing the ui_locales parameter. To change the language, you'd have to go back to the application or click cancel and start over.

Respectfully, I must disagree. The change of the language is a matter of passing in a ui_locale parameter, which can be injected via JavaScript and reloaded on the page. This also means that the embedded policy will maintain the parameter value when triggered. However, the value is lost when the cancel button is hit; because 'cancelling' the subsequent (embedded) policy is cancelling the entire flow, though the user expect to go back to sign-in and any app developer would likely return the user to the policy the embedded policy was called from.

[JasSuri]

Closing as the sample does work as intended.

[iamalexmang]

Respectfully, since there was no reply, I am of the opinion the issue shouldn't be closed.