public inbox for [email protected]help / color / mirror / Atom feed
Bug #6337 5+ messages / 3 participants [nested] [flat]
* Bug #6337 @ 2021-05-26 11:31 Florian Sabonchi <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Florian Sabonchi @ 2021-05-26 11:31 UTC (permalink / raw) To: pgadmin-hackers Hello, Is someone already working on ticket #6337 or can I start working on it? https://redmine.postgresql.org/issues/6337 Regards, Florian Sabonchi ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Bug #6337 @ 2021-05-26 12:46 Dave Page <[email protected]> parent: Florian Sabonchi <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Dave Page @ 2021-05-26 12:46 UTC (permalink / raw) To: Florian Sabonchi <[email protected]>; +Cc: pgadmin-hackers Hi On Wed, May 26, 2021 at 1:40 PM Florian Sabonchi <[email protected]> wrote: > Hello, > > Is someone already working on ticket #6337 or can I start working on it? > > https://redmine.postgresql.org/issues/6337 Not as far as I know. Please feel free to work on it. Do you have a design in mind? I would suggest maybe adding a "login_attempts" column to the user table in the config database, and having a parameter in config.py to define the maximum number of login attempts allowed. login_attempts would be incremented for every failed login, and set to zero for a successful one. If it's value is >= to the maximum in the config, login would be denied. There would also need to be changes to the user management dialogue to show the status for each user, and reset them. Thanks! -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Bug #6337 @ 2021-07-06 08:29 Rahul Shirsat <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Rahul Shirsat @ 2021-07-06 08:29 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: pgadmin-hackers Hi Team, Thank you Dave for analysing & providing the requirement for this issue. Please find below scenarios which I have compiled. *For INTERNAL USERS*, they would be able to reset login attempts by: 1. *Resetting password via reset link* - User has to reset password by their own (this won't work for undeliverable email ids) 2. *Resetting only login attempts* - Admin will be able to reset only login attempts of a particular user, so that user would try again to login with the same password. 3. *Resetting login attempts with reset password* - Admin will reset password, and will share it with the user. Users would be able to login with this new password again. I feel the 1st & 3rd options are reliable and good to go. A still or wireframe for user management for Admin: [image: user_unlock_1.png] *For LDAP & KERBEROS:* As per my understanding, we don't provide reset passwords for LDAP & KERBEROS, so we can't lock those users, and let users be allowed to attempt login as we have it currently. Let me know if this works. -- *Rahul Shirsat* Senior Software Engineer | EnterpriseDB Corporation. On Wed, May 26, 2021 at 6:16 PM Dave Page <[email protected]> wrote: > Hi > > On Wed, May 26, 2021 at 1:40 PM Florian Sabonchi <[email protected]> > wrote: > >> Hello, >> >> Is someone already working on ticket #6337 or can I start working on it? >> >> https://redmine.postgresql.org/issues/6337 > > > Not as far as I know. Please feel free to work on it. > > Do you have a design in mind? I would suggest maybe adding a > "login_attempts" column to the user table in the config database, and > having a parameter in config.py to define the maximum number of login > attempts allowed. login_attempts would be incremented for every failed > login, and set to zero for a successful one. If it's value is >= to the > maximum in the config, login would be denied. There would also need to be > changes to the user management dialogue to show the status for each user, > and reset them. > > Thanks! > > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > -- *Rahul Shirsat* Senior Software Engineer | EnterpriseDB Corporation. Attachments: [image/png] user_unlock_1.png (186.9K, 3-user_unlock_1.png) download | view image ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Bug #6337 @ 2021-07-06 13:52 Dave Page <[email protected]> parent: Rahul Shirsat <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Dave Page @ 2021-07-06 13:52 UTC (permalink / raw) To: Rahul Shirsat <[email protected]>; +Cc: pgadmin-hackers; Florian Sabonchi <[email protected]> Hi I just realised part of this thread drifted off-list. Florian (CC'd) had been talking about working on it. Florian, are you planning to do so? On Tue, Jul 6, 2021 at 9:29 AM Rahul Shirsat <[email protected]> wrote: > Hi Team, > > Thank you Dave for analysing & providing the requirement for this issue. > Please find below scenarios which I have compiled. > > *For INTERNAL USERS*, they would be able to reset login attempts by: > > 1. *Resetting password via reset link* - User has to reset password by > their own (this won't work for undeliverable email ids) > > 2. *Resetting only login attempts* - Admin will be able to reset only > login attempts of a particular user, so that user would try again to login > with the same password. > > 3. *Resetting login attempts with reset password* - Admin will reset > password, and will share it with the user. Users would be able to login > with this new password again. > > I feel the 1st & 3rd options are reliable and good to go. > > A still or wireframe for user management for Admin: > > [image: user_unlock_1.png] > > *For LDAP & KERBEROS:* > > As per my understanding, we don't provide reset passwords for LDAP & > KERBEROS, so we can't lock those users, and let users be allowed to attempt > login as we have it currently. > > Let me know if this works. > > -- > *Rahul Shirsat* > Senior Software Engineer | EnterpriseDB Corporation. > > On Wed, May 26, 2021 at 6:16 PM Dave Page <[email protected]> wrote: > >> Hi >> >> On Wed, May 26, 2021 at 1:40 PM Florian Sabonchi <[email protected]> >> wrote: >> >>> Hello, >>> >>> Is someone already working on ticket #6337 or can I start working on it? >>> >>> https://redmine.postgresql.org/issues/6337 >> >> >> Not as far as I know. Please feel free to work on it. >> >> Do you have a design in mind? I would suggest maybe adding a >> "login_attempts" column to the user table in the config database, and >> having a parameter in config.py to define the maximum number of login >> attempts allowed. login_attempts would be incremented for every failed >> login, and set to zero for a successful one. If it's value is >= to the >> maximum in the config, login would be denied. There would also need to be >> changes to the user management dialogue to show the status for each user, >> and reset them. >> >> Thanks! >> >> -- >> Dave Page >> Blog: https://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EDB: https://www.enterprisedb.com >> >> > > -- > *Rahul Shirsat* > Senior Software Engineer | EnterpriseDB Corporation. > -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com Attachments: [image/png] user_unlock_1.png (186.9K, 3-user_unlock_1.png) download | view image ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Bug #6337 @ 2021-07-06 15:40 Dave Page <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Dave Page @ 2021-07-06 15:40 UTC (permalink / raw) To: Florian Sabonchi <[email protected]>; pgadmin-hackers [Please keep the list CC'd] That's great, thanks. I just wanted to make sure two people weren't working on this. I look forward to seeing your patch. On Tue, Jul 6, 2021 at 4:05 PM Florian Sabonchi <[email protected]> wrote: > Thank you for your message. I planned to work on it unfortunately I didn't > have time due to my exam period. I have already started the development and > can finish it. However, I can only start next week to complete the patch, > if this is too late please let someone else take a look at it. > On 06.07.21 15:52, Dave Page wrote: > > Hi > > I just realised part of this thread drifted off-list. Florian (CC'd) had > been talking about working on it. Florian, are you planning to do so? > > > On Tue, Jul 6, 2021 at 9:29 AM Rahul Shirsat < > [email protected]> wrote: > >> Hi Team, >> >> Thank you Dave for analysing & providing the requirement for this issue. >> Please find below scenarios which I have compiled. >> >> *For INTERNAL USERS*, they would be able to reset login attempts by: >> >> 1. *Resetting password via reset link* - User has to reset password by >> their own (this won't work for undeliverable email ids) >> >> 2. *Resetting only login attempts* - Admin will be able to reset only >> login attempts of a particular user, so that user would try again to login >> with the same password. >> >> 3. *Resetting login attempts with reset password* - Admin will reset >> password, and will share it with the user. Users would be able to login >> with this new password again. >> >> I feel the 1st & 3rd options are reliable and good to go. >> >> A still or wireframe for user management for Admin: >> >> [image: user_unlock_1.png] >> >> *For LDAP & KERBEROS:* >> >> As per my understanding, we don't provide reset passwords for LDAP & >> KERBEROS, so we can't lock those users, and let users be allowed to attempt >> login as we have it currently. >> >> Let me know if this works. >> >> -- >> *Rahul Shirsat* >> Senior Software Engineer | EnterpriseDB Corporation. >> >> On Wed, May 26, 2021 at 6:16 PM Dave Page <[email protected]> wrote: >> >>> Hi >>> >>> On Wed, May 26, 2021 at 1:40 PM Florian Sabonchi <[email protected]> >>> wrote: >>> >>>> Hello, >>>> >>>> Is someone already working on ticket #6337 or can I start working on it? >>>> >>>> https://redmine.postgresql.org/issues/6337 >>> >>> >>> Not as far as I know. Please feel free to work on it. >>> >>> Do you have a design in mind? I would suggest maybe adding a >>> "login_attempts" column to the user table in the config database, and >>> having a parameter in config.py to define the maximum number of login >>> attempts allowed. login_attempts would be incremented for every failed >>> login, and set to zero for a successful one. If it's value is >= to the >>> maximum in the config, login would be denied. There would also need to be >>> changes to the user management dialogue to show the status for each user, >>> and reset them. >>> >>> Thanks! >>> >>> -- >>> Dave Page >>> Blog: https://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EDB: https://www.enterprisedb.com >>> >>> >> >> -- >> *Rahul Shirsat* >> Senior Software Engineer | EnterpriseDB Corporation. >> > > > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com Attachments: [image/png] user_unlock_1.png (186.9K, 3-user_unlock_1.png) download | view image ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2021-07-06 15:40 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-05-26 11:31 Bug #6337 Florian Sabonchi <[email protected]> 2021-05-26 12:46 ` Dave Page <[email protected]> 2021-07-06 08:29 ` Rahul Shirsat <[email protected]> 2021-07-06 13:52 ` Dave Page <[email protected]> 2021-07-06 15:40 ` 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