Re: [pgAdmin][RM6448]: [search object] error displayed for non superuser because of right on pg_catalog.pg_subscription

[Pradip Parkale]

Hi Akshay,
Please find the updated patch.I have added a more reliable solution to
solve this issue.

On Wed, Jun 23, 2021 at 12:52 PM Akshay Joshi 
wrote:

> Thanks, the patch applied.
>
> On Tue, Jun 22, 2021 at 4:17 PM Pradip Parkale <
> pradip.park...@enterprisedb.com> wrote:
>
>> Hi Hackers,
>> Please ignore my previous email and find the attached patch. I have fixed
>> some review comments given by Aditya.
>>
>> On Tue, Jun 22, 2021 at 2:21 PM Fred  wrote:
>>
>>> nice !
>>> thanks
>>>
>>> fred
>>>
>>>
>>> Le 22 juin 2021 09:08:05 GMT+02:00, Pradip Parkale <
>>> pradip.park...@enterprisedb.com> a écrit :

 Hi Hackers,

 Please find the attached patch for # 6448. I have added a check to
 ignore the subscription when the search type is 'All type' if the user
 doesn't have access to subscription.

 --
 Thanks & Regards,
 Pradip Parkale
 Software Engineer | EnterpriseDB Corporation

>>>
>>
>> --
>> Thanks & Regards,
>> Pradip Parkale
>> Software Engineer | EnterpriseDB Corporation
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
> *pgAdmin Hacker | Principal Software Architect*
> *EDB Postgres *
>
> *Mobile: +91 976-788-8246*
>


-- 
Thanks & Regards,
Pradip Parkale
Software Engineer | EnterpriseDB Corporation


RM6448_v2.patch
Description: Binary data

pgAdmin 4 commit: Fixed an issue in the search object when searching in

[Akshay Joshi]

Fixed an issue in the search object when searching in 'all types' or 
'subscription' if the user doesn't have access to the subscription. Fixes #6448

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=b2205fc6e178638dff9062e9b6c469c207b5e688
Author: Pradip Parkale 

Modified Files
--
docs/en_US/release_notes_5_6.rst  | 1 +
web/pgadmin/tools/search_objects/utils.py | 8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)

pgAdmin 4 commit: Added exception handling for SQLAlchemy function to c

[Akshay Joshi]

Added exception handling for SQLAlchemy function to check the table exists or 
not.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=5768ade198bda653c7b20fc15574b8c8a8e6aceb
Author: Nikhil Mohite 

Modified Files
--
.../browser/tests/test_set_session_expiration_time.py|  4 ++--
web/pgadmin/setup/db_table_check.py  | 12 
2 files changed, 10 insertions(+), 6 deletions(-)

Re: [pgAdmin][RM6448]: [search object] error displayed for non superuser because of right on pg_catalog.pg_subscription

[Akshay Joshi]

Thanks, the patch applied.

On Mon, Jul 19, 2021 at 1:49 PM Pradip Parkale <
pradip.park...@enterprisedb.com> wrote:

> Hi Akshay,
> Please find the updated patch.I have added a more reliable solution to
> solve this issue.
>
> On Wed, Jun 23, 2021 at 12:52 PM Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Thanks, the patch applied.
>>
>> On Tue, Jun 22, 2021 at 4:17 PM Pradip Parkale <
>> pradip.park...@enterprisedb.com> wrote:
>>
>>> Hi Hackers,
>>> Please ignore my previous email and find the attached patch. I have
>>> fixed some review comments given by Aditya.
>>>
>>> On Tue, Jun 22, 2021 at 2:21 PM Fred  wrote:
>>>
 nice !
 thanks

 fred


 Le 22 juin 2021 09:08:05 GMT+02:00, Pradip Parkale <
 pradip.park...@enterprisedb.com> a écrit :
>
> Hi Hackers,
>
> Please find the attached patch for # 6448. I have added a check to
> ignore the subscription when the search type is 'All type' if the user
> doesn't have access to subscription.
>
> --
> Thanks & Regards,
> Pradip Parkale
> Software Engineer | EnterpriseDB Corporation
>

>>>
>>> --
>>> Thanks & Regards,
>>> Pradip Parkale
>>> Software Engineer | EnterpriseDB Corporation
>>>
>>
>>
>> --
>> *Thanks & Regards*
>> *Akshay Joshi*
>> *pgAdmin Hacker | Principal Software Architect*
>> *EDB Postgres *
>>
>> *Mobile: +91 976-788-8246*
>>
>
>
> --
> Thanks & Regards,
> Pradip Parkale
> Software Engineer | EnterpriseDB Corporation
>


-- 
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres *

*Mobile: +91 976-788-8246*

Re: SQLAlchemy updates for check tables.

[Akshay Joshi]

Thanks, the patch applied.

