github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-22 06:24:14 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Ldap Admin UI looses encryption settings on save #8561

New Issue
Closed
opened 2025-11-02 08:10:50 -06:00 by GiteaMirror · 8 comments
GiteaMirror commented 2025-11-02 08:10:50 -06:00
Owner
Copy Link

Originally created by @gtudan on GitHub (Feb 14, 2022).

Gitea Version

1.16.1

Operating System

Linux

Browser Version

Safari 15.3

Can you reproduce the bug on the Gitea demo site?

No

Description

When I edit an LDAP Authentication source without touching the encryption settings and submit the form, the encryption settings will revert to "unencrypted". Then I have to edit the form again and select (for example) StartTLS.

The encryption status is shown correct, but will still revert to unencrypted unless I explicitly set it to StartTLS before saving.

Screenshots

Bildschirmfoto 2022-02-14 um 13 54 00
Originally created by @gtudan on GitHub (Feb 14, 2022). ### Gitea Version 1.16.1 ### Operating System Linux ### Browser Version Safari 15.3 ### Can you reproduce the bug on the Gitea demo site? No ### Description When I edit an LDAP Authentication source without touching the encryption settings and submit the form, the encryption settings will revert to "unencrypted". Then I have to edit the form again and select (for example) StartTLS. The encryption status is shown correct, but will still revert to unencrypted unless I explicitly set it to StartTLS before saving. ### Screenshots <img width="456" alt="Bildschirmfoto 2022-02-14 um 13 54 00" src="https://user-images.githubusercontent.com/419425/153868040-c86ee467-7f2a-4c2f-847e-2dc6e521a516.png">
GiteaMirror added the type/bug label 2025-11-02 08:10:50 -06:00
GiteaMirror commented 2025-11-02 08:10:51 -06:00
Author
Owner
Copy Link

@tcpluess commented on GitHub (Feb 21, 2022):

I can confirm this. Also, since I updated to 1.16.1, the LDAP authentication seems to be broken and users can no longer sign in at all. However it is difficult to debug, is there somewhere an option to see the LDAP error messages?
perhaps it would be good to have a LDAP test possibility.

@tcpluess commented on GitHub (Feb 21, 2022): I can confirm this. Also, since I updated to 1.16.1, the LDAP authentication seems to be broken and users can no longer sign in at all. However it is difficult to debug, is there somewhere an option to see the LDAP error messages? perhaps it would be good to have a LDAP test possibility.
GiteaMirror commented 2025-11-02 08:10:51 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 22, 2022):

I can confirm this. Also, since I updated to 1.16.1, the LDAP authentication seems to be broken and users can no longer sign in at all. However it is difficult to debug, is there somewhere an option to see the LDAP error messages? perhaps it would be good to have a LDAP test possibility.

There are some PRs have been merged into v1.16.2 and will be released soon.

@lunny commented on GitHub (Feb 22, 2022): > I can confirm this. Also, since I updated to 1.16.1, the LDAP authentication seems to be broken and users can no longer sign in at all. However it is difficult to debug, is there somewhere an option to see the LDAP error messages? perhaps it would be good to have a LDAP test possibility. There are some PRs have been merged into v1.16.2 and will be released soon.
GiteaMirror commented 2025-11-02 08:10:52 -06:00
Author
Owner
Copy Link

@tcpluess commented on GitHub (Feb 22, 2022):

lunny,
this is awesome, thanks.
In my situation, I have a couple users that are waiting to be able to use gitea again.
I am wonderin whether it is smarter to restore the backup, which is 1 week old, and lose one week of work on the server, OR whether I should wait for 1.16.2. Unfortnately I realised that it is not possible to downgrade after I found out that the login does not work.

@tcpluess commented on GitHub (Feb 22, 2022): lunny, this is awesome, thanks. In my situation, I have a couple users that are waiting to be able to use gitea again. I am wonderin whether it is smarter to restore the backup, which is 1 week old, and lose one week of work on the server, OR whether I should wait for 1.16.2. Unfortnately I realised that it is not possible to downgrade after I found out that the login does not work.
GiteaMirror commented 2025-11-02 08:10:52 -06:00
Author
Owner
Copy Link

@gtudan commented on GitHub (Feb 22, 2022):

Maybe try to reconfigure LDAP - in my case it helped to reset the encryption field and save again.

Am 22.02.2022 um 10:21 schrieb tcpluess @.***>:

lunny,
this is awesome, thanks.
In my situation, I have a couple users that are waiting to be able to use gitea again.
I am wonderin whether it is smarter to restore the backup, which is 1 week old, and lose one week of work on the server, OR whether I should wait for 1.16.2. Unfortnately I realised that it is not possible to downgrade after I found out that the login does not work.

