Auth0 Home Blog Docs

Redirect users after login to non-callback url lock v11

lock-11
#1

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?

#2

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.

#3

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!?

#4

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.