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.
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 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.
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().
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.
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?
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.
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.