[pgAdmin] RM6128 RM6084 datistemplate issue

[Rahul Shirsat]

Hi Hackers,

Please find the attached patch below which resolves the issue of
datistemplate.

-- 
*Rahul Shirsat*
Senior Software Engineer | EnterpriseDB Corporation.


RM6128_RM6084.patch
Description: Binary data

[pgAdmin][PM-6069]: Getting error while refreshing files in query tool

[Nikhil Mohite]

Hi Tema,

Please find the attached patch for RM-6069
: Getting error while
refreshing files in query tool.



-- 
*Thanks & Regards,*
*Nikhil Mohite*
*Software Engineer.*
*EDB Postgres* 
*Mob.No: +91-7798364578.*


RM_6069.patch
Description: Binary data

[pgAdmin][RM5488] Tooltip information does not display properly if user check all options under explain analyze

[Aditya Toshniwal]

Hi Hackers,

Attached patch improves the way explain plan details tooltip for a node is
shown. With the change, popup with details will be shown upon clicking a
node, and it will remain open until explicitly closed.

Please review.

-- 
Thanks,
Aditya Toshniwal
pgAdmin hacker | Sr. Software Engineer | *edbpostgres.com*

"Don't Complain about Heat, Plant a TREE"


RM5488.patch
Description: Binary data

pgAdmin 4 commit: Fixed an issue where sequences are not created. Fixes

[Akshay Joshi]

Fixed an issue where sequences are not created. Fixes #6128

refs #6084

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=d5c544216223bd9f995593b42ba74ef6ecd2
Author: Rahul Shirsat 

Modified Files
--
docs/en_US/release_notes_4_30.rst   |  1 +
.../server_groups/servers/databases/casts/__init__.py   |  9 +
.../servers/databases/event_triggers/__init__.py| 12 
.../server_groups/servers/databases/extensions/__init__.py  | 12 
.../servers/databases/foreign_data_wrappers/__init__.py | 12 
.../foreign_data_wrappers/foreign_servers/__init__.py   | 12 
.../foreign_servers/user_mappings/__init__.py   | 12 
.../server_groups/servers/databases/languages/__init__.py   | 13 +
.../server_groups/servers/databases/schemas/__init__.py | 13 -
.../servers/databases/schemas/catalog_objects/__init__.py   | 12 
.../databases/schemas/catalog_objects/columns/__init__.py   | 12 
.../servers/databases/schemas/collations/__init__.py| 12 
.../servers/databases/schemas/domains/__init__.py   | 12 +++-
.../schemas/domains/domain_constraints/__init__.py  | 12 
.../servers/databases/schemas/foreign_tables/__init__.py| 12 
.../databases/schemas/fts_configurations/__init__.py| 12 
.../servers/databases/schemas/fts_dictionaries/__init__.py  | 13 +
.../servers/databases/schemas/fts_parsers/__init__.py   | 13 +
.../servers/databases/schemas/fts_templates/__init__.py | 13 +
.../servers/databases/schemas/sequences/__init__.py | 12 
.../servers/databases/schemas/synonyms/__init__.py  | 12 
.../databases/schemas/tables/compound_triggers/__init__.py  |  9 +
.../schemas/tables/constraints/check_constraint/__init__.py | 11 ++-
.../tables/constraints/exclusion_constraint/__init__.py | 11 ++-
.../schemas/tables/constraints/foreign_key/__init__.py  | 12 +++-
.../schemas/tables/constraints/index_constraint/__init__.py | 12 +++-
.../server_groups/servers/resource_groups/__init__.py   | 11 ++-
web/pgadmin/browser/server_groups/servers/roles/__init__.py | 10 +-
.../browser/server_groups/servers/tablespaces/__init__.py   | 10 +-
web/pgadmin/utils/driver/psycopg2/server_manager.py |  3 ++-
30 files changed, 250 insertions(+), 82 deletions(-)

pgAdmin 4 commit: Ensure that verbose logs should be visible for Utilit

[Akshay Joshi]

Ensure that verbose logs should be visible for Utility(Backup, Maintenance) 
jobs. Fixes #6140

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=90004119afd235b7c7c6d784b217f9a7684e420d

Modified Files
--
docs/en_US/release_notes_4_30.rst   | 1 +
web/pgadmin/misc/bgprocess/processes.py | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)

