Re: Bug #6337

[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 <sabonchi(at)posteo(dot)de> 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 <
> rahul(dot)shirsat(at)enterprisedb(dot)com> 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 <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>> On Wed, May 26, 2021 at 1:40 PM Florian Sabonchi <sabonchi(at)posteo(dot)de>
>>> 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