I’m trying to implement a POC for a new feature using ACUL. I added a new checkbox to the mfa-sms-challenge screen and I need to make this user selection available in an Action Script that runs as part of the post-login flow.
Things I’ve tried:
- Writing cookies from ACUL. The Action script doesn’t seem to have any way of reading them.
- Pass this information as a custom option as part of the SDK’s
mfaSmsChallenge.continueMfaSmsChallenge(options). I see the option gets sent to Auth0 in the dev tools, but I’ve found no way to access it in my actions.
I’m currently trying to write this to the user’s metadata, but I don’t see any option in the ACUL SDK to do so.
Is this possible to do? If not, do I have any other options?
Hi @david.rochin.ukg
Welcome to the Auth0 Community!
Please allow me some time to research on this use case and I will return with additional information that should help with your implementation.
Thank you for your patience!
Gerald
Hi @david.rochin.ukg
We appreciate your patience on this matter!
I understand that your use-case is to implement a POC via ACUL to gather additional user information via a checkbox in the mfa-sms-challenge screen. We can recommend two approaches in order to pass the custom data:
Approach 1: Pass data as a query parameter (Recommended for POC)
- Modify your ACUL customization to capture the checkbox state and pass it as a query parameter when initiating the authorization flow. For example, if the user checks the box, append
?custom_preference=true to the authorization URL;
- Access the parameter in your post-login Action using
event.request.query.custom_preference. This value will be available throughout the authentication flow;
Example Action code:
exports.onExecutePostLogin = async (event, api) => {
const customPreference = event.request.query.custom_preference;
if (customPreference) {
api.user.setUserMetadata("mfa_preference", customPreference);
}
};
This approach works because query parameters are preserved across the authentication pipeline and are accessible in the Post-Login Action’s event object.
Approach 2: Write to user metadata after MFA challenge (More persistent)
- After the user completes the MFA challenge in ACUL, call the Auth0 Management API from your backend to update the user’s metadata with the checkbox selection. This requires a Machine-to-Machine (M2M) application with the
update:users scope.
- In your post-login Action, read the stored metadata:
exports.onExecutePostLogin = async (event, api) => {
const mfaPreference = event.user.user_metadata?.mfa_preference;
// Use the stored preference
};
Note: You need to ensure synchronization between your backend and Auth0 in order for the user information to correctly be added to the user_metadata. The M2M request needs to capture the information and pass it to /continue before triggering the Post-Login Action.
Our recommendation is to implement the first approach if applicable due to less overall complexity and more long-term stability for your flow.
Hope this helped, have a great one!
Gerald
Thanks for taking the time to investigate this for me. I had no idea that query parameters are persistent. I’ll give it a try!
I tried implementing the query parameter approach, but it didn’t work unfortunately. Mind if I give you more details so hopefully you can see if I’m missing something?
In the mfa-sms-challenge screen, I’m appending my query parameter like this:
const url = new URL(window.location.href);
url.searchParams.set("enrollForAuthenticator", String(value));
window.history.replaceState({}, "", url);
With that code, my URL bar will have something like this after I click my custom checkbox (which looks good to me so far):
https://my-gateway.dev/u/mfa-sms-challenge?state=hqFo2SB...&enrollForAuthenticator=true
And in my post-login action, I’m trying to access it like this:
exports.onExecutePostLogin = async (event, api) => {
console.log(`POC: `, event.request?.query?.enrollForAuthenticator);
};
However, all it prints is undefined. If I inspect the contents of event.request.query I only see the initial query parameters that the authentication URL had, and not what I added mid-flow.
Did I miss something?