pgAdmin 4 commit: Fixed an issue on refreshing files in Query Tool. Fix

[Akshay Joshi]

Fixed an issue on refreshing files in Query Tool. Fixes #6069

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=0fcfe630921f49b89db89b47a51031f17474808c
Author: Nikhil Mohite 

Modified Files
--
docs/en_US/release_notes_4_30.rst  |  1 +
.../misc/file_manager/static/js/create_dialogue.js | 72 --
.../misc/file_manager/static/js/select_dialogue.js | 29 +
web/pgadmin/misc/file_manager/static/js/utility.js |  6 +-
.../file_manager/templates/file_manager/index.html |  2 +-
5 files changed, 62 insertions(+), 48 deletions(-)

pgAdmin 4 commit: Fixed an issue where the database list in the new con

[Akshay Joshi]

Fixed an issue where the database list in the new connection window is not 
visible. Fixes #6121

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=f8497d4e7aa3af4ee4a24584ad67816be6405883
Author: Nikhil Mohite 

Modified Files
--
docs/en_US/release_notes_4_30.rst | 1 +
.../servers/databases/templates/databases/sql/default/nodes.sql   | 4 
2 files changed, 5 insertions(+)

Re: [pgAdmin][RM-6121]: Unable to see database list in connection window launched from change connection option in query tool

[Akshay Joshi]

Thanks, patch applied.

On Thu, Jan 7, 2021 at 5:05 PM Nikhil Mohite 
wrote:

> Hi Team,
>
> Please find the attached patch for RM-6121
> : Unable to see database list
> in connection window launched from change connection option in query tool.
>
> --
> *Thanks & Regards,*
> *Nikhil Mohite*
> *Software Engineer.*
> *EDB Postgres* 
> *Mob.No: +91-7798364578.*
>


-- 
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres *

*Mobile: +91 976-788-8246*

Re: [pgAdmin] RM6128 RM6084 datistemplate issue

[Akshay Joshi]

Thanks, patch applied.

On Mon, Jan 11, 2021 at 2:43 PM Rahul Shirsat <
rahul.shir...@enterprisedb.com> wrote:

> Hi Hackers,
>
> Please find the attached patch below which resolves the issue of
> datistemplate.
>
> --
> *Rahul Shirsat*
> Senior Software Engineer | EnterpriseDB Corporation.
>


-- 
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres *

*Mobile: +91 976-788-8246*

Re: [pgAdmin][PM-6069]: Getting error while refreshing files in query tool

[Akshay Joshi]

Thanks, patch applied.

On Mon, Jan 11, 2021 at 4:16 PM Nikhil Mohite <
nikhil.moh...@enterprisedb.com> wrote:

> Hi Tema,
>
> Please find the attached patch for RM-6069
> : Getting error while
> refreshing files in query tool.
>
>
>
> --
> *Thanks & Regards,*
> *Nikhil Mohite*
> *Software Engineer.*
> *EDB Postgres* 
> *Mob.No: +91-7798364578.*
>


-- 
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres *

*Mobile: +91 976-788-8246*

Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1

[Magnus Hagander]

