Regarding RM #2214 SCRAM Authentication for Change Password

[Akshay Joshi]

Hi Hackers,

As a part of RM #2214, we will have to support SCRAM authentication. User
will be able to login, but the problem is with "Change Password" of
database server won't work, as we are encrypting new password using md5 and
set the new password using "*ALTER USER  WITH ENCRYPTED PASSWORD
*" query.

If password_encryption = scram-sha-256 in postgresql.conf file then it will
change the password with md5 encryption which is not correct and user won't
be able to login using changed password. I have  tried previously (almost
12 months ago) and tried following again

from passlib.hash import scram

scram.default_rounds = 4096
digest_info = scram.extract_digest_info(scram.encrypt(password), 'sha-256')

salt = digest_info[0]
rounds = digest_info[1]
secret = digest_info[2]

salted_password = hashlib.pbkdf2_hmac('sha256', secret, salt, rounds)

but not able to encrypt the password for SCRAM.

There is new method introduce in PostgreSQL 10 to encrypt the password:

char *PQencryptPasswordConn(PGconn *conn, const char *passwd, const
char *user, const char *algorithm);

As we are using psycopg2, so the support for the above method should be
available in psycopg2. *Ashesh* *Vashi* has already send the patch to
support for preparing encrypted password and they are planning to merge his
patch in version 2.8. Following is the link of his patch
https://github.com/psycopg/psycopg2/pull/576

So when the above patch will be merged and released by psycopg2, we will
work on this feature again and modified the code. I'll update the RM
accordingly.

Suggestion/ Comments?

-- 
*Akshay Joshi*

*Sr. Software Architect *



*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

Re: [pgAdmin4][RM#3155] Allow user to lock the Layout

[Joao De Almeida Pereira]

Hello,

On Mon, Apr 2, 2018 at 10:07 AM Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

>
> ​Hello,
>
> Please find updated patch,
>
> Now layout will be locked after user updates its preferences, w
> e have used ​
> templated variable in the javascript file
> ​ because we do not have preference module or preference cache available
> when the page loads and panels gets rendered,
> ​I
> ​ also
> made changes in JS tests as per Joao's review comments.
>
Looks like everything is working when we change the lock.
As a personal preferences I would prefer to see this in at least 2 commits,
one that is related to the preference issue and another one that is related
to this story.


All the tests are working, but he linter is failing:

/tmp/build/4a5630c2/pivotal-rm-3155/web /tmp/build/4a5630c2
 

./pgadmin/misc/__init__.py:78: [E303] too many blank lines (2)
 

1   E303 too many blank lines (2)
 


1


> @Dave/Pivotal team,
> The given patch is working fine for all the Tabs/Panels (all the panels
> from main window as well as from Query tool and Debugger) but I'm facing an
> issue while handling the Browser tree section, It is a wcDocer frame
>  and not a wcDocker
> panel . Like wcDocker
> panel, wcDocker frame do not provide any API so that a developer can
> prevent drag-drop functionality on it.
>
> By visiting wcDocker github page  It
> looks like it not actively maintained.
> What do you suggest how should we tackle this issue?
>
>
I think this should be moved to a different thread, because at this point
in time we have 3 of our core libraries that are no longer
maintained/supported/under active development that I know out of my head.
(ACITree, Backbone and wcDocker). I might even add to the mix jquery 1.11.2
because it stopped being actively developed and supported after May 20 of
2016.


> For time being, I've created subtask for this issue
> https://redmine.postgresql.org/issues/3243
>
> Thanks,
> Murtuza
>  ​
> On Thu, Mar 29, 2018 at 8:57 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hi Murtuza,
>>
>> After changing the setting in the preferences nothing happened, we had to
>> reset the layout or refresh the app to see it working. It only looks the
>> right side. Was this the intended behavior?
>>
>> Not sure if this is the expected behavior or not. I would expect that any
>> change I do in the preferences would start working after I press the Save
>> button. This also happens with other preferences that only take effect
>> after refresh on the browser.
>> This being said, not sure if having the templated variable in the
>> javascript file is the best approach in this case.
>>
>> Do you think you can remove the requirejs tags on the tests?
>>
>> At the testing file you do not need to create 3 different variables for
>> the panels, you can reuse it, because the beforeEach will run for every test
>>
>> Thanks
>> Joao
>>
>> On Thu, Mar 29, 2018 at 9:48 AM Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Thu, Mar 29, 2018 at 2:15 PM, Murtuza Zabuawala <
>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>
 Hi,

 PFA patch which will allow user to lock the panels and it will not
 allow user to drag & drop them.

>>>
>>> Tests pass, but when I lock the layout, I can still drag panels and
>>> adjust the splitters etc. After doing so,  reset the layout and now have
>>> the broken layout seen in the attached screenshot. I have rebuilt the
>>> bundle, reloaded etc.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>

[pgadmin4][patch] #3244 Query elapse time granularity

[Joao De Almeida Pereira]

Hi Hackers,

Attached you can find a patch that increases the granularity of time
displayed for total run time of a query.
Also extracts the functionality, wraps it with tests.
An addon to this patch is the extraction of the function
call_render_after_poll  that uses the function that calculates the time as
well


Thanks
Joao


granularity-of-query-elapse-time.diff
Description: Binary data

Re: [pgadmin4][patch] #3244 Query elapse time granularity

[Robert Eckhardt]

On Mon, Apr 2, 2018 at 6:24 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hi Hackers,
>
> Attached you can find a patch that increases the granularity of time
> displayed for total run time of a query.
> Also extracts the functionality, wraps it with tests.
> An addon to this patch is the extraction of the function
> call_render_after_poll  that uses the function that calculates the time as
> well
>
>
This was an issue pointed out in an email I can't find. Basically it
pointed out something we thought we had done in the first place.

-- Rob


> Thanks
> Joao
>