Missing client parameter

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.

Hi Jeremy, attached an image which contains some more technical information.

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.

I am using it exactly the same way as described:

(function () {
  var webAuth = new auth0.WebAuth({
    domain: 'xxx',
    clientID: xxx'',
    redirectUri: xx'',
    responseType: 'id_token',
    scope: xx''
  });

  var loginBtn = document.getElementById('btn-login');
  loginBtn.addEventListener('click', function (e) {
    e.preventDefault();
    webAuth.authorize();
  });

  function handleAuthentication() {
    webAuth.parseHash(function (err, authResult) {
      if (authResult && authResult.idTokenPayload) {
        window.location.hash = '';
        alert('your user_id is: ' + authResult.idTokenPayload.sub);
      } 
    });
  }

  handleAuthentication();
})();

NOTE:

I am using with https://cdn.auth0.com/js/auth0/9.2.2/auth0.min.js

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.

https://pwnhealth.auth0.com/authorize?audience=https%3A%2F%2Fpwnhealth.auth0.com%2Fuserinfo&auth0Client=eyJuYW1lIjoib21uaWF1dGgtYXV0aDAiLCJ2ZXJzaW9uIjoiMi4wLjAifQ%3D%3D&client_id=h5d9aF3VkOyHyzS7MLpP0ERzCawRmrLP&redirect_uri=https%3A%2F%2Flabs.pwnhealth.com%2Fauth%2Fauth0%2Fcallback&response_type=code&scope=openid+profile&state=dfa3be12d91b2a8a79cdf3ae317555fe6315f3b3bd2973fc

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.

I am using the authorize endpoint using a Hosted Login page and still got this error for one customers this morning.

1 Like

Still having an issue, but it looks like the error message has changed to:

“You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn’t find your session. Try logging in again from the application and if the problem persists please contact the administrator.”

Same problem here, i’m using lock hosted page (11.3.1)

Any update on this error?

Hi Jeremy,

Any updates on this issue?

Some of our customers (Chrome web-browser on Android device) can not login at the moment, which is really problematic. As we’ve mentioned earlier: we are using the auth0 hosted pages, and have set back all the layout modifications. We have also verified that the /authorize endpoint is being used by the hosted login page.

The username-password login is working, but when a user should receive a SMS or push notification (MFA) the page is stuck on the loading screen (see below):

stuck

Our log doesn’t show any errors either. On a success login the following log-records are generated:

  1. Second factor started - Guardian - Start second factor authentication
  2. Push notification sent - Guardian - Second factor send push notification
  3. OTP Auth suceed - Guardian - Second factor authentication succeed
  4. Success Login

But when the page is stuck on the loading screen only the following log-record is generated:
1) Second factor started - Guardian - Start second factor authentication
… nothing else…

Any update or help is appreciated. Thanks.

We’ve just noticed that it’s working correctly on Android 63.xxx, but fails after upgrading to Android 64.xxx or Android 65.xxx. It seems to be fixed in Android version 66.xxx.

A fix was deployed to our preview and staging environments over the weekend and will be reaching production soon

Just checking to see if this is still persisting?

The fix rolls back to the previous login type of link where the query string parameters are there in the URL. However, end users that already bookmarked the old link will have it fail. Eventually errors will decrease

Seems to be fixed, thanks!

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.