On Sun, Jan 3, 2021 at 6:31 PM Stephen Frost  wrote:
>
> Greetings,
>
> * Dave Page (dp...@pgadmin.org) wrote:
> > On Sat, 2 Jan 2021 at 15:59, Stephen Frost  wrote:
> > > * Dave Page (dp...@pgadmin.org) wrote:
> > > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost  wrote:
> > > > > * Khushboo Vashi (khushboo.va...@enterprisedb.com) wrote:
> > > > > > Please find the attached patch to support Kerberos Authentication in
> > > > > > pgAdmin RM 5457.
> > > > > >
> > > > > > The patch introduces a new pluggable option for Kerberos
> > > authentication,
> > > > > > using SPNEGO to forward kerberos tickets through a browser which 
> > > > > > will
> > > > > > bypass the login page entirely if the Kerberos Authentication
> > > succeeds.
> > > > >
> > > > > I've taken a (very short) look at this as it's certainly something 
> > > > > that
> > > > > I'm interested in and glad to see work is being done on it.
> > > > >
> > > > > I notice that 'delegated_creds' is being set but it's unclear to me 
> > > > > how
> > > > > they're actually being used (if at all), which is a very important 
> > > > > part
> > > > > of Kerberos.
> > > > >
> > > > > What's commonly done with mod_auth_kerb/mod_auth_gss is that the
> > > > > delegated credentials are stored on the filesystem in a temporary
> > > > > directory and then an environment variable is set to signal to libpq /
> > > > > the Kerberos libraries that the delegated credentials can be found in
> > > > > the temporary file.  I don't see any of that happening in this patch-
> > > is
> > > > > that already handled in some way?  If not, what's the plan for making
> > > > > that work?  Also important is to make sure that this approach will 
> > > > > work
> > > > > for constrainted delegation implementations.
> > > >
> > > > Phase 1 of this project (which this patch aims to implement) is to 
> > > > handle
> > > > Kerberos logins to pgAdmin when running in server mode (as we’ve already
> > > > done for LDAP, except KRB authenticated users don’t see a login page of
> > > > course). Phase 2 will add support for logging into the PostgreSQL
> > > servers -
> > > > I believe that is where we’ll need to handle delegated credentials,
> > > correct?
> > >
> > > Yes, though I sure hope there isn't a plan to release just 'phase 1'
> > > since that would imply that the user is still sending their password to
> > > pgAdmin in some form that pgAdmin then turns around and impersonates the
> > > user, basically completely against how Kerberos auth should be working
> > > in this kind of a intermediate service arrangement.
> > >
> > > In other words, if just 'phase 1' is released, it'd probably be CVE
> > > worthy right out of the gate...
> >
> > It wouldn’t impersonate the user at all, it would just work as it does now,
> > requiring the user to supply a username/password for scram/md5/ldap etc, or
> > a cert for SSL auth. Connection to a PostgreSQL server which required gss
> > or sspi simply wouldn’t work (unless the service account under which the
> > pgAdmin server is running has a valid ticket through other means).
>
> That *is* impersonating the user..
>
> Kerberized services really should *not* be accepting a cleartext
> password to use to authenticate as the user against another service,
> which is why I'd strongly recommend against releasing with just
> 'phase 1' done.. or at least heavily caveat'ing it that this isn't
> actually real Kerberos support but is just an intermediate step that no
> one should really deploy...

AIUI that's not what's being proposed.

Correct me if I'm wrong, but I think what's said is that this phase would:

1. Allow kerberos login *to pgadmin*.
2. Do exactly *nothing* to logins to the database server.

So per (2) logins to the db server would work exactly the same as it
does today, and bear no connection to the actual KRB login at all.

One question around that though -- when I click "save password" on a
database connection in pgadmin, it gets stored on the pgadmin server.
Isn't the key used to encrypt that derived from my password?  If I'm
logging into pgadmin without a password (using kerberos),what would
that key be derived from?

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1

[Dave Page]

On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander  wrote:

