Hi,
we are following the documentation for prodigy[company] but we get a 307 response "Temporary Redirect" and the SSO authentication procedure never starts.
Could you point us in the direction of potential reasons?
Thank you in advance,
Marco
Hi @marcoB,
Is that happening when you're testing with a locally deployed Prodigy or on a public domain? Could check if the URL under Location in the 307 response is correct?
Thanks!
Hi @magdaaniol,
I am not sure what you mean by location. We don't have URL but IP addresses
in the lines like:
INFO: 10.X.X.X:YYYYY - "GET login/callback?code=....
INFO: 10.X.X.X:ZZZZZ - "GET login/ HTTP/1.1" 307 Temporary Redirect
Do you mean the two IP addresses?
Hi @marcoB ,
Looking back I realize I haven't expressed myself clearly enough. Sorry!
I think we should inspect the URL that the SSO is trying to redirect to. For that, we would have inspect the body of the HTTP request, e.g. via browser's developer tools. After starting your Prodigy server, if you open a new tab and left click anywhere, you can select inspect (or similar depending on what browser you use) from the local menu. Now, if you access the Prodigy URL, you should see the different HTTP requests in the Network tab including the 307 one which gets stuck.
If you inspect its Headers you should see a URL under Location key which should be a valid URL if you copy it and try it in another tab. It should bring up the sign-in page.
We should check if this generated URL is valid. The 307 response at this point is expected, the problem is probably with the redirect URL.
Attaching a screenshot to show where this info is located:
Thank you @magdaaniol
Following up with the IT team, it seems that (if I understand correctly) before authentication, prodigy sends a request with the following: __prodigy_cauth_id_token__ and __prodigy_cauth_access_token__ . This results in big headers (over 4k) which are blocked by the gateway.
Could you suggest any workaround from prodigy side?
Hi @marcoB ,
We've dug into this a bit and there's indeed a change we can make to make them smaller. Currently the code requires the profile scope. This includes information such as given name, family name, URL of profile photo, etc. We're using this to get the user's name to display.
We can change it so that this information isn't required, and we just display the user's email. This halves the size of the ID token.
In our testing the headers were coming in below 4k before this change though. I suppose it could depend on the details that are actually in the profile data? For instance names in certain alphabets could expand the size a bit?
Overall what's happening here is that we're asking Auth0 to give us back signed JWT's that represent the user's identity and access rights. We're not attaching custom claims to these so I wouldn't think they'd be unusually large. We'll go ahead with the change to make the profile scope optional though, which hopefully will resolve it for you.
Hi @marcoB ,
We have just released an update to Prodigy SSO plugin (now version 0.2.0), that makes it possible to exclude profile from scopes via PRODIGY_OIDC_REQUIRED_SCOPES env variable.
The current default is openid profile email so setting it to openid email will exclude profile resulting in smaller payloads.
To upgrade the company plugins package:
python -m pip install --upgrade prodigy-company-plugins --extra-index-url https://XXXX-XXXX-XXXX-XXXX@download.prodi.gy
Thank you, we will test it as soon as possible!
am I correct that we would need to include this line in the Dockerfile:
ENV PRODIGY_OIDC_REQUIRED_SCOPES = "openid email"
Thank you!
Hi @marcoB ,
That's right. That should work. Alternatively, follow the pattern of however your other SSO env variables are defined, in case it's different.