We’re using Lock.js to overlay our website with a login box, meaning that that users can see our page underneath while signing in, instead of directing away to auth0’s domain. This works well, but there are a couple things not quite as we want and I could do with some guidance on how best to tackle them.
Currently, application ‘Callback URLs’ doesn’t support wildcards after the domain as far as I can tell. Our website gives users the ability to create their own pages with their own path. Something like this: ‘https://www.product.com/s/myuniquename’
We also want users to be able to view these pages while unauthorised if the creator selects so, and when they try to interact with the page, we then display the lock.js popup to sign them in. What this means is that we have any number of page URLs that need to be acceptable as a Callback URL that will all come from ‘https://www.product.com/*’, and we obviously cant keep adding them into the whitelist, it would quickly become unmanageable. What can be done to help in this situation?
To reiterate, ideally we do not want to redirect users away from the page they are on to log in, we want the page they were originally accessing to be visible under the lock widget.
When switching between tabs in the lock widget, the page is stripped from the URL and replaced with a Hash (#) symbol. Is this expected functionality, and how can it be prevented as this is losing our user’s page URL?
For example, the user routes to ‘https://www.product.com/s/myuniquename’, clicks the login button to display the lock.js popup, then clicks the Signup tab. The URL then becomes ‘.product.com/#’ which means when the user signs up they are dropped back to the root page, so the page they originally wanted to access is lost and they have to route there again. We can have separate buttons for log in and sign up, but if they switch tabs for any reason, the page is lost.
Can the return URL be stored in a state, or can we pass a return-to URL via the lock? Or can we disable the # entirely?
Any help you can provide is greatly appreciated as this is proving to be a bit of a blocker in what is otherwise a very sleek product and service!
I think the most effective way to handle that would be to talk directly with the tool maintainers which in this situation means creating a GitHub issue in the repo. Once you have the link to it please share it with me here so I can ping repo maintainers regarding that. Thank you!
Thanks for your quick reply. Ive opened a github issue with regards to number 2 above here:
But as number1 isn’t really related to lock specifically, ive not outlined it there. Any input you can provide with regards to that would also be very useful. Thanks!
HI!
Just dropping a line to see if there is any input on how I can allow for wildcard Callback URLs in Auth0. As outlined in #1 above, this has become fairly critical and I’d really like to find a solution if at all possible