> On Sun, Jan 3, 2021 at 6:31 PM Stephen Frost  wrote:
> >
> > Greetings,
> >
> > * Dave Page (dp...@pgadmin.org) wrote:
> > > On Sat, 2 Jan 2021 at 15:59, Stephen Frost  wrote:
> > > > * Dave Page (dp...@pgadmin.org) wrote:
> > > > > On Sat, 2 Jan 2021 at 15:41, Stephen Frost 
> wrote:
> > > > > > * Khushboo Vashi (khushboo.va...@enterprisedb.com) wrote:
> > > > > > > Please find the attached patch to support Kerberos
> Authentication in
> > > > > > > pgAdmin RM 5457.
> > > > > > >
> > > > > > > The patch introduces a new pluggable option for Kerberos
> > > > authentication,
> > > > > > > using SPNEGO to forward kerberos tickets through a browser
> which will
> > > > > > > bypass the login page entirely if the Kerberos Authentication
> > > > succeeds.
> > > > > >
> > > > > > I've taken a (very short) look at this as it's certainly
> something that
> > > > > > I'm interested in and glad to see work is being done on it.
> > > > > >
> > > > > > I notice that 'delegated_creds' is being set but it's unclear to
> me how
> > > > > > they're actually being used (if at all), which is a very
> important part
> > > > > > of Kerberos.
> > > > > >
> > > > > > What's commonly done with mod_auth_kerb/mod_auth_gss is that the
> > > > > > delegated credentials are stored on the filesystem in a temporary
> > > > > > directory and then an environment variable is set to signal to
> libpq /
> > > > > > the Kerberos libraries that the delegated credentials can be
> found in
> > > > > > the temporary file.  I don't see any of that happening in this
> patch-
> > > > is
> > > > > > that already handled in some way?  If not, what's the plan for
> making
> > > > > > that work?  Also important is to make sure that this approach
> will work
> > > > > > for constrainted delegation implementations.
> > > > >
> > > > > Phase 1 of this project (which this patch aims to implement) is to
> handle
> > > > > Kerberos logins to pgAdmin when running in server mode (as we’ve
> already
> > > > > done for LDAP, except KRB authenticated users don’t see a login
> page of
> > > > > course). Phase 2 will add support for logging into the PostgreSQL
> > > > servers -
> > > > > I believe that is where we’ll need to handle delegated credentials,
> > > > correct?
> > > >
> > > > Yes, though I sure hope there isn't a plan to release just 'phase 1'
> > > > since that would imply that the user is still sending their password
> to
> > > > pgAdmin in some form that pgAdmin then turns around and impersonates
> the
> > > > user, basically completely against how Kerberos auth should be
> working
> > > > in this kind of a intermediate service arrangement.
> > > >
> > > > In other words, if just 'phase 1' is released, it'd probably be CVE
> > > > worthy right out of the gate...
> > >
> > > It wouldn’t impersonate the user at all, it would just work as it does
> now,
> > > requiring the user to supply a username/password for scram/md5/ldap
> etc, or
> > > a cert for SSL auth. Connection to a PostgreSQL server which required
> gss
> > > or sspi simply wouldn’t work (unless the service account under which
> the
> > > pgAdmin server is running has a valid ticket through other means).
> >
> > That *is* impersonating the user..
> >
> > Kerberized services really should *not* be accepting a cleartext
> > password to use to authenticate as the user against another service,
> > which is why I'd strongly recommend against releasing with just
> > 'phase 1' done.. or at least heavily caveat'ing it that this isn't
> > actually real Kerberos support but is just an intermediate step that no
> > one should really deploy...
>
> AIUI that's not what's being proposed.
>
> Correct me if I'm wrong, but I think what's said is that this phase would:
>
> 1. Allow kerberos login *to pgadmin*.
> 2. Do exactly *nothing* to logins to the database server.
>
> So per (2) logins to the db server would work exactly the same as it
> does today, and bear no connection to the actual KRB login at all.
>

Correct.


>
> One question around that though -- when I click "save password" on a
> database connection in pgadmin, it gets stored on the pgadmin server.
> Isn't the key used to encrypt that derived from my password?  If I'm
> logging into pgadmin without a password (using kerberos),what would
> that key be derived from?
>

Also correct - and right now, the plan is to disable password saving if
logged in using Kerberos.

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

EDB: http://www.enterprisedb.com

Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1

[Stephen Frost]

Greetings,

* Dave Page (dp...@pgadmin.org) wrote:
> On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander  wrote:
> > One question around that though -- when I click "save password" on a
> > database connection in pgadmin, it gets stored on the pgadmin server.
> > Isn't the key used to encrypt that derived from my password?  If I'm
> > logging into pgadmin without a password (using kerberos),what would
> > that key be derived from?
> 
> Also correct - and right now, the plan is to disable password saving if
> logged in using Kerberos.

Disable password *saving*, or disable password *using*?

If you're saying that, when Kerberos is enabled, users will never be
prompted to provide a password because password-based auth has been
disabled, then perhaps that's reasonable.  I don't know how useful such
a pgadmin setup would be, but at least it wouldn't be violating one of
the core values that using Kerberos brings.

If you're saying that this is just disabling password *saving*, then
that implies that if someone actually wants to use pgadmin to, uh, log
into a PostgreSQL server which is configured for md5 or SCRAM auth or
LDAP based auth that the way that'll work is that pgadmin will prompt
the user for a password, which the user will provide and which will
then be sent from the client to the pgadmin system in the clear, and
which pgadmin will turn around and use to log into PG with, right?

It's the latter than I'm concerned with because it just wouldn't be
appropriate for a Kerberized service which is set up to use Kerberos to
then prompt the user for a password.

