public inbox for [email protected]  

help / color / mirror / Atom feed

From: Rahul Shirsat <[email protected]>
To: Dave Page <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: Bug #6337
Date: Tue, 6 Jul 2021 13:59:17 +0530
Message-ID: <CAKtn9dPAh4O9VkzXUnRBHB_9umbiKMR1gHxXHN_ozDiKCgrhzg@mail.gmail.com> (raw)
In-Reply-To: <CA+OCxowU7uPHBRt1RPZUXM-SS88YtRnScfri8P1DbnrvJ4OKmw@mail.gmail.com>
References: <[email protected]>
	<CA+OCxowU7uPHBRt1RPZUXM-SS88YtRnScfri8P1DbnrvJ4OKmw@mail.gmail.com>

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

view thread (5+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Bug #6337
  In-Reply-To: <CAKtn9dPAh4O9VkzXUnRBHB_9umbiKMR1gHxXHN_ozDiKCgrhzg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox