Replies: 2 comments
-
Per #412 and #275 it appears that this should be supported (the 2.2.2 release notes too!), but no combination of things I have tried (with Authelia) has been successful. I essentially have the same questions listed here. Also tried adding or editing fastcgi_params in /etc/nginx/fastcgi_params (e.g. adding fastcgi_param REMOTE_USER $http_x_forwarded_user; or modifying the PHP_AUTH_USER does not automatically log any user in. Other services using Authelia are working. This may not be be active yet as @lenaxia points out. Expect I may be missing something obvious. |
Beta Was this translation helpful? Give feedback.
-
This works today, it's simply that the container's nginx doesn't pass on the header. Add a file containing the below to 'custom-cont-init.d' folder in heimdall/freshrss config dir:
Nginx will immediately pick up the config change on restart (this script is run last, on app startup but nginx will read the change). |
Beta Was this translation helpful? Give feedback.
-
Support exists for PHP_AUTH_USER, however Authelia for instance only supports HTTP_REMOTE_USER.
Heimdall would read HTTP_REMOTE_USER and redirect accordingly to the user's dashboard. If the user does not exist, Heimdall would redirect to the user select page for manual login to occur.
Optionally, the Admin user can define a HTTP_REMOTE_GROUPS to support in order to manage access control. If the user exists and a group in HTTP_REMOTE_GROUPS matches the defined permissions group, they would be directed to their dashboard. Regardless if the user exists, if their HTTP_REMOTE_GROUPS does not match a defined group, they would be directed to the user select page
Beta Was this translation helpful? Give feedback.
All reactions