Grist doesn't respect changes in FORWARD_AUTH_HEADER when doing SSO
See original GitHub issueBased on following how-tos: https://community.getgrist.com/t/a-template-for-self-hosting-grist-with-traefik-and-docker-compose/856 https://community.getgrist.com/t/grist-authelia-custom-logout-path/967
… I have setup Grist with Caddy as Reverse Proxy and Authelia for authentication. But I think there is an error on Grist when it comes to single sign on.
For showing the problem I have installed 2 different whoami, whoami.example.com and whoami2.example.com. Both secured with Authelia. Also Grist is secured.
Logout will be catched on all 3 apps by Caddy when calling /signed-out
:
1. open in a tab whoami.example.com, login with Authelia
Result: Remote-Email: myuser@example.com, Cookie: 123
2. open in a tab whoami2.example.com
Result: Remote-Email: myuser@example.com, Cookie: 123
3. open in a tab grist.example.com, press sign-in
Result: signed in automatically, Auth[GET]: id 6 email myuser@example.com, Cookie: 123
4. open whoami.example.com/signed-out
Result: Authelia login page returns to both whoami and whoami2
on grist Auth[GET]: id 6 email myuser@example.com, Cookie: 123, stil logged in!!
5. login to whoami.example.com with anotheruser
Result: whoami and whoami2 are logged in with Remote-Email: anotheruser@example.com, Cookie: 789
on grist still Auth[GET]: id 6 email myuser@example.com, but Cookie is: 789
Everything works fine as long as I only use Grist for Login/Logout. When I login on another Webapp first, Grist doesn’t respect the new login from another user.
Issue Analytics
- State:
- Created a year ago
- Comments:9 (4 by maintainers)
Top Results From Across the Web
Forwarded headers - Grist Help Center
Set GRIST_FORWARD_AUTH_HEADER to a header that will contain authorized user emails, say x-forwarded-user . This needs to match what your middleware will set....
Read more >Better support for self-hosting login solution · Issue #44 - GitHub
Authentik looks like a decent self-hosted sso solution. I just tested it and it works well with Grist, using SAML.
Read more >Chrome 19 doesn't respect basic auth details embedded in ...
I am having the issue in #39, but not in an extension, just on a normal web page. xhr.open(..., username, password) just doesn't...
Read more >How to Configure Request Header Authentication in Nexus ...
This article will walk you through the steps needed to set up request header authentication for Nexus Repository Manager using the Apache web ......
Read more >Why doesn't the browser reuse the authorization headers after ...
The advantage is that the authentication credentials will never find their ... When using HTML, one would normally assign an URI to the...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks for spelling this out @helmut72. It makes sense, the
ForwardAuthLogin
mechanism as implemented doesn’t play well with peer sites. I think the fix could be fairly straightforward.Thanks! This is enough for personal use, because I’m being able to include a tables/URLs in Markdown documents and no one need an account on my Grist installation to view/open the table.
I understand that this takes a longer time, also needs testing. Will ask in some months again. 😉 Thanks for sharing this undocumented feature. Unfortunately I’m busy these days and need to test it, but this should help.