Redirect users after login to non-callback url lock v11

I have been trying to follow this:

The options for lock v11 are

var authOptions = {
                    allowSignUp: false,
                    rememberLastLogin: false,
                    avatar: null,
                    closable: false,
                    autoclose: true,
                    //container: 'hiw-login-container',
                    languageDictionary: {
                        title: 'Welcome',
                        usernameOrEmailInputPlaceholder: 'your email'
                    },
                    sso: true,
                    auth: {
                        params: {
                            scope: 'openid offline_access nameidentifier',
                        },
                    }
                };

To handle non-callback urls, I store them beforehand on the localstorage & after authentication is successfull, redirect the user.
Something like:

lock.on('authenticated',
                function (authResult) {
                    sessionService.setInitialLogin();
                    tokenService.setToken(authResult.idToken);
                    tokenService.setRefreshToken(authResult.refreshToken);
                    authManager.authenticate();

                        lock.getProfile(authResult.accessToken,
                            function (error, profile) {
                                if (error) {
                                    loginFailed();
                                    console.log(error);
                                }
                               // more stuff...
                              var redirectUrl = localStorage.getItem(APP_CONFIG.redirectUrl);
                              if (redirectUrl !== '' && redirectUrl !== "undefined") {
                                   $window.location.href = redirectUrl;
                              }

                            });
                });

But whenever the user puts in a non-callback url , the lock gets displayed, user logs in & the
https://<client>.auth0.com/authorize? call has the redirect_uri set to the non-callback url.

This results in standard Callback URL mismatch error.

How do I resolve this?

Your Lock options don’t explicitly set a callback URL so if I recall correctly Lock will automatically use the current URL which may not be white-listed. You should set the URL in Lock options (https://auth0.com/docs/libraries/lock/v11/configuration#redirecturl-string-) so that no matter the page that the end-user currently has selected the callback URL is the one you chose (after authentication you can redirect again to the original page the end-user was viewing). Have in mind that if you the callback URL explicitly you might also need to set response type as noted in the linked docs.

Ok.

I tried setting the callback URL & response type as:

 responseType: 'token'

But when the user puts in a non-callback url in the address bar, for example , http://localhost:3254/noncallback

The lock screen is displayed for them to login & after user is logged in the following URL is set in the browser to be redirected:

https://<client>.au.auth0.com/authorize?client_id=KeX&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%3A3254%2Fnoncallback&connection=Username-Password-Authentication&state=SS.&scope=openid%20offline_access%20nameidentifier%20businessidentifier&callback_url=http%3A%2F%2Flocalhost%3A3254&realm=Username-Password-Authentication&login_ticket=GN&auth0Client=ey

Clearly the callback_url is set correctly but the redirect_url is still set to original non-callback URL.

Which of course ends up with the same error:

Callback URL mismatch.
The URL "http://localhost:3254/noncallback" is not in the list of allowed callback URLs.
Please go to the Application Settings page and make sure you are sending a valid callback url from your application.

Not sure what’s going on here!?

If Lock is still using the current URL on the browser address bar then you may have set the wrong option in Lock or you set the option in a Lock instance different then the one being used. Your issue is highly specific to the client application code you use so without a mini-sample application that exhibits the issue it will be hard to pinpoint the problem.

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