Inconsistent behaviour when LDAP user is not activated #2031

New Issue

GiteaMirror · 2025-11-02T04:21:43-06:00

GiteaMirror commented

2025-11-02 04:21:43 -06:00

Originally created by @leepfrog-ger on GitHub (Jul 9, 2018).

Gitea version (or commit ref): 1.4.2
Git version: not relevant
Operating system: Windows
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

Description

Consider the following scenario:

A user is authenticating via an LDAP authentication source
The authentication source has synchronization enabled and during one of those syncs it determines that all users need to be disabled (e.g. due to #4402)
Now affected accounts are disabled in the database even though the "live" check against LDAP will pass successful

Actual behaviour

The resulting behaviour is not consistent:

Users can login via web interface just fine (as this uses a live check against LDAP)
Users can Pull/Push through HTTPS just fine (as this uses a live check against LDAP)
Users cannot push/pull through SSH (tested with built-in SSH server; as this uses the "is_active" flag from the database)

Expected behaviour

The expectied behvaiour would be that either all of the three above work or all fail, but not a mix of both.

Personally I'd prefer if all would work (meaning that upon an SSH connection attempt a live check against LDAP would need to take place) but I'll leave that up for discussion.

Originally created by @leepfrog-ger on GitHub (Jul 9, 2018). - Gitea version (or commit ref): 1.4.2 - Git version: not relevant - Operating system: Windows - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [x] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description Consider the following scenario: - A user is authenticating via an LDAP authentication source - The authentication source has synchronization enabled and during one of those syncs it determines that all users need to be disabled (e.g. due to #4402) - Now affected accounts are disabled in the database even though the "live" check against LDAP will pass successful **Actual behaviour** The resulting behaviour is not consistent: - Users **can** login via web interface just fine (as this uses a live check against LDAP) - Users **can** Pull/Push through HTTPS just fine (as this uses a live check against LDAP) - Users **cannot** push/pull through SSH (tested with built-in SSH server; as this uses the "is_active" flag from the database) **Expected behaviour** The expectied behvaiour would be that either all of the three above work or all fail, but not a mix of both. Personally I'd prefer if all would work (meaning that upon an SSH connection attempt a live check against LDAP would need to take place) but I'll leave that up for discussion.

GiteaMirror added the issue/confirmed type/enhancement topic/authentication labels 2025-11-02 04:21:43 -06:00

GiteaMirror commented

2025-11-02 04:21:44 -06:00

@stale[bot] commented on GitHub (Jan 19, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 19, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:21:44 -06:00

@stale[bot] commented on GitHub (Mar 23, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Mar 23, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror referenced this issue

2025-11-02 12:04:18 -06:00

[PR #2031] [CLOSED] update git module to fix bugs in fact #16189

GiteaMirror referenced this issue

2025-11-02 12:04:25 -06:00

[PR #2037] [MERGED] update git module #16193

Sign in to join this conversation.