Hi @James.Morrison, do you have any updates for us?
Thanks
After looking again at this with a senior engineer this may be related to your redirect_URI. Can you please verify that your redirect_URI is indeed correct as well as the Allowed Callback URLs? Thanks!
hi @James.Morrison thanks for response, I’m sending you image on how our auth0 initialization looks like
for redirectUri we use window.location.href which should, and pls correct me if I’m wrong, translate into one of those sws-test://{tenant}.auth0.com/login/callback URIs
Hi there @dsel,
In your code sample you are using the current URI as the redirect URI (Callback URI) which won’t work. The callback URI should be a specific, unchanging link.
The Cordova SDK should be configured in the config.xml like the example below:
That example would resolve to something like:
com.auth0.cordova.example://sample.auth0.com/cordova/com.auth0.cordova.example/callback
In short … the callback URI used ( redirectUri in the code) should not change, needs to be saved in the Application in Auth0, and has to be handled correctly by the app.
Please let us know if you have any additional questions.
Great! we don’t experience open with dialog just by changing the callback URI to what you advised above - but we’re having another issue now - every soc network keeps “Loading…” once I put my credentials and try to login to FB / Twitter / LinkedIn…
I’m glad to hear it all came together!
What is the default login connection that you use? Username/Password? If so, does that work correctly?
Are you seeing anything in the logs within the Dashboard when these requests are sent off?
Hi @James.Morrison , I’m actually seeing Success Login in log with username and profile ID it’s just like it can’t get back to the app itself - it’s stuck on a Redirecting you back to the application page…
This is a tough one @dsel, since it’s showing success in the log but doesn’t transfer as expected. Is there an emulator you can see processes run through like with Xcode for your environment? Additional details could be really beneficially at this point in narrowing down what may be going on.
Hi @James.Morrison, we cleared all callback URIs from app settings Allowed Callback URLs
field (https://manage.auth0.com/dashboard/us/sws-test/applications/RX9P6VqztARXDcUNbDkrDtNdAy6414Ic/settings) and we have used just the one you suggested (com.socialwebsuite.app://sws-test.auth0.com/cordova/com.socialwebsuite.app/callback) with our settings, now we are getting the message “Callback URL mismatch”, can you pls let us now what may be the issue.
Thanks.
Are these callback changes matched in the app?
Hi @James.Morrison, yes, all changes are reflected in app, we just erased all the other testing URLs from callback field in settings and basically left just the one that made the breakthrough (from this post)
Looking into this, I will let you know what I find. Thanks!
Following up on this front @dsel since I have been out of office the past two days.
After confirming with our SDK team, generally if the server responds “callback url mismatch” the error it’s often a point to the dashboard not having the correct callback URL whitelisted.
However since the callback URLs use the package name at the beginning of it, you shouldn’t be running into such issues unless there’s more than 1 app installed that had registered that URL. Can you confirm that this is indeed not the case for me?
Hi @James.Morrison, thanks for the response. We actually deleted other two apps that we had in order to get as clean as possible, and now we’re again stuck with Redirecting you back to the application page (on twitter, on fb it’s just spinning the loader icon).
This same issue we experienced in previous post.
Can I get a time stamp of when this occurs so I can take a deeper look on our side of things? Please also check the dashboard logs to see if anything populates at the time of you reproducing the issue. Thanks.
hi @James.Morrison thanks for the response, here is the most recent event, in logs I’m getting success and upon expanding the entry I see all the relevant data provided by twitter in this case, but the only thing is I’m not being redirected back to the app, it sort of hangs out on twitter redirect page
timestamp of this event in log is 2019-09-23 14:25:46.345 UTC
thanks.
After confirming on the backend on our side of things, matching the timestamp everything looks copacetic. However depending on your app development environment, are you able to capture a HAR file of the hang up after the twitter redirect page that it’s hanging on and share it via a DM? Thanks in advance!
Following up on this front @dsel, I was able to double verify with a senior engineer after inspecting the HAR file that we are handing off the session correctly to the application.