On Mon, Jul 19, 2021 at 11:45 AM Nikhil Mohite <
nikhil.moh...@enterprisedb.com> wrote:

> Hi Akshay,
>
> PFA updated the patch to make it work with an older version of SQLAlchemy.
>
> On Mon, Jul 19, 2021 at 11:36 AM Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Hi Nikhil
>>
>> On Mon, Jul 19, 2021 at 11:07 AM Nikhil Mohite <
>> nikhil.moh...@enterprisedb.com> wrote:
>>
>>> Hi Hackers,
>>>
>>> Please find the attached patch for SQLAlchemy updates for check table is
>>> present in the database or not. (This will resolve load and dump server.)
>>>
>>
>> I am assuming the changes should work with the old version of
>> SQLAlchemy. If not please fix and resend the patch
>>
>>>
>>> --
>>> *Thanks & Regards,*
>>> *Nikhil Mohite*
>>> *Software Engineer.*
>>> *EDB Postgres* 
>>> *Mob.No: +91-7798364578.*
>>>
>>
>>
>> --
>> *Thanks & Regards*
>> *Akshay Joshi*
>> *pgAdmin Hacker | Principal Software Architect*
>> *EDB Postgres *
>>
>> *Mobile: +91 976-788-8246*
>>
>
> Regards,
> Nikhil Mohite
>


-- 
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres *

*Mobile: +91 976-788-8246*

Re: SQLAlchemy updates for check tables.

[Dave Page]

Hi

On Mon, Jul 19, 2021 at 6:37 AM Nikhil Mohite <
nikhil.moh...@enterprisedb.com> wrote:

> Hi Hackers,
>
> Please find the attached patch for SQLAlchemy updates for check table is
> present in the database or not. (This will resolve load and dump server.)
>

How come this upstream change didn't fail the regression tests?

-- 
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

Re: SQLAlchemy updates for check tables.

[Khushboo Vashi]

On Mon, Jul 19, 2021 at 2:17 PM Dave Page  wrote:

> Hi
>
> On Mon, Jul 19, 2021 at 6:37 AM Nikhil Mohite <
> nikhil.moh...@enterprisedb.com> wrote:
>
>> Hi Hackers,
>>
>> Please find the attached patch for SQLAlchemy updates for check table is
>> present in the database or not. (This will resolve load and dump server.)
>>
>
> How come this upstream change didn't fail the regression tests?
>
Flask-SQLAlchemy is dependent on SQLAlchemy and which is an indirect
dependency of pgAdmin, so if the installed version of Flask-SQLAlchemy is
the latest one, it will be skipped.

>
>
-- 
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>

Re: SQLAlchemy updates for check tables.

[Dave Page]

On Mon, Jul 19, 2021 at 9:58 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Mon, Jul 19, 2021 at 2:17 PM Dave Page  wrote:
>
>> Hi
>>
>> On Mon, Jul 19, 2021 at 6:37 AM Nikhil Mohite <
>> nikhil.moh...@enterprisedb.com> wrote:
>>
>>> Hi Hackers,
>>>
>>> Please find the attached patch for SQLAlchemy updates for check table is
>>> present in the database or not. (This will resolve load and dump server.)
>>>
>>
>> How come this upstream change didn't fail the regression tests?
>>
> Flask-SQLAlchemy is dependent on SQLAlchemy and which is an indirect
> dependency of pgAdmin, so if the installed version of Flask-SQLAlchemy is
> the latest one, it will be skipped.
>

Sure, but the regression test runs on the buildfarm build the venv from
scratch on every run (as happens when we build the packages themselves). So
I can see why local regression runs might have passed (as developers
generally don't recreate their venv's from scratch before testing), but I
would expect to have seen failures on the buildfarm.

-- 
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

Re: Bug #6337 Patch

[Akshay Joshi]

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  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 *

*Mobile: +91 976-788-8246*

Re: Bug #6337 Patch

[Dave Page]

Hi

On Mon, Jul 19, 2021 at 1:22 PM Akshay Joshi 
wrote:

> 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.
>
> Isn't the point that any admin can unlock the account from the user
management dialog?


-- 
Dave Page
VP, Chief Architect, Database Infrastructure
Blog: https://www.enterprisedb.com/dave-page
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

Re: Bug #6337 Patch

[Akshay Joshi]

On Mon, Jul 19, 2021 at 6:23 PM Dave Page 
wrote:

> Hi
>
> On Mon, Jul 19, 2021 at 1:22 PM Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> 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.
>>
>> Isn't the point that any admin can unlock the account from the user
> management dialog?
>

Yes, I missed that part, it is working fine from the user management
dialog.

>
>
> --
> Dave Page
> VP, Chief Architect, Database Infrastructure
> Blog: https://www.enterprisedb.com/dave-page
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>


-- 
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres *

*Mobile: +91 976-788-8246*