Lately we have introduced a modification in the redirection between /authorize call and /login call that needs to keep the user session in order to work. For a normal end user that will work without any issue, however, we have seen tons of errors coming from User-Agents like Java and other tools that are not browsers. If you have an automated tool you will need to be sure that the tool keeps the session.
This was 100% happing from auth0.js running in Chrome browser. In any event this makes me nervous using this solution going forward, how can it work one day and the next throwing errors? This will loose sensitive customers for sure! There should be protocolâs ensuring this never never never happens with an authentication systemâŠ
Thank you for the verification - let me go back and see if I can track down what happened. Can you send me your tenant name so we can investigate? A DM is fine if you would prefer
Itâs keeping several of our users from login in. Weâre not using any automated tools, these are internal users/admins. Auth0 marked the incident as resolved yesterday but weâre still experiencing the issue. Tenant âpwnhealthâ. Please advise.
we are experiencing a simular problem when our MFA wants to send a push notification.
Itâs stuck on the loading page and sometimes a browser refresh is producing your âmissing client parameterâ error in the Auth0 log.
Weâve narrowed it down to a combination of an Android OS and the google Chrome browser.
Any onter combination works fine. No errors and no problems login in.
We will be creating a new ticket but wanted to let you know.
So with this issue, quite often we see this happen when someone has bookmarked the login page and then try to hit that page - which will eventually not work after the session has expired - the login page is not meant to be bookmarked as it is shown as part of a non-repeatable OAuth 2.0 transaction.
Accessing /login will not work after April 1 as we deprecate old endpoints and instead push towards /authorize instead.
Is it possible to just route the user to the intended URL when this happens? We have some users that are not that technically savvy and are having issues like this. It would be easier if the login site just routed back to the original site instead.
Just to let you know. There are no bookmarks involved when looking at our problem.
The interface just keeps loading which in some cases result in a âmissing client parameterâ error after a refresh.
And the problem only occurs on Android in combination with the Chrome browser.
To better provide an answer as to what is going on, and what changes should be made (@warren1 / @jnovak / @athome / @dennis1 / @jaliperti1 / @gmilow ), we need to know what/how youâre using Auth0, essentially the usecase. Feel free to DM me if you would prefer.
For instance, @athome where is that URL coming from? You can enter into /login with same values as before or be redirected by /authorize. Both, currently work. But if youâre making requests directly to /login that will need to change, otherwise some people may periodically see issues related to a lost session when the redirect comes to /authorize
Hi Jeremy, attached a screenshot of where we get stuck in the proces. Itâs the out of the box 2FA authentication provided with Lock and Gardian. The screenshot is with Android and Chrome and with those we have the issues. Not always but nine out of ten. We happily provide you with more details if so required.
I used a tutorial I found on your site using auth0.js as is. Using it through a web. 100% No bookmarks. Also it was working perfectly for the last 2 monthâs and started happening without making any changes.
Ok so hereâs the information I have received around this. This isnât an outage, but is instead around making sure everyone is using secure clients and best practice. Clients need to be utilizing the /authorize endpoint properly, and in turn will be logged in properly. The /login endpoint is not a documented part of our API and should not be used. The proper process is identified here.
Thatâs not the issue for us either, weâre redirecting to /authorize. For instance, when the user visits an authenticated URL (labs.pwnhealth.com), theyâre redirected to the URL below, per tutorial/documentation on the Rails SDK. Again, this issue never happened in several months since we implemented Auth0 for authentication, and started happening at the time of the incident mentioned previously. Even though the incident was closed, we continue to experience the issue.
One of my users started experiencing this yesterday as well, and continues to today. Just this one specific user (there are only about ten users total), no other users see the error. For this user it doesnât happen 100% of the time, sometimes they can login just fine.
My use case is very simple, Iâm only using Username-Password-Authentication connection, no other social logins. Iâm using the PHP-SDK, version 5.1.0. My code looks almost exactly like that in the setup docs: Auth0 PHP SDK Quickstarts: Login
Iâm also using the hosted pages for login, so I havenât built my own. Thus I donât have any code which calls endpoints myself, nor am I using Lock, etc.