Diool is an app with its own users, and we rely on Auth0 to authenticate these app users through our tenant “myxxxxxxxxx@eu”.
Among these users, we have some of them that are facing a recurrent difficulty to connect to our Diool application with a permanent error message which is as follows on their web browser :
404 NOT FOUND
After inspecting the browser navigation page, here are the exact content of the API call and corresponding response that qlways occur to these users :
How can you help us identify what the problem would be for these users, here are some logins and recent connection dates: Monday February 26 between 5 p.m. and 6:30 p.m. WAT for tanxxxxxxxri@gmail.com and dxxxxxxy@cityxxxxmr.com
It looks like the URL of the /login request is incorrectly encoded - some of the URL parts are URL-encoded, and some not. There are white spaces which shouldn’t be there.
In the above part, I believe the redirect_uri is not a valid URL.
If we decode the redirect_uri part we get only HTTPS:
Could you please take a closer look at the part of your code responsible for forming the above URL?
Looking at the login URL I can see that also one path params is missing: a proper URL would contain "u/" before "login", like this: https://auth0's_domain.auth0.com/u/login
This would explain why some of users got Not Found 404 - the request URI is malformed thus doesn’t return anything.
Could you please ask one of the affected users to try to log in to your app from a different machine? Does the login URL looks the same then (is similarly malformed)?
Does the login attempts your referred to has been recorded by your Auth0’s tenant? (Do you see them on the Monitoring section of your Auth0’s tenant?)
Answering to these questions will help us to understand better the nature of a problem.
Thanks for your support. We had already tried to ask different other users to login on the same device, same network, same connection, same browser, same config… WE even went ourselves to the customer premises, in order to try our own login in the very same condition that they were doing their own login attempts… And for every attempted login, we have never been able to get any different response than the one of this post, even changing from one device to another into their premises.
But finally earlier today, with the help of one of our fullstack sw engineer, the issue seemed to come from the url of a cdn that was not reachable for the machine of that specific network. So we had to declare on auth0 server config another cdn that was reachable.
Can’t tell you anything more clear or precise as I was not the one doing the config on Auth0, but I have explained the gemeric principle hoping that you have understood.
Appreciate your update on that @philippeb and it’s great that you have been able to manage it! I shared your isight internally.
Sometimes a generic issue description is absolutely enough to deliver a complete support, but in this case, my initial assumption of the potential root cause was different than in your solution, thus sometimes it takes, for example, investigating the HAR files by our support team.
Thank you! Please let us know if we can assist you more on this issue.
