On Thursday, October 13, 2016, Ashesh Vashi <ashesh.va...@enterprisedb.com>

> Hi Dave,
> On Tue, Oct 11, 2016 at 9:10 PM, Dave Page <dp...@pgadmin.org
> <javascript:_e(%7B%7D,'cvml','dp...@pgadmin.org');>> wrote:
>> Hi Ashesh,
>> Can you please review the attached patch, and apply if you're happy with
>> it?
> Overall the patch looked good to me.
> But - I encounter an issue in 'web' mode, which wont happen with 'runtime'.
> Steps for reproduction on existing pgAdmin 4 environment with 'web' mode.
> - Apply the patch
> - Start the pgAdmin4 application (stand alone application).
> - Open pgAdmin home page.
> - Log out (if already login).
> And, you will see an exception.
> I have figure out the issue with the patch.
> We were setting the SECURITY_PASSWORD_SALT, after initializing the
> Security object.
> Hence - it could not set the SECURITY_KEY, and SECURITY_PASSWORD_SALT
> properly.


> I had moved the Security object initialization after fetching these
> configurations from the database.
> I have attached a addon patch for the same.

OK, thanks.

> Now - I run into another issue.
> Because - the existing password was hashed using the old
> SECURITY_PASSWORD_SALT, I am no more able to login to pgAdmin 4.
> I think - we need to think about different strategy for upgrading the
> configuration file in the 'web' mode.
> I was thinking - we can store the existing security configurations in the
> database during upgrade process in 'web' mode.

My concern with that is that we'll likely be storing the default config
values in many cases, thus for those users, perpetuating the problem.

I guess what we need to do is re-encrypt the password during the upgrade -
however, that makes me think; we then have both the key and the encrypted
passwords in the same database which is clearly not a good idea. Sigh...
Needs more thought.

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Reply via email to