In any case, I have a really hard time seeing this as being something
that it'd be good for the pgAdmin team to publish as "we now have
Kerberos support!" because, either way, it doesn't seem like it would be
usable in a secure manner in a Kerberized environment.  Once "phase 2"
is done (which hopefully will include both traditional credential
delegating and constrainted delegation support...), then it'll be a game
changer imv and something that everyone should be shouting from the
rooftops about and I'll be right there cheering it on too..

Thanks,

Stephen


signature.asc
Description: PGP signature

Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1

[Dave Page]

On Mon, Jan 11, 2021 at 4:50 PM Stephen Frost  wrote:

> Greetings,
>
> * Dave Page (dp...@pgadmin.org) wrote:
> > On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander 
> wrote:
> > > One question around that though -- when I click "save password" on a
> > > database connection in pgadmin, it gets stored on the pgadmin server.
> > > Isn't the key used to encrypt that derived from my password?  If I'm
> > > logging into pgadmin without a password (using kerberos),what would
> > > that key be derived from?
> >
> > Also correct - and right now, the plan is to disable password saving if
> > logged in using Kerberos.
>
> Disable password *saving*, or disable password *using*?
>

I'm pretty sure I wrote "saving".


>
> If you're saying that, when Kerberos is enabled, users will never be
> prompted to provide a password because password-based auth has been
> disabled, then perhaps that's reasonable.  I don't know how useful such
> a pgadmin setup would be, but at least it wouldn't be violating one of
> the core values that using Kerberos brings.
>
> If you're saying that this is just disabling password *saving*, then
> that implies that if someone actually wants to use pgadmin to, uh, log
> into a PostgreSQL server which is configured for md5 or SCRAM auth or
> LDAP based auth that the way that'll work is that pgadmin will prompt
> the user for a password, which the user will provide and which will
> then be sent from the client to the pgadmin system in the clear, and
> which pgadmin will turn around and use to log into PG with, right?
>

Yes.


>
> It's the latter than I'm concerned with because it just wouldn't be
> appropriate for a Kerberized service which is set up to use Kerberos to
> then prompt the user for a password.
>

Well you never answered my previous question about that. Why is it
appropriate for an FDW to do that, but not pgAdmin? Or for a user on a
kerberised machine to use a web browser to access a non-kerberised site? Or
frankly pretty much anything outside of a windows domain or kerberos
environment that a user inside the environment might want to use?

You basically seem to be saying that once a user logs into something using
Kerberos, *everything* else they login to from there must also be done
using Kerberos - which clearly will not be the case in the vast majority of
deployments.

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

EDB: http://www.enterprisedb.com

Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1

[Stephen Frost]

Greetings,

* Dave Page (dp...@pgadmin.org) wrote:
> On Mon, Jan 11, 2021 at 4:50 PM Stephen Frost  wrote:
> > If you're saying that, when Kerberos is enabled, users will never be
> > prompted to provide a password because password-based auth has been
> > disabled, then perhaps that's reasonable.  I don't know how useful such
> > a pgadmin setup would be, but at least it wouldn't be violating one of
> > the core values that using Kerberos brings.
> >
> > If you're saying that this is just disabling password *saving*, then
> > that implies that if someone actually wants to use pgadmin to, uh, log
> > into a PostgreSQL server which is configured for md5 or SCRAM auth or
> > LDAP based auth that the way that'll work is that pgadmin will prompt
> > the user for a password, which the user will provide and which will
> > then be sent from the client to the pgadmin system in the clear, and
> > which pgadmin will turn around and use to log into PG with, right?
> 
> Yes.

Alright, glad I wasn't completely misunderstanding something.

> > It's the latter than I'm concerned with because it just wouldn't be
> > appropriate for a Kerberized service which is set up to use Kerberos to
> > then prompt the user for a password.
> 
> Well you never answered my previous question about that. Why is it
> appropriate for an FDW to do that, but not pgAdmin? Or for a user on a
> kerberised machine to use a web browser to access a non-kerberised site? Or
> frankly pretty much anything outside of a windows domain or kerberos
> environment that a user inside the environment might want to use?

Pretty sure I didn't say it was appropriate for an FDW to do that, it
really isn't, but FDWs are also a side feature of the overall product,
not a core component, and you have to be granted specific rights to be
able to use an FDW.