—
Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/18766#issuecomment-1047586620, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADGMYKUSDIUBQ2SGGNJWETU4NIRJANCNFSM5OLLEBEA.
You are receiving this because you authored the thread.

@gtudan commented on GitHub (Feb 22, 2022): Maybe try to reconfigure LDAP - in my case it helped to reset the encryption field and save again. > Am 22.02.2022 um 10:21 schrieb tcpluess ***@***.***>: > > > lunny, > this is awesome, thanks. > In my situation, I have a couple users that are waiting to be able to use gitea again. > I am wonderin whether it is smarter to restore the backup, which is 1 week old, and lose one week of work on the server, OR whether I should wait for 1.16.2. Unfortnately I realised that it is not possible to downgrade after I found out that the login does not work. > > — > Reply to this email directly, view it on GitHub <https://github.com/go-gitea/gitea/issues/18766#issuecomment-1047586620>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADGMYKUSDIUBQ2SGGNJWETU4NIRJANCNFSM5OLLEBEA>. > You are receiving this because you authored the thread. >
GiteaMirror commented 2025-11-02 08:10:52 -06:00
Author
Owner
Copy Link

@tcpluess commented on GitHub (Feb 22, 2022):

Maybe try to reconfigure LDAP - in my case it helped to reset the encryption field and save again.
…
Am 22.02.2022 um 10:21 schrieb tcpluess @.***>: lunny, this is awesome, thanks. In my situation, I have a couple users that are waiting to be able to use gitea again. I am wonderin whether it is smarter to restore the backup, which is 1 week old, and lose one week of work on the server, OR whether I should wait for 1.16.2. Unfortnately I realised that it is not possible to downgrade after I found out that the login does not work. — Reply to this email directly, view it on GitHub <#18766 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADGMYKUSDIUBQ2SGGNJWETU4NIRJANCNFSM5OLLEBEA. You are receiving this because you authored the thread.

Just checked, I cannot confirm this. I see that the encryption gets occasionally reset to "unencrypted" when I open the admin panel.

To also to confirm, I restored the backup from Jan 30, where I had Gitea 1.15.11 installed with the exact same configuration. This works fine. With 1.16.1 it does not work. However, restoring the backup also means that all database changes since Jan 30 are lost....

@tcpluess commented on GitHub (Feb 22, 2022): > Maybe try to reconfigure LDAP - in my case it helped to reset the encryption field and save again. > […](#) > Am 22.02.2022 um 10:21 schrieb tcpluess ***@***.***>: lunny, this is awesome, thanks. In my situation, I have a couple users that are waiting to be able to use gitea again. I am wonderin whether it is smarter to restore the backup, which is 1 week old, and lose one week of work on the server, OR whether I should wait for 1.16.2. Unfortnately I realised that it is not possible to downgrade after I found out that the login does not work. — Reply to this email directly, view it on GitHub <[#18766 (comment)](https://github.com/go-gitea/gitea/issues/18766#issuecomment-1047586620)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADGMYKUSDIUBQ2SGGNJWETU4NIRJANCNFSM5OLLEBEA>. You are receiving this because you authored the thread. Just checked, I cannot confirm this. I see that the encryption gets occasionally reset to "unencrypted" when I open the admin panel. To also to confirm, I restored the backup from Jan 30, where I had Gitea 1.15.11 installed with the exact same configuration. This works fine. With 1.16.1 it does not work. However, restoring the backup also means that all database changes since Jan 30 are lost....
GiteaMirror commented 2025-11-02 08:10:52 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 22, 2022):

I think #18856 should fix this.

@lunny commented on GitHub (Feb 22, 2022): I think #18856 should fix this.
GiteaMirror commented 2025-11-02 08:10:53 -06:00
Author
Owner
Copy Link

@richmahn commented on GitHub (Feb 22, 2022):

@lunny has it been verified that #18856 fixes it?

@richmahn commented on GitHub (Feb 22, 2022): @lunny has it been verified that #18856 fixes it?
GiteaMirror commented 2025-11-02 08:10:53 -06:00
Author
Owner
Copy Link

@tcpluess commented on GitHub (Feb 22, 2022):

@richmahn I can confirm that my gitea instance works now again.
1.15.x worked with LDAP, when I updated to 1.16.x a couple days ago LDAP was broken.
With the newest PRs, it seems to work again. I am now using 1.16.1+36-gf5a3c0dd6.

@tcpluess commented on GitHub (Feb 22, 2022): @richmahn I can confirm that my gitea instance works now again. 1.15.x worked with LDAP, when I updated to 1.16.x a couple days ago LDAP was broken. With the newest PRs, it seems to work again. I am now using 1.16.1+36-gf5a3c0dd6.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#8561
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?