Dave, Testing Environment
Ubuntu 16.04 Linux 64: -------------------------------- pg-AdminIV Development Environment Setup for Ubuntu : 1) Install GIT sudo apt-get install git 2) Install pip3 sudo apt-get install python3-pip 3) Install virtualenv sudo pip3 install virtualenv 4) install below dependency as it is required for psycopg2 & pycrypto module sudo apt-get install libpq-dev sudo apt-get install python3-dev 5) Create virtual environment virtualenv -p python3 venv 6) Create mkdir Projects 7) Clone git repo in Projects git clone http://git.postgresql.org/git/pgadmin4.git 8) activate virtual environment source venv/bin/activate 9) Install modules pip3 install -r requirements_py3.txt *10) Edit the config.py file to config_local.py resides in Projects\pgAdmin4\web * 11)Now run setup.py file (\Projects\pgAdmin4\web) python setup.py If user does not create config_local.py and do Python setup.py for new Development then SECURITY_PASSWORD_SALT message is also displayed: Here is the output: ------------------------- python setup.py pgAdmin 4 - Application Initialisation ====================================== The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does not exist. Entering initial setup mode... NOTE: Configuring authentication for SERVER mode. Enter the email address and password to use for the initial pgAdmin user account: Email address: fahar.ab...@enterprisedb.com Password: Retype password: Traceback (most recent call last): File "setup.py", line 449, in <module> do_setup(app) File "setup.py", line 96, in do_setup password = encrypt_password(p1) File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", line 150, in encrypt_password signed = get_hmac(password).decode('ascii') File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", line 108, in get_hmac 'set to "%s"' % _security.password_hash) RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must not be None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512" (venv) fahar@fahar-virtual-machine:~/Projects/pgadmin4/web$ Is this expected? On Wed, Oct 19, 2016 at 1:37 PM, Fahar Abbas <fahar.ab...@enterprisedb.com> wrote: > Sure, > > Will test this thoroughly after complete investigation. > > Kind Regards, > > On Wed, Oct 19, 2016 at 1:27 PM, Dave Page <dp...@pgadmin.org> wrote: > >> Patch applied. >> >> Fahar, can you please test this thoroughly in desktop and server modes, >> with both fresh and upgraded installations? >> >> https://redmine.postgresql.org/issues/1849 >> >> Packagers: This change means that packages are no longer forced to create >> a config_local.py file, and there is no longer any need to explicitly set >> SECURITY_PASSWORD_SALT, SECURITY_KEY and CSRF_SESSION_KEY in the config >> (in fact, they should be removed for new installations, if you have >> included them in 1.0) >> >> Thanks. >> >> >> On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Vashi < >> ashesh.va...@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> On Sat, Oct 15, 2016 at 8:02 AM, Dave Page <dp...@pgadmin.org> wrote: >>> >>>> Hi >>>> >>>> >>>> On Friday, October 14, 2016, Dave Page <dp...@pgadmin.org> wrote: >>>> >>>>> 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> 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. >>>>> >>>> >>>> OK, so I've been thinking about this and experimenting for a couple of >>>> hours, as well as annoying the crap out of Magnus by thinking out loud in >>>> his general direction, and it looks like this isn't a major problem as from >>>> what I can see, SECURITY_PASSWORD_SALT is (aside from really being a key >>>> not a salt) not the only salting that's done. >>>> >>>> It looks like it's used system-wide as the key to generate an HMAC of >>>> the users password, which is then passed to passlib which salts and hashes >>>> it. I did some testing, and found that two users with the same password end >>>> up with different hashes in the database, so clearly there is also per-user >>>> salting happening. I also created two users, then dropped the database and >>>> created the same user accounts with the same passwords again, and found >>>> that the resulting hashes were different in both databases - thus there is >>>> something else ensuring the hashes are unique across different >>>> installations/databases. >>>> >>>> So, I believe we can do as you suggest and migrate existing values for >>>> SECURITY_PASSWORD_SALT, given that there's clearly some other per user and >>>> per installation/database salting going on anyway. New installations can >>>> have the random value for SECURITY_PASSWORD_SALT. >>>> >>> We do not need to generate the random SECURITY_PASSWORD_SALT during >>> upgrade mode, which was wrong added in my addon patch. >>> >>> Please find the updated patch. >>> >>> Otherwise - looks good to me. >>> Please commit the new patch (if you're ok with the change). >>> >>> >>> -- >>> >>> Thanks & Regards, >>> >>> Ashesh Vashi >>> EnterpriseDB INDIA: Enterprise PostgreSQL Company >>> <http://www.enterprisedb.com/> >>> >>> >>> *http://www.linkedin.com/in/asheshvashi* >>> <http://www.linkedin.com/in/asheshvashi> >>> >>>> >>>> I don't believe SECURITY_KEY and CSRF_SESSION_KEY are issues either, as >>>> they're used for purposes that are essentially ephemeral, and thus can be >>>> changed during an upgrade. >>>> >>>> Adding Magnus as I'd appreciate any thoughts he may have. >>>> >>>> Patch attached - please review (Ashesh, but others too would be >>>> appreciated)! >>>> >>>> Thanks. >>>> >>>> >>>> -- >>>> Dave Page >>>> Blog: http://pgsnake.blogspot.com >>>> Twitter: @pgsnake >>>> >>>> EnterpriseDB UK: http://www.enterprisedb.com >>>> The Enterprise PostgreSQL Company >>>> >>>> >>> >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > > > -- > Syed Fahar Abbas > Quality Management Group > > EnterpriseDB Corporation > Phone Office: +92-51-835-8874 > Phone Direct: +92-51-8466803 > Mobile: +92-333-5409707 > Skype ID: syed.fahar.abbas > Website: www.enterprisedb.com > -- Syed Fahar Abbas Quality Management Group EnterpriseDB Corporation Phone Office: +92-51-835-8874 Phone Direct: +92-51-8466803 Mobile: +92-333-5409707 Skype ID: syed.fahar.abbas Website: www.enterprisedb.com
