ShinyProxy 400 Bad Request

Help
1

I have set up openid with auth0 on ShinyProxy.

The cookie received from https://DOMAIN.auth0.com/authorize gets bigger every time I log out.
Leading to:
400 Bad Request
Request Header Or Cookie Too Large
nginx

I also am receiving: Failed to load resource: the server responded with a status of 404 () /user/ssodata:1
at the login screen.

Does anyone have an idea of why this is happening?

3

Hey there @kevin.mcginley, can you snag us a HAR file of the workflow as the error happens so we can take a deeper look at what may be occurring and DM it over to me along with the tenant name? Thanks in advance!

5

I wanted to follow up @kevin.mcginley on this topic and what we were able to find after looking at the HAR files you sent over.

Initially you mentioned about receiving a status of 404 for /user/ssodata. One of our Engineers @nicolas_sabena gave a terrific explanation on this that I am going to quote below:

TL;DR: the 404 from /user/ssodata is no cause for concern. Read below for more details.

When a user already has a session in Auth0 and an application requests a new token, Auth0’s Lock used to present a “Last time you logged in as john.doe@acme.com” button in the hosted login page that would let you reuse the existing session easily (no need to enter credentials again).

New tenants (or existing tenants that turn on “Enable Seamless SSO” in the tenant advanced options) behave differently: if the user already has a session in place then the login step is skipped completely so that the hosted login page is not even displayed (although the user might see other prompts such as MFA or consent).

When this “Seamless SSO” functionality is enabled (which, again, is the default and only behavior available on new tenants) the /user/ssodata returns 404 , because its functionality is not really needed anymore.

Lock still tries to call /user/ssodata anyway (because Lock, running in the browser, is unaware of the tenant configuration), but when getting a 404 response it simply assumes that there’s no session in place (which is the right assumption to make, because if there was a valid session then the login page would not have been loaded).

Now to follow up on the 400 Bad Request generated by a Cookie getting larger after each logout. From looking over the HAR file it appears you are using the Auth0 Google Dev keys in production, we would recommend generating a fresh set of keys from Google for your production use case. I have linked a supporting doc below that can help you on that front.

https://auth0.com/docs/connections/social/google

Please let me know if you have any additional questions on this front, thanks!

6

Hi @James.Morrison,

Thanks for the info.

I generated new keys from Google and I am still getting the 400 Bad Request.

8

Hi Kevin. I just inspected the .HAR file.
This happens because of an error I reported in don't use cookies inside the HLP · Issue #882 · auth0/auth0.js · GitHub, and it should be fixed in Lock v11.13.0 (the latest release as of today).

Can you check if this works for you now? Not sure what the expiration time was at the time those cookies were set but if they are still there you might have to clear them.

9

Hi @nicolas_sabena
I still got the growing cookie problem with Lock v11.13.
The problem went away when I changed Lock to v11.3 however.

10

Hi again Kevin.

https://cdn.auth0.com/js/lock/11.13/lock.min.js will no longer generate cookies in the HLP. I just checked on my side and the extra cookies are no longer created (a few ones are still there, generated by the Auth0 domain to track the session, but no more than 5-6).

Are you are using Lock in the hosted login page?

11

Hi @nicolas_sabena .

I am using Lock in the hosted login page.
I have sent you a har file using lock v11.13.

1 Like
12

Thanks for the .HAR file @kevin.mcginley !. That helped to find the root cause: Lock v11.13 solves the cookie issue when email/password logins are used, but the problem is still there when other login methods are used (like passwordless or social providers).

I’ve created another issue for this at Don't use storage inside the HLP · Issue #896 · auth0/auth0.js · GitHub. You can subscribe to it so that you get notified of any developments.

In the meantime, you can downgrade the Lock version to 11.9.1 (cookie storage was added in 11.10).

2 Likes
13

UPDATE: this now has been finally fixed, in Auth0.js v9.9.1 and Lock v11.13.1. Thanks again @kevin.mcginley!

2 Likes
14

Do you mean Lock v11.13.1?

15

I do, corrected. Thanks!

16

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