From: | Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> |
Subject: | Re: RM1849: Auto-generating security keys |
Date: | 2016-10-13 14:16:56 |
Message-ID: | CAG7mmoyhJXXrLv+fgjmgd-Z5GFSaJfHTC89MWQ8LQX3Atw-04A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
Hi Dave,
On Tue, Oct 11, 2016 at 9:10 PM, Dave Page <dpage(at)pgadmin(dot)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.
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.
I was not able to spend much time on it due to some other priorities.
--
Thanks & Regards,
Ashesh Vashi
> The purpose is to auto-generate the various security keys that are
> currently in the configuration file, and store them in the SQLite database.
> This allows us to remove the checks for config_local.py and the hard-coded
> default keys which are causing some problems with packaging:
>
> - Hard coded defaults are fine for Desktop mode, and packages generally
> aim to make that work primarily.
> - Hard coded defaults are a security risk for Server mode, hence we
> currently require the user to manually setup keys, which is currently being
> overridden by packagers for Desktop mode.
>
> This change ensures that we have unique security keys for every
> installation, whether running in desktop or server mode (generated from
> os.urandom).
>
> Thanks!
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
Attachment | Content-Type | Size |
---|---|---|
add_auto_generate_security_keys.patch | application/octet-stream | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Priyanka Shendge | 2016-10-14 09:27:01 | Package and synonyms patch |
Previous Message | Dave Page | 2016-10-13 14:00:20 | Re: Foreign Table Patch |