Difficulty authenticating using Lock in single-page app

Hello all. New to Auth0/Lock and I’m trying to get it to work on a single-page app. When I create the lock, I’m setting redirect to true as recommended, responseType to token as preferred for SPAs, and redirectURL to an empty string in accordance with using token. (I realize these are defaults, but I’m naming them explicitly here for clarity.) My scope in params is the standard openid profile email, though right now I’m just trying to get email/password to work.

I start at the beginning of my flow and go through a few screens of the app before I hit the part where the lock appears. When I attempt to sign up with a new username and password, it attempts to redirect to the URL where I originally started, which is denied because it’s not in the list of approved URLs. Even if I add it, however, it just puts me back where I started and lock.on( "authenticated" ... ) is not triggered. Clicking the emailed confirmation link just loads up a confirmation screen and also fails to trigger the listener.

Am I doing anything obviously wrong? Do I need to revisit those settings or am I missing something else? Cheers.

Hi @tlhinman,

Welcome to the Auth0 Community Forum! Hopefully we can help you get up and running on your SPA project.

Are you using one of the quickstarts? If so, which one? If not, which framework are you using?

Are you getting any specific errors in the console?

Thanks,
Dan

Thanks Dan! I’m working on an existing app in Vue, so a lot of Auth0 functionality is currently in place. We were using a passwordless flow in which users would receive a magic link that would allow them to proceed, but we’d like to change this to a universal login with Lock.

I’m testing this on my local server. In the console, the most clueful error appears to be a 403 from this URL (brackets replacing some sensitive strings):

https://[me].auth0.com/authorize?client_id=[client id]&response_type=token%20id_token&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2F&scope=openid%20profile%20email&state=[long string]&nonce=[long string]&response_mode=web_message&prompt=none&auth0Client=[very long string]

I’m also getting several 404s from a Gravatar URL and for favicon.ico, but I would guess those are less concerning. Thanks!

Hi @tlhinman,

Can you confirm that the error has no message and is just a generic 403? Can you also DM me the name of your tenant so I can take a look.

Thanks,
Dan

Hi all. I thought I’d rephrase a prior question I had, as I think I’ve got things narrowed down to a specific issue/misunderstanding.

In an effort to familiarize myself with Lock, I downloaded the sample app from the Vue Quickstart and I’m trying to put Lock into it. Within authService.js, I’m definining a lock with a responseType of token id_token and a redirect URL. I have a function in AuthService that sets the on("authenticated" ... ) listener and calls show() on the lock. I call that function from NavBar.

All of this seems to let me create a user and log in just fine. The problem is that the on listener never triggers, neither in that moment nor when I confirm my email address. I can’t figure out what I’m doing wrong. Should I be setting on elsewhere, or creating the lock elsewhere for that matter? Thanks.

Could you also post the code that this question is related to? The on and show would be specifically helpful.

Thanks for merging the topics, Dan. I’ll post code from my attempt at the sample project since that distills my problem.

The lock, defined in authService.js:

const lock = new Auth0Lock(
  authConfig.clientId, authConfig.domain,
  {
    initialScreen: 'signUp',
    auth: {
      redirectUrl: `${window.location.origin}/callback`,
      responseType: 'token id_token'
    }
  }
);

In that same file, in the AuthService class, I have:

  lockLogin() {
    // I have /* eslint-disable no-console */ at the top of the file so I can use this to test
    lock.on("authenticated", function(authResult) { console.log("YES: " + authResult); } );
    lock.show();
  }

In NavBar.vue, I’ve replaced the @click.prevent call in qsLoginBtn with lockLogin, which is defined below in methods and simply calls this.$auth.lockLogin().

Thanks again for your help!

1 Like

Do you have this configured in your allowed callback urls? I am only seeing one callback that would fit this schema and it doesn’t look like the location origin. It is possible that it is, it just depends how you have it configured.

Yes, http://localhost:3000/callback is in the allowed callbacks for the client ID I provided over DM. Actually logging in seems to work well; it’s just the “authenticated” event I’m having trouble firing. It must be that the redirection/page reloading wipes away the on call, but I’m confused as to where else I might put it.

Yeah it looks like that would be the correct place to put it from what I’ve seen researching. Let me reach out to someone since I am a little stuck on this one.

1 Like

Can you provide us with a HAR file? Please DM it to me with any sensitive data scrubbed.

Worked with things a little more yesterday, and in my main app, I was able to trigger the event if I created the lock right when declaring it as a member variable of AuthService and set the listener in that class’s constructor. Strangely, I could not replicate this in the sample app, and in any case, I want to be able to create the lock later on so I can prefill the email field dynamically. Nonetheless, this seems to point to an issue of listeners being “registered” before I call on. Is there any way to “refresh” the listeners so this one will come into effect?

Can you keep the lock.on in a constructor and use the prefill option in lock.show?

Will this accomplish what you would like?

lock.show({
  prefill: {
    email : "example@email.com"}
});

Will that work? According to this page, prefill is not exposed. Has this changed?

Working with a colleague, we hit upon a solution of creating a bare-bones dummy Lock member variable when AuthService is initialized, calling this.lock.on in that class’s constructor, and assigning this.lock to a new Lock when we need it. I’m not entirely sure why it works, but it seems to be fitting the bill. Nonetheless, I remain interested in understanding/solving this problem for future reference.

Hi @tlhinman,

Sorry for the delay on this.

It looks like the prefill option should work according to https://github.com/auth0/lock/blob/6b04ccc85b0be438d767672648af2ba8cb62ec1a/README.md

Let me know,
Dan

Just tested it out and it looks like prefill is settable only in the Lock’s creation and not when I call show. But I can work with that.

Glad to hear we got some sort of workaround. If you have some feedback as to how we can make this feature better, please take a moment and file a feedback ticket The product team looks at each ticket and uses it to decide how to improve the product.

Thanks for your patience working through that use-case. Let us know if there is anything else we can do.

Cheers,
Dan

1 Like

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