SSO login fail for chrome/chromium/apps #3

New Issue

pratyush · 2022-12-22T02:02:54+01:00

pratyush commented

2022-12-22 02:02:54 +01:00

pratyush commented

2022-12-22 04:51:38 +01:00

reported by @nish

Login via sso auth is functional as expected using firefox but fails when using Chrome/Chromium Holds true for mobile browsers (checked Android)

Other browser tests pending!

Furthermore, according to the intercompatibility doc, it should work with the mobile application Tusky.

The issue here is Authentication but it only occurs with this service.

reported by @nish Login via sso auth is functional as expected using `firefox` but fails when using `Chrome`/`Chromium` Holds true for mobile browsers (checked Android) Other browser tests pending! Furthermore, according to the [intercompatibility](https://github.com/jointakahe/takahe/blob/main/docs/intercompatibility.rst) doc, it should work with the mobile application [Tusky](https://f-droid.org/en/packages/com.keylesspalace.tusky/). The issue here is Authentication but it only occurs with this service.

pratyush changed title from ~~Accountz ooo[]]]]]]]]]]]]~~ to SSO login fail for chrome/chromium/apps

2022-12-22 05:03:44 +01:00

Georg commented

2022-12-22 11:05:19 +01:00

Please provide * client side error messages * screenshots of the error * steps to reproduce the issue

as

but fails

is not descriptive.

Please provide * client side error messages * screenshots of the error * steps to reproduce the issue as > but fails is not descriptive.

Georg commented

2022-12-22 11:06:12 +01:00

The issue here is Authentication but it only occurs with this service.

That will indeed be an issue if the application tries to authenticate purely to Django (presumably using some headers). The correct solution is for the application to support API tokens, although this not being a user friendly solution, as Takahe is not exposing the functionality for user self-service.

> The issue here is Authentication but it only occurs with this service. That will indeed be an issue if the application tries to authenticate purely to Django (presumably using some headers). The correct solution is for the application to support API tokens, although this not being a user friendly solution, as Takahe is not exposing the functionality for user self-service.

Georg commented

2022-12-22 11:40:29 +01:00

I was able to reproduce the issue in Chromium. The error can be found upon inspecting the browser console for the POST request to /saml2/acs after submitting the login through the IDP (SSO):

Hence the issue has been resolved by changing

SESSION_COOKIE_SECURE = False

to

SESSION_COOKIE_SECURE = True

in settings.py.

Let me know if the issue is equally resolved on your end.

I was able to reproduce the issue in Chromium. The error can be found upon inspecting the browser console for the POST request to /saml2/acs after submitting the login through the IDP (SSO): ![image](/attachments/63316c50-be18-42a3-8a13-014283c30ee6) Hence the issue has been resolved by changing ``` SESSION_COOKIE_SECURE = False ``` to ``` SESSION_COOKIE_SECURE = True ``` in `settings.py`. Let me know if the issue is equally resolved on your end.

image.png

129 KiB

pratyush commented

2022-12-22 17:48:29 +01:00

I knew it would resolve that way, just by reading the Network Tab in both since it gives the solution in chrome inspect tool. But I wasnt certain so I left it to you

Agreed, I was to follow up with comment on the two contrasting browser consoles images and suggested soln, I was sidetracked into another issue and we can discuss that

I knew it would resolve that way, just by reading the Network Tab in both since it gives the solution in chrome inspect tool. But I wasnt certain so I left it to you Agreed, I was to follow up with comment on the two contrasting browser consoles images and suggested soln, I was sidetracked into another issue and we can discuss that

pratyush commented

2022-12-23 01:02:28 +01:00