Accessing systems outside of the Kerberized environment is obviously a
different situation as you *can't* use the Kerberos credentials- and,
hopefully, everyone is using password managers and has a distinct and
different password for every service they do use outside of the
Kerberized environment.  When you're talking about a set of systems
which live inside of the Kerberized environment, however, it's simply
not sensible to ask the user to provide their *domain-level* credentials
which an attacker could use to log in as that user to the entire domain
and have complete access over their account and that's exactly what is
likely to end up being the case here because the only way to set this up
would be Kerberos for pgAdmin and LDAP for PG- at least until delegated
credentials are implemented.

> You basically seem to be saying that once a user logs into something using
> Kerberos, *everything* else they login to from there must also be done
> using Kerberos - which clearly will not be the case in the vast majority of
> deployments.

Everything else they login to from there in the same Kerberized
environment absolutely should be done using Kerberos delegated
credentials.  That's the point of Kerberos delegation.  Are you modeling
this approach based on some existing system which accepts Kerberos
logins but then *doesn't* allow use of delegated credentials to log into
other Kerberized systems from there?  Surely SSH works great with
delegated credentials, as does any website that uses mod_auth_kerb or
mod_auth_gss, or IIS..

I sure hope that the vast majority of deployments where pgAdmin is set
up with Kerberos will be using Kerberos for logging into PG with
delegated credentials, and further, that we will be *strongly*
encouraging that as otherwise you might as well use LDAP auth for all of
it and accept that any compromise of the web server or of PG will result
in complete compromise of any user's account who accesses the system.

I don't understand all this push-back.

The intent is to do the 'phase 2', right?  And it hopefully will happen
in relatively short order, no?  At least, I'd think it would make sense,
while people have developer environments set up and working with
Kerberos to go ahead and get that part done.  All I'm saying is that the
'phase 1' part really shouldn't be independently released, or if it is,
it should be *heavily* caveated that it is strongly discouraged for
people to run it in an environment where pgadmin and PG are in the same
Kerberized environment because it's not possible to set that up, with
just phase 1 done, in a manner which would avoid the pgadmin and PG
servers seeing the user's password.

Thanks,

Stephen


signature.asc
Description: PGP signature

Somewhat excessive version checks

[Magnus Hagander]

Hi!

If I read the code correctly, pgadmin will (unless turned off) hit the
website to check the version.json file for updates *every time it
starts*.

Wouldn't it make sense to rate limit that to checking say once per 24
hours maximum? Or even 48?

It seems nobody needs the update *that* quickly, and AFAICT it does
call out to make that check synchronously on startup which means the
user is waiting.

And if/when doing that, it would be useful to include an
If-Modified-Since header on the request, so the server can just
respond with a tiny 304 reply when there is no update, which is going
to be the majority of the time. Or possibly even more efficiently,
create a custom etag and use If-None-Matches. If you make that etag be
say the version that the client has, it becomes very cheap to check
and you don't need to track any extra data.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/

Re: Somewhat excessive version checks

[Khushboo Vashi]

On Tue, Jan 12, 2021 at 3:36 AM Magnus Hagander  wrote:

> Hi!
>
> If I read the code correctly, pgadmin will (unless turned off) hit the
> website to check the version.json file for updates *every time it
> starts*.
>
> Wouldn't it make sense to rate limit that to checking say once per 24
> hours maximum? Or even 48?
>
> It seems nobody needs the update *that* quickly, and AFAICT it does
> call out to make that check synchronously on startup which means the
> user is waiting.
>
> Agreed, we should have some mechanism in place to limit the server hit,
maybe an asynchronous call from the client while loading.


> And if/when doing that, it would be useful to include an
> If-Modified-Since header on the request, so the server can just
> respond with a tiny 304 reply when there is no update, which is going
> to be the majority of the time. Or possibly even more efficiently,
> create a custom etag and use If-None-Matches. If you make that etag be
> say the version that the client has, it becomes very cheap to check
> and you don't need to track any extra data.
>
> --
>  Magnus Hagander
>  Me: https://www.hagander.net/
>  Work: https://www.redpill-linpro.com/
>
>
>

The target connection was wrong in function check_version_compatibility()

[Huang, Jun]

Hi,
The target connection was made by source connection manager(it should be made 
by target connection manager)
in function 
check_version_compatibility(web\pgadmin\tools\schema_diff\__init__.py).
Attached patch adds the changes.

Regrads,
Huang




0001-Target-connection-was-wrong-in-function.patch
Description: 0001-Target-connection-was-wrong-in-function.patch