public inbox for [email protected]help / color / mirror / Atom feed
Regarding #8580 10+ messages / 3 participants [nested] [flat]
* Regarding #8580 @ 2025-05-09 07:45 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Akshay Joshi @ 2025-05-09 07:45 UTC (permalink / raw) To: pgadmin-hackers Hi Hackers/Dave, I have started working on issue #8580 <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the correct error message should be displayed based on the user's authentication source when an incorrect password is provided. *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = ['internal', 'ldap']. A user with the email [email protected] exists only as an internal user in the database, and there is no corresponding LDAP entry for this user. When this user attempts to log in with an incorrect password, the system first tries internal authentication, which fails. It then proceeds to check the next authentication source (LDAP), as per the configured logic. Since no matching LDAP user exists, an LDAP-related error is returned, even though the user is intended to be authenticated only internally. His/her account will never get locked. This behavior appears to be incorrect to me. I’m proposing two possible solutions to address it: *Solution 1 (Logic Changes): * *Scenario 1: ['internal', 'ldap']:* - If a user exists in the database with the specified authentication source (internal), attempt to authenticate using internal. If authentication fails, return an error. No need to check for the LDAP or next auth source. - If no user-auth source combination is found for internal, proceed to the next authentication source (LDAP). Attempt LDAP login, and if successful (and auto-create is enabled), create the user in the database. *Scenario 2: ['ldap', 'internal']* - If the LDAP user does not exist in the database, but the same user exists as an internal user, first try LDAP authentication. If it fails, fall back to internal or the next configured auth source in the list. - If the LDAP user does exist in the database, attempt to authenticate via LDAP. If LDAP authentication fails, return the error without checking for the next authentication source. *Note:* - In the above approach, it is the administrator's responsibility to configure the order of authentication sources appropriately. *Solution 2 (GUI Changes): *Add a single login button with a drop-down menu to select the authentication source (e.g., "Internal", "LDAP") on the login page, as we already display N buttons for N OAuth2 configurations, which can be removed for a cleaner user experience. OR Alternatively, add a separate button labeled "Login with LDAP" to explicitly trigger LDAP authentication. Need your inputs/suggestions on this. Akshay Joshi Principal Engineer | Engineering Manager | pgAdmin Hacker enterprisedb.com * Blog*: https://www.enterprisedb.com/akshay-joshi * GitHub*: https://github.com/akshay-joshi * LinkedIn*: https:// <http://goog_373708537; www.linkedin.com/in/akshay-joshi-a9317b14 ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> @ 2025-05-09 09:53 ` Dave Page <[email protected]> 2025-05-09 10:33 ` Re: Regarding #8580 Khushboo Vashi <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Dave Page @ 2025-05-09 09:53 UTC (permalink / raw) To: Akshay Joshi <[email protected]>; +Cc: pgadmin-hackers Hi On Fri, 9 May 2025 at 08:45, Akshay Joshi <[email protected]> wrote: > Hi Hackers/Dave, > > I have started working on issue #8580 > <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the correct > error message should be displayed based on the user's authentication source > when an incorrect password is provided. > > *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = > ['internal', 'ldap']. A user with the email [email protected] exists only as an > internal user in the database, and there is no corresponding LDAP entry for > this user. When this user attempts to log in with an incorrect password, > the system first tries internal authentication, which fails. It then > proceeds to check the next authentication source (LDAP), as per the > configured logic. Since no matching LDAP user exists, an LDAP-related error > is returned, even though the user is intended to be authenticated only > internally. His/her account will never get locked. > > This behavior appears to be incorrect to me. I’m proposing two possible > solutions to address it: > *Solution 1 (Logic Changes): * > *Scenario 1: ['internal', 'ldap']:* > > - If a user exists in the database with the specified authentication > source (internal), attempt to authenticate using internal. If > authentication fails, return an error. No need to check for the LDAP or > next auth source. > > Yes. > > - If no user-auth source combination is found for internal, proceed to > the next authentication source (LDAP). Attempt LDAP login, and if > successful (and auto-create is enabled), create the user in the database. > > Yes. > *Scenario 2: ['ldap', 'internal']* > > - If the LDAP user does not exist in the database, but the same user > exists as an internal user, first try LDAP authentication. If it fails, > fall back to internal or the next configured auth source in the list. > > Yes. > > - If the LDAP user does exist in the database, attempt to authenticate > via LDAP. If LDAP authentication fails, return the error without checking > for the next authentication source. > > Yes. > *Note:* - In the above approach, it is the administrator's responsibility > to configure the order of authentication sources appropriately. > Agreed. > > *Solution 2 (GUI Changes): *Add a single login button with a drop-down > menu to select the authentication source (e.g., "Internal", "LDAP") on the > login page, as we already display N buttons for N OAuth2 configurations, > which can be removed for a cleaner user experience. > OR > Alternatively, add a separate button labeled "Login with LDAP" to > explicitly trigger LDAP authentication. > I don't like this solution, as it requires the end user to understand how their admin has setup the backend authentication. That seems like something they shouldn't need to concern themselves with. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> @ 2025-05-09 10:33 ` Khushboo Vashi <[email protected]> 2025-05-09 10:49 ` Re: Regarding #8580 Dave Page <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Khushboo Vashi @ 2025-05-09 10:33 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote: > Hi > > On Fri, 9 May 2025 at 08:45, Akshay Joshi <[email protected]> > wrote: > >> Hi Hackers/Dave, >> >> I have started working on issue #8580 >> <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the correct >> error message should be displayed based on the user's authentication source >> when an incorrect password is provided. >> >> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = >> ['internal', 'ldap']. A user with the email [email protected] exists only as an >> internal user in the database, and there is no corresponding LDAP entry for >> this user. When this user attempts to log in with an incorrect password, >> the system first tries internal authentication, which fails. It then >> proceeds to check the next authentication source (LDAP), as per the >> configured logic. Since no matching LDAP user exists, an LDAP-related error >> is returned, even though the user is intended to be authenticated only >> internally. His/her account will never get locked. >> >> This behavior appears to be incorrect to me. I’m proposing two possible >> solutions to address it: >> *Solution 1 (Logic Changes): * >> *Scenario 1: ['internal', 'ldap']:* >> >> - If a user exists in the database with the specified authentication >> source (internal), attempt to authenticate using internal. If >> authentication fails, return an error. No need to check for the LDAP or >> next auth source. >> >> Yes. > >> >> - If no user-auth source combination is found for internal, proceed >> to the next authentication source (LDAP). Attempt LDAP login, and if >> successful (and auto-create is enabled), create the user in the database. >> >> Yes. > > >> *Scenario 2: ['ldap', 'internal']* >> >> - If the LDAP user does not exist in the database, but the same user >> exists as an internal user, first try LDAP authentication. If it fails, >> fall back to internal or the next configured auth source in the list. >> >> Yes. > >> >> - If the LDAP user does exist in the database, attempt to >> authenticate via LDAP. If LDAP authentication fails, return the error >> without checking for the next authentication source. >> >> Yes. > If the user is registered for multiple authentications (per entries in our database), the next in line should be checked if one fails. > >> *Note:* - In the above approach, it is the administrator's >> responsibility to configure the order of authentication sources >> appropriately. >> > > Agreed. > > >> >> *Solution 2 (GUI Changes): *Add a single login button with a drop-down >> menu to select the authentication source (e.g., "Internal", "LDAP") on the >> login page, as we already display N buttons for N OAuth2 configurations, >> which can be removed for a cleaner user experience. >> OR >> Alternatively, add a separate button labeled "Login with LDAP" to >> explicitly trigger LDAP authentication. >> > > I don't like this solution, as it requires the end user to understand how > their admin has setup the backend authentication. That seems like something > they shouldn't need to concern themselves with. > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > pgEdge: https://www.pgedge.com > > ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 10:33 ` Re: Regarding #8580 Khushboo Vashi <[email protected]> @ 2025-05-09 10:49 ` Dave Page <[email protected]> 2025-05-09 11:13 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Dave Page @ 2025-05-09 10:49 UTC (permalink / raw) To: Khushboo Vashi <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, 9 May 2025 at 11:34, Khushboo Vashi <[email protected]> wrote: > > > On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote: > >> Hi >> >> On Fri, 9 May 2025 at 08:45, Akshay Joshi <[email protected]> >> wrote: >> >>> Hi Hackers/Dave, >>> >>> I have started working on issue #8580 >>> <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the >>> correct error message should be displayed based on the user's >>> authentication source when an incorrect password is provided. >>> >>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = >>> ['internal', 'ldap']. A user with the email [email protected] exists only as an >>> internal user in the database, and there is no corresponding LDAP entry for >>> this user. When this user attempts to log in with an incorrect password, >>> the system first tries internal authentication, which fails. It then >>> proceeds to check the next authentication source (LDAP), as per the >>> configured logic. Since no matching LDAP user exists, an LDAP-related error >>> is returned, even though the user is intended to be authenticated only >>> internally. His/her account will never get locked. >>> >>> This behavior appears to be incorrect to me. I’m proposing two possible >>> solutions to address it: >>> *Solution 1 (Logic Changes): * >>> *Scenario 1: ['internal', 'ldap']:* >>> >>> - If a user exists in the database with the specified authentication >>> source (internal), attempt to authenticate using internal. If >>> authentication fails, return an error. No need to check for the LDAP or >>> next auth source. >>> >>> Yes. >> >>> >>> - If no user-auth source combination is found for internal, proceed >>> to the next authentication source (LDAP). Attempt LDAP login, and if >>> successful (and auto-create is enabled), create the user in the database. >>> >>> Yes. >> >> >>> *Scenario 2: ['ldap', 'internal']* >>> >>> - If the LDAP user does not exist in the database, but the same user >>> exists as an internal user, first try LDAP authentication. If it fails, >>> fall back to internal or the next configured auth source in the list. >>> >>> Yes. >> >>> >>> - If the LDAP user does exist in the database, attempt to >>> authenticate via LDAP. If LDAP authentication fails, return the error >>> without checking for the next authentication source. >>> >>> Yes. >> > > > If the user is registered for multiple authentications (per entries in our > database), the next in line should be checked if one fails.= > I think that's reasonable, but *only* in that case where there's another source already present in the DB. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 10:33 ` Re: Regarding #8580 Khushboo Vashi <[email protected]> 2025-05-09 10:49 ` Re: Regarding #8580 Dave Page <[email protected]> @ 2025-05-09 11:13 ` Akshay Joshi <[email protected]> 2025-05-09 11:20 ` Re: Regarding #8580 Dave Page <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Akshay Joshi @ 2025-05-09 11:13 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; pgadmin-hackers On Fri, May 9, 2025 at 4:20 PM Dave Page <[email protected]> wrote: > > > On Fri, 9 May 2025 at 11:34, Khushboo Vashi < > [email protected]> wrote: > >> >> >> On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote: >> >>> Hi >>> >>> On Fri, 9 May 2025 at 08:45, Akshay Joshi <[email protected]> >>> wrote: >>> >>>> Hi Hackers/Dave, >>>> >>>> I have started working on issue #8580 >>>> <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the >>>> correct error message should be displayed based on the user's >>>> authentication source when an incorrect password is provided. >>>> >>>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = >>>> ['internal', 'ldap']. A user with the email [email protected] exists only as >>>> an internal user in the database, and there is no corresponding LDAP entry >>>> for this user. When this user attempts to log in with an incorrect >>>> password, the system first tries internal authentication, which fails. It >>>> then proceeds to check the next authentication source (LDAP), as per the >>>> configured logic. Since no matching LDAP user exists, an LDAP-related error >>>> is returned, even though the user is intended to be authenticated only >>>> internally. His/her account will never get locked. >>>> >>>> This behavior appears to be incorrect to me. I’m proposing two possible >>>> solutions to address it: >>>> *Solution 1 (Logic Changes): * >>>> *Scenario 1: ['internal', 'ldap']:* >>>> >>>> - If a user exists in the database with the specified >>>> authentication source (internal), attempt to authenticate using internal. >>>> If authentication fails, return an error. No need to check for the LDAP or >>>> next auth source. >>>> >>>> Yes. >>> >>>> >>>> - If no user-auth source combination is found for internal, proceed >>>> to the next authentication source (LDAP). Attempt LDAP login, and if >>>> successful (and auto-create is enabled), create the user in the database. >>>> >>>> Yes. >>> >>> >>>> *Scenario 2: ['ldap', 'internal']* >>>> >>>> - If the LDAP user does not exist in the database, but the >>>> same user exists as an internal user, first try LDAP authentication. If it >>>> fails, fall back to internal or the next configured auth source in the >>>> list. >>>> >>>> Yes. >>> >>>> >>>> - If the LDAP user does exist in the database, attempt to >>>> authenticate via LDAP. If LDAP authentication fails, return the error >>>> without checking for the next authentication source. >>>> >>>> Yes. >>> >> >> >> If the user is registered for multiple authentications (per entries in >> our database), the next in line should be checked if one fails.= >> > > I think that's reasonable, but *only* in that case where there's another > source already present in the DB. > In that case, the core issue remains unresolved. As mentioned earlier, the system checks internal authentication first (based on the configured order), and then attempts LDAP if the user exists. However, it consistently returns an error for LDAP, and the account is never locked even after exceeding the maximum number of login attempts. > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > pgEdge: https://www.pgedge.com > > ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 10:33 ` Re: Regarding #8580 Khushboo Vashi <[email protected]> 2025-05-09 10:49 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 11:13 ` Re: Regarding #8580 Akshay Joshi <[email protected]> @ 2025-05-09 11:20 ` Dave Page <[email protected]> 2025-05-09 11:48 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Dave Page @ 2025-05-09 11:20 UTC (permalink / raw) To: Akshay Joshi <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; pgadmin-hackers On Fri, 9 May 2025 at 12:14, Akshay Joshi <[email protected]> wrote: > > > On Fri, May 9, 2025 at 4:20 PM Dave Page <[email protected]> wrote: > >> >> >> On Fri, 9 May 2025 at 11:34, Khushboo Vashi < >> [email protected]> wrote: >> >>> >>> >>> On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote: >>> >>>> Hi >>>> >>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi < >>>> [email protected]> wrote: >>>> >>>>> Hi Hackers/Dave, >>>>> >>>>> I have started working on issue #8580 >>>>> <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the >>>>> correct error message should be displayed based on the user's >>>>> authentication source when an incorrect password is provided. >>>>> >>>>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = >>>>> ['internal', 'ldap']. A user with the email [email protected] exists only as >>>>> an internal user in the database, and there is no corresponding LDAP entry >>>>> for this user. When this user attempts to log in with an incorrect >>>>> password, the system first tries internal authentication, which fails. It >>>>> then proceeds to check the next authentication source (LDAP), as per the >>>>> configured logic. Since no matching LDAP user exists, an LDAP-related error >>>>> is returned, even though the user is intended to be authenticated only >>>>> internally. His/her account will never get locked. >>>>> >>>>> This behavior appears to be incorrect to me. I’m proposing two >>>>> possible solutions to address it: >>>>> *Solution 1 (Logic Changes): * >>>>> *Scenario 1: ['internal', 'ldap']:* >>>>> >>>>> - If a user exists in the database with the specified >>>>> authentication source (internal), attempt to authenticate using internal. >>>>> If authentication fails, return an error. No need to check for the LDAP or >>>>> next auth source. >>>>> >>>>> Yes. >>>> >>>>> >>>>> - If no user-auth source combination is found for internal, >>>>> proceed to the next authentication source (LDAP). Attempt LDAP login, and >>>>> if successful (and auto-create is enabled), create the user in the database. >>>>> >>>>> Yes. >>>> >>>> >>>>> *Scenario 2: ['ldap', 'internal']* >>>>> >>>>> - If the LDAP user does not exist in the database, but the >>>>> same user exists as an internal user, first try LDAP authentication. If it >>>>> fails, fall back to internal or the next configured auth source in the >>>>> list. >>>>> >>>>> Yes. >>>> >>>>> >>>>> - If the LDAP user does exist in the database, attempt to >>>>> authenticate via LDAP. If LDAP authentication fails, return the error >>>>> without checking for the next authentication source. >>>>> >>>>> Yes. >>>> >>> >>> >>> If the user is registered for multiple authentications (per entries in >>> our database), the next in line should be checked if one fails.= >>> >> >> I think that's reasonable, but *only* in that case where there's another >> source already present in the DB. >> > > In that case, the core issue remains unresolved. As mentioned earlier, > the system checks internal authentication first (based on the configured > order), and then attempts LDAP if the user exists. However, it consistently > returns an error for LDAP, and the account is never locked even after > exceeding the maximum number of login attempts. > So, just lock all matching accounts. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 10:33 ` Re: Regarding #8580 Khushboo Vashi <[email protected]> 2025-05-09 10:49 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 11:13 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 11:20 ` Re: Regarding #8580 Dave Page <[email protected]> @ 2025-05-09 11:48 ` Akshay Joshi <[email protected]> 2025-05-09 13:01 ` Re: Regarding #8580 Dave Page <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Akshay Joshi @ 2025-05-09 11:48 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; pgadmin-hackers On Fri, May 9, 2025 at 4:50 PM Dave Page <[email protected]> wrote: > > > On Fri, 9 May 2025 at 12:14, Akshay Joshi <[email protected]> > wrote: > >> >> >> On Fri, May 9, 2025 at 4:20 PM Dave Page <[email protected]> wrote: >> >>> >>> >>> On Fri, 9 May 2025 at 11:34, Khushboo Vashi < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote: >>>> >>>>> Hi >>>>> >>>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Hackers/Dave, >>>>>> >>>>>> I have started working on issue #8580 >>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the >>>>>> correct error message should be displayed based on the user's >>>>>> authentication source when an incorrect password is provided. >>>>>> >>>>>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = >>>>>> ['internal', 'ldap']. A user with the email [email protected] exists only as >>>>>> an internal user in the database, and there is no corresponding LDAP entry >>>>>> for this user. When this user attempts to log in with an incorrect >>>>>> password, the system first tries internal authentication, which fails. It >>>>>> then proceeds to check the next authentication source (LDAP), as per the >>>>>> configured logic. Since no matching LDAP user exists, an LDAP-related error >>>>>> is returned, even though the user is intended to be authenticated only >>>>>> internally. His/her account will never get locked. >>>>>> >>>>>> This behavior appears to be incorrect to me. I’m proposing two >>>>>> possible solutions to address it: >>>>>> *Solution 1 (Logic Changes): * >>>>>> *Scenario 1: ['internal', 'ldap']:* >>>>>> >>>>>> - If a user exists in the database with the specified >>>>>> authentication source (internal), attempt to authenticate using internal. >>>>>> If authentication fails, return an error. No need to check for the LDAP or >>>>>> next auth source. >>>>>> >>>>>> Yes. >>>>> >>>>>> >>>>>> - If no user-auth source combination is found for internal, >>>>>> proceed to the next authentication source (LDAP). Attempt LDAP login, and >>>>>> if successful (and auto-create is enabled), create the user in the database. >>>>>> >>>>>> Yes. >>>>> >>>>> >>>>>> *Scenario 2: ['ldap', 'internal']* >>>>>> >>>>>> - If the LDAP user does not exist in the database, but the >>>>>> same user exists as an internal user, first try LDAP authentication. If it >>>>>> fails, fall back to internal or the next configured auth source in the >>>>>> list. >>>>>> >>>>>> Yes. >>>>> >>>>>> >>>>>> - If the LDAP user does exist in the database, attempt to >>>>>> authenticate via LDAP. If LDAP authentication fails, return the error >>>>>> without checking for the next authentication source. >>>>>> >>>>>> Yes. >>>>> >>>> >>>> >>>> If the user is registered for multiple authentications (per entries in >>>> our database), the next in line should be checked if one fails.= >>>> >>> >>> I think that's reasonable, but *only* in that case where there's another >>> source already present in the DB. >>> >> >> In that case, the core issue remains unresolved. As mentioned earlier, >> the system checks internal authentication first (based on the configured >> order), and then attempts LDAP if the user exists. However, it consistently >> returns an error for LDAP, and the account is never locked even after >> exceeding the maximum number of login attempts. >> > > So, just lock all matching accounts. > One more scenario I just thought of with 'Auto Create User'. Suppose that [email protected] exists as an internal user in the database, but there is no corresponding LDAP entry. When the user attempts to log in with an incorrect password, the system checks the database for entries from other authentication sources and throws an error. In this case, the 'Auto Create User' functionality will not be triggered. I think we can either keep the current behavior as it is and close the issue (since I reported it), or add a rule with documentation saying that login should follow the order of the authentication sources. In most cases, users who prefer LDAP can just set the auth source to ['ldap', 'internal'], which should work fine. > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > pgEdge: https://www.pgedge.com > > ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 10:33 ` Re: Regarding #8580 Khushboo Vashi <[email protected]> 2025-05-09 10:49 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 11:13 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 11:20 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 11:48 ` Re: Regarding #8580 Akshay Joshi <[email protected]> @ 2025-05-09 13:01 ` Dave Page <[email protected]> 2025-05-12 07:07 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Dave Page @ 2025-05-09 13:01 UTC (permalink / raw) To: Akshay Joshi <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; pgadmin-hackers On Fri, 9 May 2025 at 12:48, Akshay Joshi <[email protected]> wrote: > > > On Fri, May 9, 2025 at 4:50 PM Dave Page <[email protected]> wrote: > >> >> >> On Fri, 9 May 2025 at 12:14, Akshay Joshi <[email protected]> >> wrote: >> >>> >>> >>> On Fri, May 9, 2025 at 4:20 PM Dave Page <[email protected]> wrote: >>> >>>> >>>> >>>> On Fri, 9 May 2025 at 11:34, Khushboo Vashi < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Hackers/Dave, >>>>>>> >>>>>>> I have started working on issue #8580 >>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the >>>>>>> correct error message should be displayed based on the user's >>>>>>> authentication source when an incorrect password is provided. >>>>>>> >>>>>>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = >>>>>>> ['internal', 'ldap']. A user with the email [email protected] exists only >>>>>>> as an internal user in the database, and there is no corresponding LDAP >>>>>>> entry for this user. When this user attempts to log in with an incorrect >>>>>>> password, the system first tries internal authentication, which fails. It >>>>>>> then proceeds to check the next authentication source (LDAP), as per the >>>>>>> configured logic. Since no matching LDAP user exists, an LDAP-related error >>>>>>> is returned, even though the user is intended to be authenticated only >>>>>>> internally. His/her account will never get locked. >>>>>>> >>>>>>> This behavior appears to be incorrect to me. I’m proposing two >>>>>>> possible solutions to address it: >>>>>>> *Solution 1 (Logic Changes): * >>>>>>> *Scenario 1: ['internal', 'ldap']:* >>>>>>> >>>>>>> - If a user exists in the database with the specified >>>>>>> authentication source (internal), attempt to authenticate using internal. >>>>>>> If authentication fails, return an error. No need to check for the LDAP or >>>>>>> next auth source. >>>>>>> >>>>>>> Yes. >>>>>> >>>>>>> >>>>>>> - If no user-auth source combination is found for internal, >>>>>>> proceed to the next authentication source (LDAP). Attempt LDAP login, and >>>>>>> if successful (and auto-create is enabled), create the user in the database. >>>>>>> >>>>>>> Yes. >>>>>> >>>>>> >>>>>>> *Scenario 2: ['ldap', 'internal']* >>>>>>> >>>>>>> - If the LDAP user does not exist in the database, but the >>>>>>> same user exists as an internal user, first try LDAP authentication. If it >>>>>>> fails, fall back to internal or the next configured auth source in the >>>>>>> list. >>>>>>> >>>>>>> Yes. >>>>>> >>>>>>> >>>>>>> - If the LDAP user does exist in the database, attempt to >>>>>>> authenticate via LDAP. If LDAP authentication fails, return the error >>>>>>> without checking for the next authentication source. >>>>>>> >>>>>>> Yes. >>>>>> >>>>> >>>>> >>>>> If the user is registered for multiple authentications (per entries in >>>>> our database), the next in line should be checked if one fails.= >>>>> >>>> >>>> I think that's reasonable, but *only* in that case where there's >>>> another source already present in the DB. >>>> >>> >>> In that case, the core issue remains unresolved. As mentioned earlier, >>> the system checks internal authentication first (based on the configured >>> order), and then attempts LDAP if the user exists. However, it consistently >>> returns an error for LDAP, and the account is never locked even after >>> exceeding the maximum number of login attempts. >>> >> >> So, just lock all matching accounts. >> > > One more scenario I just thought of with 'Auto Create User'. Suppose > that [email protected] exists as an internal user in the database, but there is > no corresponding LDAP entry. When the user attempts to log in with an > incorrect password, the system checks the database for entries from other > authentication sources and throws an error. In this case, the 'Auto Create > User' functionality will not be triggered. > > I think we can either keep the current behavior as it is and close the > issue (since I reported it), or add a rule with documentation saying that > login should follow the order of the authentication sources. In most cases, > users who prefer LDAP can just set the auth source to ['ldap', 'internal'], > which should work fine. > Right, I believe that would be the typical case. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 10:33 ` Re: Regarding #8580 Khushboo Vashi <[email protected]> 2025-05-09 10:49 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 11:13 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 11:20 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 11:48 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 13:01 ` Re: Regarding #8580 Dave Page <[email protected]> @ 2025-05-12 07:07 ` Akshay Joshi <[email protected]> 2025-05-13 11:08 ` Re: Regarding #8580 Dave Page <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Akshay Joshi @ 2025-05-12 07:07 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; pgadmin-hackers Hi Dave/Hackers, We found another scenario during testing. I know these cases can be tricky, but they’re valid. For example, if the auth sources are set to ['ldap', 'internal'] and there's both an LDAP and internal user with the same email (e.g., "[email protected]"). If the LDAP user tries to log in but forgets the password, the system first checks LDAP, then internal. Since the internal login also fails, the error shown is for the internal user, not LDAP. This can confuse users. To avoid this kind of confusion, it might be better to add a separate 'Login with LDAP' button on the login page (Please refer to the attached screenshot). This way, users can choose the right option directly. On Fri, May 9, 2025 at 6:31 PM Dave Page <[email protected]> wrote: > > > On Fri, 9 May 2025 at 12:48, Akshay Joshi <[email protected]> > wrote: > >> >> >> On Fri, May 9, 2025 at 4:50 PM Dave Page <[email protected]> wrote: >> >>> >>> >>> On Fri, 9 May 2025 at 12:14, Akshay Joshi <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, May 9, 2025 at 4:20 PM Dave Page <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, 9 May 2025 at 11:34, Khushboo Vashi < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Hackers/Dave, >>>>>>>> >>>>>>>> I have started working on issue #8580 >>>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the >>>>>>>> correct error message should be displayed based on the user's >>>>>>>> authentication source when an incorrect password is provided. >>>>>>>> >>>>>>>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = >>>>>>>> ['internal', 'ldap']. A user with the email [email protected] exists only >>>>>>>> as an internal user in the database, and there is no corresponding LDAP >>>>>>>> entry for this user. When this user attempts to log in with an incorrect >>>>>>>> password, the system first tries internal authentication, which fails. It >>>>>>>> then proceeds to check the next authentication source (LDAP), as per the >>>>>>>> configured logic. Since no matching LDAP user exists, an LDAP-related error >>>>>>>> is returned, even though the user is intended to be authenticated only >>>>>>>> internally. His/her account will never get locked. >>>>>>>> >>>>>>>> This behavior appears to be incorrect to me. I’m proposing two >>>>>>>> possible solutions to address it: >>>>>>>> *Solution 1 (Logic Changes): * >>>>>>>> *Scenario 1: ['internal', 'ldap']:* >>>>>>>> >>>>>>>> - If a user exists in the database with the specified >>>>>>>> authentication source (internal), attempt to authenticate using internal. >>>>>>>> If authentication fails, return an error. No need to check for the LDAP or >>>>>>>> next auth source. >>>>>>>> >>>>>>>> Yes. >>>>>>> >>>>>>>> >>>>>>>> - If no user-auth source combination is found for internal, >>>>>>>> proceed to the next authentication source (LDAP). Attempt LDAP login, and >>>>>>>> if successful (and auto-create is enabled), create the user in the database. >>>>>>>> >>>>>>>> Yes. >>>>>>> >>>>>>> >>>>>>>> *Scenario 2: ['ldap', 'internal']* >>>>>>>> >>>>>>>> - If the LDAP user does not exist in the database, but the >>>>>>>> same user exists as an internal user, first try LDAP authentication. If it >>>>>>>> fails, fall back to internal or the next configured auth source in the >>>>>>>> list. >>>>>>>> >>>>>>>> Yes. >>>>>>> >>>>>>>> >>>>>>>> - If the LDAP user does exist in the database, attempt to >>>>>>>> authenticate via LDAP. If LDAP authentication fails, return the error >>>>>>>> without checking for the next authentication source. >>>>>>>> >>>>>>>> Yes. >>>>>>> >>>>>> >>>>>> >>>>>> If the user is registered for multiple authentications (per entries >>>>>> in our database), the next in line should be checked if one fails.= >>>>>> >>>>> >>>>> I think that's reasonable, but *only* in that case where there's >>>>> another source already present in the DB. >>>>> >>>> >>>> In that case, the core issue remains unresolved. As mentioned >>>> earlier, the system checks internal authentication first (based on the >>>> configured order), and then attempts LDAP if the user exists. However, it >>>> consistently returns an error for LDAP, and the account is never locked >>>> even after exceeding the maximum number of login attempts. >>>> >>> >>> So, just lock all matching accounts. >>> >> >> One more scenario I just thought of with 'Auto Create User'. Suppose >> that [email protected] exists as an internal user in the database, but there is >> no corresponding LDAP entry. When the user attempts to log in with an >> incorrect password, the system checks the database for entries from other >> authentication sources and throws an error. In this case, the 'Auto Create >> User' functionality will not be triggered. >> >> I think we can either keep the current behavior as it is and close >> the issue (since I reported it), or add a rule with documentation saying >> that login should follow the order of the authentication sources. In most >> cases, users who prefer LDAP can just set the auth source to ['ldap', >> 'internal'], which should work fine. >> > > Right, I believe that would be the typical case. > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > pgEdge: https://www.pgedge.com > > Attachments: [image/png] Screenshot 2025-05-12 at 12.35.10 PM.png (48.7K, 3-Screenshot%202025-05-12%20at%2012.35.10%E2%80%AFPM.png) download | view image ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Regarding #8580 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 10:33 ` Re: Regarding #8580 Khushboo Vashi <[email protected]> 2025-05-09 10:49 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 11:13 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 11:20 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-09 11:48 ` Re: Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 13:01 ` Re: Regarding #8580 Dave Page <[email protected]> 2025-05-12 07:07 ` Re: Regarding #8580 Akshay Joshi <[email protected]> @ 2025-05-13 11:08 ` Dave Page <[email protected]> 0 siblings, 0 replies; 10+ messages in thread From: Dave Page @ 2025-05-13 11:08 UTC (permalink / raw) To: Akshay Joshi <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; pgadmin-hackers Hi On Mon, 12 May 2025 at 03:07, Akshay Joshi <[email protected]> wrote: > Hi Dave/Hackers, > > We found another scenario during testing. I know these cases can be > tricky, but they’re valid. For example, if the auth sources are set to ['ldap', > 'internal'] and there's both an LDAP and internal user with the same > email (e.g., "[email protected]"). > > If the LDAP user tries to log in but forgets the password, the system > first checks LDAP, then internal. Since the internal login also fails, the > error shown is for the internal user, not LDAP. This can confuse users. > I'm not sure how it would confuse users; "Incorrect username or password" applies in both cases - and we shouldn't be exposing information about which authentication methods were attempted and subsequently failed anyway, as that leaks information that could be useful to an attacker. > To avoid this kind of confusion, it might be better to add a separate > 'Login with LDAP' button on the login page (Please refer to the attached > screenshot). This way, users can choose the right option directly. > > On Fri, May 9, 2025 at 6:31 PM Dave Page <[email protected]> wrote: > >> >> >> On Fri, 9 May 2025 at 12:48, Akshay Joshi <[email protected]> >> wrote: >> >>> >>> >>> On Fri, May 9, 2025 at 4:50 PM Dave Page <[email protected]> wrote: >>> >>>> >>>> >>>> On Fri, 9 May 2025 at 12:14, Akshay Joshi < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, May 9, 2025 at 4:20 PM Dave Page <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 9 May 2025 at 11:34, Khushboo Vashi < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, May 9, 2025 at 3:23 PM Dave Page <[email protected]> wrote: >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> On Fri, 9 May 2025 at 08:45, Akshay Joshi < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Hackers/Dave, >>>>>>>>> >>>>>>>>> I have started working on issue #8580 >>>>>>>>> <https://github.com/pgadmin-org/pgadmin4/issues/8580;, where the >>>>>>>>> correct error message should be displayed based on the user's >>>>>>>>> authentication source when an incorrect password is provided. >>>>>>>>> >>>>>>>>> *Actual Issue*: The admin has configured AUTHENTICATION_SOURCES = >>>>>>>>> ['internal', 'ldap']. A user with the email [email protected] exists only >>>>>>>>> as an internal user in the database, and there is no corresponding LDAP >>>>>>>>> entry for this user. When this user attempts to log in with an incorrect >>>>>>>>> password, the system first tries internal authentication, which fails. It >>>>>>>>> then proceeds to check the next authentication source (LDAP), as per the >>>>>>>>> configured logic. Since no matching LDAP user exists, an LDAP-related error >>>>>>>>> is returned, even though the user is intended to be authenticated only >>>>>>>>> internally. His/her account will never get locked. >>>>>>>>> >>>>>>>>> This behavior appears to be incorrect to me. I’m proposing two >>>>>>>>> possible solutions to address it: >>>>>>>>> *Solution 1 (Logic Changes): * >>>>>>>>> *Scenario 1: ['internal', 'ldap']:* >>>>>>>>> >>>>>>>>> - If a user exists in the database with the specified >>>>>>>>> authentication source (internal), attempt to authenticate using internal. >>>>>>>>> If authentication fails, return an error. No need to check for the LDAP or >>>>>>>>> next auth source. >>>>>>>>> >>>>>>>>> Yes. >>>>>>>> >>>>>>>>> >>>>>>>>> - If no user-auth source combination is found for internal, >>>>>>>>> proceed to the next authentication source (LDAP). Attempt LDAP login, and >>>>>>>>> if successful (and auto-create is enabled), create the user in the database. >>>>>>>>> >>>>>>>>> Yes. >>>>>>>> >>>>>>>> >>>>>>>>> *Scenario 2: ['ldap', 'internal']* >>>>>>>>> >>>>>>>>> - If the LDAP user does not exist in the database, but the >>>>>>>>> same user exists as an internal user, first try LDAP authentication. If it >>>>>>>>> fails, fall back to internal or the next configured auth source in the >>>>>>>>> list. >>>>>>>>> >>>>>>>>> Yes. >>>>>>>> >>>>>>>>> >>>>>>>>> - If the LDAP user does exist in the database, attempt to >>>>>>>>> authenticate via LDAP. If LDAP authentication fails, return the error >>>>>>>>> without checking for the next authentication source. >>>>>>>>> >>>>>>>>> Yes. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> If the user is registered for multiple authentications (per entries >>>>>>> in our database), the next in line should be checked if one fails.= >>>>>>> >>>>>> >>>>>> I think that's reasonable, but *only* in that case where there's >>>>>> another source already present in the DB. >>>>>> >>>>> >>>>> In that case, the core issue remains unresolved. As mentioned >>>>> earlier, the system checks internal authentication first (based on the >>>>> configured order), and then attempts LDAP if the user exists. However, it >>>>> consistently returns an error for LDAP, and the account is never locked >>>>> even after exceeding the maximum number of login attempts. >>>>> >>>> >>>> So, just lock all matching accounts. >>>> >>> >>> One more scenario I just thought of with 'Auto Create User'. Suppose >>> that [email protected] exists as an internal user in the database, but there is >>> no corresponding LDAP entry. When the user attempts to log in with an >>> incorrect password, the system checks the database for entries from other >>> authentication sources and throws an error. In this case, the 'Auto Create >>> User' functionality will not be triggered. >>> >>> I think we can either keep the current behavior as it is and close >>> the issue (since I reported it), or add a rule with documentation saying >>> that login should follow the order of the authentication sources. In most >>> cases, users who prefer LDAP can just set the auth source to ['ldap', >>> 'internal'], which should work fine. >>> >> >> Right, I believe that would be the typical case. >> >> -- >> Dave Page >> pgAdmin: https://www.pgadmin.org >> PostgreSQL: https://www.postgresql.org >> pgEdge: https://www.pgedge.com >> >> -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com ^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2025-05-13 11:08 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-05-09 07:45 Regarding #8580 Akshay Joshi <[email protected]> 2025-05-09 09:53 ` Dave Page <[email protected]> 2025-05-09 10:33 ` Khushboo Vashi <[email protected]> 2025-05-09 10:49 ` Dave Page <[email protected]> 2025-05-09 11:13 ` Akshay Joshi <[email protected]> 2025-05-09 11:20 ` Dave Page <[email protected]> 2025-05-09 11:48 ` Akshay Joshi <[email protected]> 2025-05-09 13:01 ` Dave Page <[email protected]> 2025-05-12 07:07 ` Akshay Joshi <[email protected]> 2025-05-13 11:08 ` Dave Page <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox