Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx7uk-0002nY-Ha for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 07:37:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bx7uk-0000qR-4D for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 07:37:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bx7uR-0000Gm-V4 for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 07:37:04 +0000 Received: from mail-it0-x22e.google.com ([2607:f8b0:4001:c0b::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bx7uM-0000O0-Rb for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 07:37:03 +0000 Received: by mail-it0-x22e.google.com with SMTP id 66so75079523itl.1 for ; Thu, 20 Oct 2016 00:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GdGZNdXV3xs53pYn5nwIN0j/NSJMnAemT7m1KsDTqUo=; b=LVSqpqU5aHo4DSnfOL5uxTMM3C0I+FAgjuj4jAxC3VzQqqkJJJyGFZNIT+BMw39xLI 636WPGzFPRSKSB6Hk8d4ZKTicy7ezMIKc4YWkW0OTotxqjA1t/RnkrdIpLjEa/HvTtiH qGmDEu7+xPkE0ywd3haB7/AQsDzz1t310yZ/21naU2gMZQ5H0tP8igYbe2H/klz07DIw HEEIQrcFtubowTxhrv9oYKslqHf5NgYPrMUm7yt/aSi0gdvTsB9iwdCB3FykMVCrhrf8 8zYs/9L9EFDZdRU7oHDb1kBr9it0iTUTG3o/XEhOKxRtRd1oGux97y5J8j/Jii1CXncA C7jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GdGZNdXV3xs53pYn5nwIN0j/NSJMnAemT7m1KsDTqUo=; b=mpzqTpcRn2ivG2319uxs+DEft87P7ZqS0t2x1zwEr4ejscLMYVAcR0/vCKY9qynfut H+dG9c6AP8KD00vtp1OoGsiKRmQTttE5v5Ic407cr39z5Y26O8YSDF6MrSjN1UubXINz r2EFcHhujtteB49RJOm9hSFuFhQkpHpqhn1q7Az/owFibE23y8fhZrndeguPFv0VyRwA ckUtB3qaxkWak7HIFiTrRmSilsU7uM71RIbvWJEXj0GLaS6nqdz2W+gk2tZ5t3R+oFto uGnHAn1JzrlYTlX+kIwmrhf/lFi/T+8U2AioTmU8s5r9J6UW9djM5+PvOAuJtK/mNUs/ QiGA== X-Gm-Message-State: AA6/9Rla4c8xWB+wK8Vzj61iBVTSvayZ+A+3bIklirGzIIPwAN4W1qWGajloqpmQc/OgP9QGb53aagpS5Y3yKdIH X-Received: by 10.107.176.204 with SMTP id z195mr10149019ioe.133.1476949010507; Thu, 20 Oct 2016 00:36:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.25.139 with HTTP; Thu, 20 Oct 2016 00:36:29 -0700 (PDT) In-Reply-To: References: From: Ashesh Vashi Date: Thu, 20 Oct 2016 13:06:29 +0530 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Fahar Abbas Cc: Murtuza Zabuawala , Dave Page , pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Type: multipart/alternative; boundary=001a114537ec1f8267053f46fdc0 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a114537ec1f8267053f46fdc0 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 20, 2016 at 1:00 PM, Fahar Abbas wrote: > Murtaza, > > Once i delete key table from pgAdmin4.db file then i can launch pgAdmin4 > with terminal as well as web browser for existing pgAdmin4 setup. > > > In case of fresh setup once we delete key table and apply latest patch > following message displayed: > > python pgAdmin4.py > Traceback (most recent call last): > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", > line 1139, in _execute_context > context) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/default.py", > line 450, in do_execute > cursor.execute(statement, parameters) > sqlite3.OperationalError: no such table: keys > That's because - you've not yet update the ConfigDB to 13 in the version table in the sqlite configuration table. And, the next exception, you're describing, is result of that. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company *http://www.linkedin.com/in/asheshvashi* > > The above exception was the direct cause of the following exception: > > Traceback (most recent call last): > File "pgAdmin4.py", line 46, in > app = create_app() > File "/home/fahar/Projects/pgadmin4/web/pgadmin/__init__.py", line 224, > in create_app > config.CSRF_SESSION_KEY = Keys.query.filter_by(name = > 'CSRF_SESSION_KEY').first().value > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", > line 2659, in first > ret = list(self[0:1]) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", > line 2457, in __getitem__ > return list(res) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", > line 2761, in __iter__ > return self._execute_and_instances(context) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", > line 2776, in _execute_and_instances > result = conn.execute(querycontext.statement, self._params) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", > line 914, in execute > return meth(self, multiparams, params) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/sql/elements.py", > line 323, in _execute_on_connection > return connection._execute_clauseelement(self, multiparams, params) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", > line 1010, in _execute_clauseelement > compiled_sql, distilled_params > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", > line 1146, in _execute_context > context) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", > line 1341, in _handle_dbapi_exception > exc_info > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/util/compat.py", > line 202, in raise_from_cause > reraise(type(exception), exception, tb=exc_tb, cause=cause) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/util/compat.py", > line 185, in reraise > raise value.with_traceback(tb) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", > line 1139, in _execute_context > context) > File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/default.py", > line 450, in do_execute > cursor.execute(statement, parameters) > sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such > table: keys [SQL: 'SELECT keys.name AS keys_name, keys.value AS > keys_value \nFROM keys \nWHERE keys.name = ?\n LIMIT ? OFFSET ?'] > [parameters: ('CSRF_SESSION_KEY', 1, 0)] > > > On Thu, Oct 20, 2016 at 11:00 AM, Murtuza Zabuawala enterprisedb.com> wrote: > >> Could you delete 'keys' table from pgadmin4.db file & try again? >> >> -- >> Regards, >> Murtuza Zabuawala >> EnterpriseDB: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> On Thu, Oct 20, 2016 at 11:26 AM, Fahar Abbas < >> fahar.abbas@enterprisedb.com> wrote: >> >>> Murtaza, >>> >>> I have applied this patch and there is no success on new pgAdmin4 setup >>> as well as existing pgAdmin4 setup. >>> >>> On Thu, Oct 20, 2016 at 10:45 AM, Murtuza Zabuawala < >>> murtuza.zabuawala@enterprisedb.com> wrote: >>> >>>> Hi, >>>> >>>> PFA patch to fix the issue for Pyhton3. >>>> RM#1849 >>>> >>>> -- >>>> Regards, >>>> Murtuza Zabuawala >>>> EnterpriseDB: http://www.enterprisedb.com >>>> The Enterprise PostgreSQL Company >>>> >>>> On Thu, Oct 20, 2016 at 11:03 AM, Fahar Abbas < >>>> fahar.abbas@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> I have reopened following RM: >>>>> ================================ >>>>> https://redmine.postgresql.org/issues/1849 >>>>> >>>>> On Wed, Oct 19, 2016 at 6:04 PM, Dave Page wrote: >>>>> >>>>>> Patch applied. >>>>>> >>>>>> On Wed, Oct 19, 2016 at 11:55 AM, Ashesh Vashi < >>>>>> ashesh.vashi@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Fahar, >>>>>>> >>>>>>> Please log the case on redmine. >>>>>>> Please find the attached patch, please apply it locally, and test it. >>>>>>> >>>>>>> And, please update the case, and this mail chain accordingly. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thanks & Regards, >>>>>>> >>>>>>> Ashesh Vashi >>>>>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company >>>>>>> >>>>>>> >>>>>>> >>>>>>> *http://www.linkedin.com/in/asheshvashi* >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 19, 2016 at 3:47 PM, Fahar Abbas < >>>>>>> fahar.abbas@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Here is the output of if we copy config_local.py and execute 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.abbas@enterprisedb.com >>>>>>>> Password: >>>>>>>> Retype password: >>>>>>>> Traceback (most recent call last): >>>>>>>> File "setup.py", line 449, in >>>>>>>> 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" >>>>>>>> python setup.py >>>>>>>> pgAdmin 4 - Application Initialisation >>>>>>>> ====================================== >>>>>>>> >>>>>>>> User can not do any setup for web based now. >>>>>>>> >>>>>>>> >>>>>>>> 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.abbas@enterprisedb.com >>>>>>>> Password: >>>>>>>> Retype password: >>>>>>>> Traceback (most recent call last): >>>>>>>> File "setup.py", line 449, in >>>>>>>> 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" >>>>>>>> >>>>>>>> On Wed, Oct 19, 2016 at 3:03 PM, Fahar Abbas < >>>>>>>> fahar.abbas@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> 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.abbas@enterprisedb.com >>>>>>>>> Password: >>>>>>>>> Retype password: >>>>>>>>> Traceback (most recent call last): >>>>>>>>> File "setup.py", line 449, in >>>>>>>>> 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.abbas@enterprisedb.com> wrote: >>>>>>>>> >>>>>>>>>> Sure, >>>>>>>>>> >>>>>>>>>> Will test this thoroughly after complete investigation. >>>>>>>>>> >>>>>>>>>> Kind Regards, >>>>>>>>>> >>>>>>>>>> On Wed, Oct 19, 2016 at 1:27 PM, Dave Page >>>>>>>>>> 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.vashi@enterprisedb.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Dave, >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Oct 15, 2016 at 8:02 AM, Dave Page >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Friday, October 14, 2016, Dave Page >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thursday, October 13, 2016, Ashesh Vashi < >>>>>>>>>>>>>> ashesh.vashi@enterprisedb.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Dave, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 9:10 PM, Dave Page < >>>>>>>>>>>>>>> dpage@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.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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>> >> >> > > > -- > 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 > --001a114537ec1f8267053f46fdc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 20, 2016 at 1:00 PM, Fahar Abbas <fahar.abbas@enterpris= edb.com> wrote:
Murtaza,

Once i delete key = table from pgAdmin4.db file then i can launch pgAdmin4 with terminal as wel= l as web browser for existing pgAdmin4 setup.


In case of f= resh setup once we delete key table and apply latest patch following messag= e displayed:

python pgAdmin4.py
Traceback= (most recent call last):
=C2=A0 File "/home/fahar/venv/lib/= python3.5/site-packages/sqlalchemy/engine/base.py", line 113= 9, in _execute_context
=C2=A0=C2=A0=C2=A0 context)
=C2=A0 File "= /home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/de= fault.py", line 450, in do_execute
=C2=A0=C2=A0=C2=A0 cursor.execut= e(statement, parameters)
sqlite3.OperationalError: no such table: keys
That's because - you've not yet update th= e ConfigDB to 13 in the version table in the sqlite configuration table.

And, the next exception, you're describing, is r= esult of that.

--

Thanks & Regards,

Ashesh Vashi
Enterpr= iseDB INDIA:=C2=A0Enterprise PostgreSQL Company


=

http://www.linkedin.com/in/asheshvashi

=C2=A0

The above exception was the direct cause of the= following exception:

Traceback (most recent = call last):
=C2=A0 File "pgAdmin4.py", line 46, in <= module>
=C2=A0=C2=A0=C2=A0 app =3D create_app()
=C2=A0 File "= /home/fahar/Projects/pgadmin4/web/pgadmin/__init__.py", line= 224, in create_app
=C2=A0=C2=A0=C2=A0 config.CSRF_SESSION_KEY =3D Keys.= query.filter_by(name =3D 'CSRF_SESSION_KEY').first().value
= =C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/sqlalch= emy/orm/query.py", line 2659, in first
=C2=A0=C2=A0=C2=A0 ret = =3D list(self[0:1])
=C2=A0 File "/home/fahar/venv/lib/python3.= 5/site-packages/sqlalchemy/orm/query.py", line 2457, in __getitem= __
=C2=A0=C2=A0=C2=A0 return list(res)
=C2=A0 File "/home/fahar/= venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", l= ine 2761, in __iter__
=C2=A0=C2=A0=C2=A0 return self._execute_and_instan= ces(context)
=C2=A0 File "/home/fahar/venv/lib/python3.5/= site-packages/sqlalchemy/orm/query.py", line 2776, in _execute_an= d_instances
=C2=A0=C2=A0=C2=A0 result =3D conn.execute(querycontext.statement, self._params)
=C2=A0 File "/home/fahar/venv/lib/python3= .5/site-packages/sqlalchemy/engine/base.py", line 914, in ex= ecute
=C2=A0=C2=A0=C2=A0 return meth(self, multiparams, params)
=C2= =A0 File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy= /sql/elements.py", line 323, in _execute_on_connection
=C2=A0= =C2=A0=C2=A0 return connection._execute_clauseelement(self, multiparam= s, params)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-pa= ckages/sqlalchemy/engine/base.py", line 1010, in _execute_clausee= lement
=C2=A0=C2=A0=C2=A0 compiled_sql, distilled_params
=C2=A0 File = "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/eng= ine/base.py", line 1146, in _execute_context
=C2=A0=C2=A0=C2=A0 con= text)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-package= s/sqlalchemy/engine/base.py", line 1341, in _handle_dbapi_excepti= on
=C2=A0=C2=A0=C2=A0 exc_info
=C2=A0 File "/home/fahar/venv/lib= /python3.5/site-packages/sqlalchemy/util/compat.py", line 20= 2, in raise_from_cause
=C2=A0=C2=A0=C2=A0 reraise(type(exception), excep= tion, tb=3Dexc_tb, cause=3Dcause)
=C2=A0 File "/home/fahar/venv/lib= /python3.5/site-packages/sqlalchemy/util/compat.py", line 18= 5, in reraise
=C2=A0=C2=A0=C2=A0 raise value.with_traceback(tb)
=C2= =A0 File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy= /engine/base.py", line 1139, in _execute_context
=C2=A0=C2=A0= =C2=A0 context)
=C2=A0 File "/home/fahar/venv/lib/python3.5/si= te-packages/sqlalchemy/engine/default.py", line 450, in do_execut= e
=C2=A0=C2=A0=C2=A0 cursor.execute(statement, parameters)
sqlalchemy= .exc.OperationalError: (sqlite3.OperationalError) no such table: keys = [SQL: 'SELECT keys.name<= /a> AS keys_name, keys.value AS keys_value \nFROM keys \nWHERE keys.name =3D ?\n LIMIT ? OFFSET ?&#= 39;] [parameters: ('CSRF_SESSION_KEY', 1, 0)]


=
On Thu, Oct 20, 2016 at 11:00 AM, Murtuza Zabuaw= ala <murtuza.zabuawala@enterprisedb.com> wrote:
Could you delete 'keys' table from pgadmin4.db file & try = again?=C2=A0

<= div class=3D"gmail-m_-5882353770282211887m_-3981273782543008520gmail_signat= ure">
--
Regards,
Murtuza Zabuawala
EnterpriseDB:=C2=A0http://www.enterprisedb.com
The Enterprise Postgr= eSQL Company

On Thu, Oct 20, 2016 at 11:26 AM, Fahar Abbas <fa= har.abbas@enterprisedb.com> wrote:
Murtaza,

I ha= ve applied this patch and there is no success on new pgAdmin4 setup as well= as existing pgAdmin4 setup.

On Thu, Oct 20, 2016 at 10:45 AM, Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wro= te:
H= i,

PFA patch to fix the issue for Pyhton3.
RM#= 1849

--
Regards,
Murtuza Zabuawala
Enterpri= seDB:=C2=A0http://www.enterpr= isedb.com
The Enterprise PostgreSQL Company
=

On Thu, Oct 20, 2016 at 11:03 AM, Fahar Abba= s <fahar.abbas@enterprisedb.com> wrote:
Hi Dave,
I have reopened following RM:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
https://r= edmine.postgresql.org/issues/1849

On Wed, Oct 19, 2016 at 6:04 PM, Dave P= age <dpage@pgadmin.org> wrote:
Patch applied.

On Wed, Oct 19, 2016 at 11:55 AM, Ashesh Vashi = <ashe= sh.vashi@enterprisedb.com> wrote:
Hi Fahar,
=
Please log the case on redmine.
Please find the attached patc= h, please apply it locally, and test it.

And, plea= se update the case, and this mail chain accordingly.

--

Thanks & Regards,
Ashesh Vashi
<= span style=3D"font-style:italic">EnterpriseDB INDIA: Enterprise PostgreSQL Company


http://www.linkedin.com/in/asheshvashi


On Wed, Oct 19, 2016 at 3:47 P= M, Fahar Abbas <fahar.abbas@enterprisedb.com> wro= te:
<= div>Here is the output of if we copy config_local.py and execute python set= up.py
pgAdmin 4 - Application Initialisation
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


The configuration database - '/ho= me/fahar/.pgadmin/pgadmin4.db' does not exist.
Entering initial= setup mode...
NOTE: Configuring authentication for SERVER mode.

=
=C2=A0=C2=A0=C2=A0 Enter the email address and password to use for the = initial pgAdmin user=C2=A0=C2=A0=C2=A0=C2=A0 account:

Email address:= fahar.ab= bas@enterprisedb.com
Password:
Retype password:
Traceback (mo= st recent call last):
=C2=A0 File "setup.py", line 449, in <= ;module>
=C2=A0=C2=A0=C2=A0 do_setup(app)
=C2=A0 File "setup.= py", line 96, in do_setup
=C2=A0=C2=A0=C2=A0 password =3D encrypt_p= assword(p1)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-p= ackages/flask_security/utils.py", line 150, in encrypt_password=C2=A0=C2=A0=C2=A0 signed =3D get_hmac(password).decode('ascii&#= 39;)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages= /flask_security/utils.py", line 108, in get_hmac
=C2=A0=C2=A0= =C2=A0 'set to "%s"' % _security.password_hash)
Runtim= eError: The configuration value `SECURITY_PASSWORD_SALT` must not be None w= hen the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512&quo= t;
python setup.py
pgAdmin 4 - Application Initialisation
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

User can not do = any setup for web based now.


The configuration databa= se - '/home/fahar/.pgadmin/pgadmin4.db' does not exist.
Ent= ering initial setup mode...
NOTE: Configuring authentication for SERVER = mode.


=C2=A0=C2=A0=C2=A0 Enter the email address and password to= use for the initial pgAdmin user=C2=A0=C2=A0=C2=A0=C2=A0 account:

E= mail address: fahar.abbas@enterprisedb.com
Password:
Retype password:
= Traceback (most recent call last):
=C2=A0 File "setup.py", lin= e 449, in <module>
=C2=A0=C2=A0=C2=A0 do_setup(app)
=C2=A0 File= "setup.py", line 96, in do_setup
=C2=A0=C2=A0=C2=A0 password = =3D encrypt_password(p1)
=C2=A0 File "/home/fahar/venv/lib/python3.= 5/site-packages/flask_security/utils.py", line 150, in encry= pt_password
=C2=A0=C2=A0=C2=A0 signed =3D get_hmac(password).decode('= ;ascii')
=C2=A0 File "/home/fahar/venv/lib/python3.5/= site-packages/flask_security/utils.py", line 108, in get_hmac
= =C2=A0=C2=A0=C2=A0 'set to "%s"' % _security.password_has= h)
RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must n= ot be None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf= 2_sha512"

On = Wed, Oct 19, 2016 at 3:03 PM, Fahar Abbas <fahar.abbas@enterpri= sedb.com> wrote:
Dave,

Testing Envir= onment
=C2=A0
Ubuntu 16.04 Linux 64:
-----------------= ---------------

pg-AdminIV Development Environment Setup for Ubuntu=C2=A0 :


= 1) Install GIT

sudo apt-get install git

2) Install pip3

sudo apt-get install pyth= on3-pip

3) Install virtualenv

sudo pip3 install virtualenv

4) install below depen= dency 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 mkdi= r Projects

7) Clone git repo in Projects

git clone http://git.= postgresql.org/git/pgadmin4.git

8) a= ctivate virtual environment

source venv/bin/activa= te

9) Install modules

pip3 in= stall -r requirements_py3.txt

10) Edit the config.py file to config_local.py =C2=A0resides in P= rojects\pgAdmin4\web=C2=A0=C2=A0

11)Now run setup.py file =C2=A0(\P= rojects\pgAdmin4\web)

=C2=A0 =C2=A0 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 I= nitialisation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


T= he configuration database - '/home/fahar/.pgadmin/pgadmin4.db'= does not exist.
Entering initial setup mode...
NOTE: Configuring aut= hentication for SERVER mode.


=C2=A0=C2=A0=C2=A0 Enter the email = address and password to use for the initial pgAdmin user=C2=A0=C2=A0=C2=A0= =C2=A0 account:

Email address: fahar.abbas@enterprisedb.com
Password: =
Retype password:
Traceback (most recent call last):
=C2=A0 File &= quot;setup.py", line 449, in <module>
=C2=A0=C2=A0=C2=A0 do_s= etup(app)
=C2=A0 File "setup.py", line 96, in do_setup
=C2= =A0=C2=A0=C2=A0 password =3D encrypt_password(p1)
=C2=A0 File "/hom= e/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py&= quot;, line 150, in encrypt_password
=C2=A0=C2=A0=C2=A0 signed =3D get_h= mac(password).decode('ascii')
=C2=A0 File "/home/fahar= /venv/lib/python3.5/site-packages/flask_security/utils.py", = line 108, in get_hmac
=C2=A0=C2=A0=C2=A0 'set to "%s"'= % _security.password_hash)
RuntimeError: The configuration value `SECUR= ITY_PASSWORD_SALT` must not be None when the value of `SECURITY_PASSWORD_HA= SH` is set to "pbkdf2_sha512"
(venv) fahar@fahar-virtual-machi= ne:~/Projects/pgadmin4/web$

<= br>
Is this expected?

On Wed, Oct 19, 2016 at 1:37 PM, Fahar Abbas <fahar.abbas@enterprisedb.com> wrote:
Sure,

<= /div>Will test this thoroughly after complete investigation.

K= ind Regards,

On Wed, Oct 19, 2016 at 1:27 PM, Dave Page <dpage@pgadmin.org> wrote:
Patch applied.

Fahar, can you please test this = thoroughly in desktop and server modes, with both fresh and upgraded instal= lations?


Packagers: This change means that package= s are no longer forced to create a config_local.py file, and there is no lo= nger any need to explicitly set=C2=A0SECUR= ITY_PASSWORD_SALT,=C2=A0SECURI= TY_KEY and=C2=A0CSRF_SESSION_KEY in the config (in fact, they should be rem= oved for new installations, if you have included them in 1.0)
<= div>
Thanks.


On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Vas= hi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dav= e,

On Sat, Oct 15, 2016 at 8:02 AM, = Dave Page <dpage@pgadmin.org> wrote:
Hi


On Friday, October 14, 2016, Dave Pag= e <dpage@pgadmin.= org> wrote:
Hi<= br>
On Thursday, October 13, 2016, Ashesh Vashi <ashesh.vashi@ente= rprisedb.com> wrote:
Hi Dave,

On Tue, Oct 11, 2016 at 9:10 PM, Dave Page <dpage@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 p= gAdmin 4 environment with 'web' mode.
- Apply the patch
- Start the pgAdmin4 application (stand alone application).
<= div>- 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 prope= rly.

Hmm.
=C2=A0

<= div>I had moved the Security object initialization after fetching these con= figurations from the database.
I have attached a addon patch for = the same.

OK, thank= s.
=C2=A0
=

Now - I run into another issue.
Because - the exi= sting password was hashed using the old SECURITY_PASSWORD_SALT, I am no mor= e 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 s= ecurity configurations in the database during upgrade process in 'web&#= 39; mode.

My concer= n with that is that we'll likely be storing the default config values i= n many cases, thus for those users, perpetuating the problem.
I guess what we need to do is re-encrypt the password during th= e 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.=C2=A0

<= /div>
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 pr= oblem as from what I can see, =C2=A0SECURITY_PASSWORD_SALT is (aside from r= eally being a key not a salt) not the only salting that's done.=C2=A0

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 wit= h the same password end up with different hashes in the database, so clearl= y 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 passw= ords again, and found that the resulting hashes were different in both data= bases - thus there is something else ensuring the hashes are unique across = different installations/databases.

So, I believe w= e can do as you suggest and migrate existing values for SECURITY_PASSWORD_S= ALT, given that there's clearly some other per user and per installatio= n/database salting going on anyway. New installations can have the random v= alue for SECURITY_PASSWORD_SALT.
We do n= ot need to generate the random SECURITY_PASSWORD_SALT during upgrade mode, = which was wrong added in my addon patch.

Please fi= nd the updated patch.

Otherwise - looks good to me= .
Please commit the new patch (if you're ok with the change).=


--=

Thanks & Regards,

A= shesh Vashi
EnterpriseDB INDIA:=C2=A0Enterprise PostgreSQL Company


=

I don't believe SECURITY_KEY and=C2=A0CSRF_SESSION_= KEY are issues either, as they're used for purposes that are essentiall= y 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 wo= uld be appreciated)!

Thanks.


--
Dave PageBlog: http://pg= snake.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 Corporati= on
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
M= obile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com



--
<= div>Syed Fahar Abbas
Quality Management Group

E= nterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Direct: <= a href=3D"tel:%2B92-51-8466803" value=3D"+92518466803" target=3D"_blank">+9= 2-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.ab= bas
Website: w= ww.enterprisedb.com



--
Syed Fahar Abbas<= br>
Quality Management Group

EnterpriseDB Corporatio= n
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
Mo= bile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com




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

EnterpriseDB UK: http://www.enterprised= b.com
The Enterprise PostgreSQL Company


--
Syed Fahar Abbas
Quality Managem= ent Group

EnterpriseDB Corporation
Phone Office: +92-51-835= -8874
Phone Direct: +92-51-8466803
Mobile: +92-333-5409707Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com



--
Syed Fahar Abb= as
Quality Management Group

EnterpriseDB Corpora= tion
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: <= a href=3D"http://www.enterprisedb.com" target=3D"_blank">www.enterprisedb.c= om



--
Syed Fahar Abbas<= br>
Quality Management Group

EnterpriseDB Corporatio= n
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
Mobil= e: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com

--001a114537ec1f8267053f46fdc0--