My YunoHost server
Hardware: Hetzner VPS
YunoHost version: 184.108.40.206 (stable)
I have access to my server : SSH and Webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no
If yes, please explain:
If your request is related to an app, specify its name and version: Gitea 1.17.4~ynh1 and/or Forgejo 1.18.5-0~ynh2
Description of my issue
Hello! So I have been trying to get Gitea/Forgejo (issue reproduces basically identically between either, the main goal currently is to get Forgejo working however) working for a few months now, with the same issue happening every time.
What happens is:
- I install Gitea/Forgejo
- I go to the app and check my profile
- Instead of my email being the correct
firstname.lastname@example.org, it shows up as something like
For example right now I have both Forgejo and Gitea installed to see if both apps are still having the issues, and the emails are
I would love some help with this as I honestly have no clue on how to fix it and am not very keen on using GitLab instead of either of these
I really would appreciate if someone could find the root of this issue, here are the logs from a fresh reinstall and then me accessing the Forgejo page to initialise my account, if that helps: https://paste.yunohost.org/raw/evaxotafeg
And the install logs: https://paste.yunohost.org/raw/pubunejali
I looked at both Gitea and Forgejo and got the same as you… I didn’t have this problem with my rewrite of Gitea GitHub - ericgaspar/gitea_ynh where I get the email to display correctly. Might be worth looking for the diffs between the different
app.ini config files…
I’ve just finished looking into this and I think I might know the culprit in that case
The difference is in how the LDAP auth is added to Gitea I believe.
In the current Gitea installation script, the LDAP authentication is added through an SQL query to the Gitea database
On the other hand, in your rewrite it’s added directly through the Gitea binary
I think if something were to be causing the issue, this could be the culprit (or potentially one of a few)
…maybe, but Forgejo is also using CLI to setup LDAP and it as the same behaviour as Gitea with SQL query… forgejo_ynh/install at 51ebe17d70a7def7076e9765e8837fb2d3dc5464 · YunoHost-Apps/forgejo_ynh · GitHub
I’ve managed to track down this issue to the following setting in
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
Setting it to
false before signing in as a user fixes this, so I can only assume the reverse proxy auth is currently broken in some capacity
the question is, why do we need
ENABLE_REVERSE_PROXY_AUTHENTICATION set to true?
I can only assume it was enabled to allow the Single Sign-On / Proxy Auth to work, but if it breaks the whole authorisation process it might be best to disable it until a fix is found
@mchal and I will use the Forgejo instance on tar.black with
ENABLE_REVERSE_PROXY_AUTHENTICATION set to
false. Thank you for your help @ericg (and @mchal), and let us know if there are changes to YunoHost or the Forgejo app that will allow for login with SSO without breaking things Thanks!
I think, I found the solution. I create a PR to resolve it (26 authentication by grosmanal · Pull Request #27 · YunoHost-Apps/forgejo_ynh · GitHub).
If someone can test the branch :
26-authentication, it would be great.
Yes! This seems as if it may have worked. I spun up a test YunoHost instance on a separate Hetzner VPS @
<domain.tld>, and after installing Forgejo from my fork with your commits on it (https://github.com/futiiile/forgejo_ynh), it seems to have worked right away!
Thank you for figuring it out, I hope to see this fix on the main branch soon!
(Also, maybe someone should apply this fix to the Gitea package too as it has the same issue )
I just wait for the yunohost automated tests to pass, and I merge it.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.