Re: Bug #6337 Patch

From: Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
To: Florian Sabonchi <sabonchi(at)posteo(dot)de>, Dave Page <dave(dot)page(at)enterprisedb(dot)com>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Bug #6337 Patch
Date: 2021-07-19 12:22:36
Message-ID: CANxoLDeWN4e_oV3--qg-ypDWgqUeGeuUVu=rYhUXgG1rbqAV4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi Florian

Following are the review comments:

- The "MAX_LOGIN_ATTEMPTS" parameter is not present in the *config.py*.
It should be there with some default value maybe 3.
- Can be added like

##########################################################################
# MAX_LOGIN_ATTEMPTS which sets the number of failed login attempts that
# are allowed. If this value is exceeded the account is locked and can be
# reset by an administrator. By setting the variable to the value zero
# this feature is deactivated.
##########################################################################
MAX_LOGIN_ATTEMPTS = 3

- I have tested by specifying the above value, and it seems the logic is
not correct. I can perform N number of unsuccessful attempts and when I
provided the correct password it shows the flash message "Account locked".
- Once the account is locked, the pgAdmin4 server needs to restart, can
we make it time-bound? I mean after N minutes user can try again, so no
need to restart the pgAdmin4 server.

On Wed, Jul 14, 2021 at 9:29 PM Florian Sabonchi <sabonchi(at)posteo(dot)de> wrote:

> Hi I have a patch for bug #6337, in this patch you have the possibility
> to set in the configuration file the value MAX_LOGIN_ATTEMPTS which sets
> the number of failed login attempts that are allowed. If this value is
> exceeded the account is locked and can be reset by an administrator. By
> setting the variable to the value zero this feature is deactivated this
> is necessary if the account of the administrator was locked.
>
> Comment:
>
> Unfortunately the test cases fail because there seems to be a bug with
> the migration, but unfortunately I was not able to locate this bug.
>
> Unfortunately, in my opinion, the documentation does not sufficiently
> explain how to correctly create the migrations.
>
> I would be very happy if you could expand the documentation in the
> future what this concerns and create a detailed guide to create a
> migration. (This also concerns the instructions for the integration test)
>
> With kind regards,
>
> Florian Sabonchi
>
>

--
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres <http://edbpostgres.com>*

*Mobile: +91 976-788-8246*

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2021-07-19 12:53:02 Re: Bug #6337 Patch
Previous Message Dave Page 2021-07-19 09:43:51 Re: SQLAlchemy updates for check tables.