Hi On Thursday, October 13, 2016, Ashesh Vashi <ashesh.va...@enterprisedb.com> wrote:
> 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. > Hmm. > > 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
