- Lock v11
- auth0-js v 9.1
I have a React app that is at
app.domain.io. My (static, Jeykll) website is at
www.domain.io, and is where people log into the app. The general flow is that a login occurs on
www, posts to Auth0, which then hits my login callback at
app.domain.io/login/callback. That endpoint then runs
auth0.parseHash() to grab the access_token from the hash and store it in localStorage, etc.
I just starting trying to use Lock to do this authentication flow from
www. The ideal scenario there is that a user click “Log in” on that subdomain, lock pops up, they enter credentials, and it redirects them to
app, as a logged in user.
Currently, this works fine in Chrome (OSX), however does not work in Safari and other browers.
As I understand it, this is due to third-party cookies, and some browers not handling them.
Accordingly, I set up the Cross-Origin Verification page at
app.domain.io/cross-origin-fallback, which runs the code detailed here: https://auth0.com/docs/cross-origin-authentication
I’m unsure why this isn’t working, however, I do have a question to start with.
As outlined above, the standard authentication flow that I have ends up landing on
app.domain.io/login/callback, which does the job of parsing the hash and storing the access_token.
Now, with this fallback URL, that page is never called, which means the access_token is never parsed, the user never authed, etc.
The question is - in this scenario, on which subdomain does the cross-origin verification page live,
app? Secondly, how do I handle getting the authentication flow to get to that login callback, so I can appropriately parse the token and store it?