Thread: [pgAdmin][RM4755] pgAdmin does not work behind reverse proxy if inbuilt server is used as it is

Hi,

We need to make it configurable, we don't require middleware when we are running in Desktop mode.

On Thu, Sep 19, 2019 at 3:52 PM Dave Page <dpage@pgadmin.org> wrote:

On Thu, Sep 19, 2019 at 11:13 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Thu, Sep 19, 2019 at 3:28 PM Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Sep 19, 2019 at 6:29 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi Hackers,

Attached is the patch to allow pgAdmin to work behind proxy with its in built server. I have used werkzeug fixer - https://werkzeug.palletsprojects.com/en/0.15.x/middleware/proxy_fix/#module-werkzeug.middleware.proxy_fix

Does this work with both X-Scheme and X-Forwarded-Proto headers as discussed?

The proxy fix work for all standard X-Forwarded-* headers. X-Scheme is not used anywhere, X-Forwarded-Proto is more robust.

Right, but our existing code uses X-Scheme (as per old advice since removed from the Flask website - see RM3149), and users have deployments that will be setup that way. We need to fall back to X-Scheme if it is present but X-Forwarded-Proto is not, to avoid breaking their installations.

 

I assume (as you haven't removed it) that it works in conjunction with the existing reverse proxy code?

Yes it should. 

Cool :-)

 

Thanks!

 

--

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

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

--

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

It is small improvement we can do to avoid overhead of checking headers in each HTTP requests for proxies.

On Thu, Sep 19, 2019 at 4:12 PM Dave Page <dpage@pgadmin.org> wrote:

Sure, but is it going to make any real difference? I'd rather have it "just work" if possible.

This isn't like compression which we expect to use noticable CPU cycles.

On Thu, Sep 19, 2019 at 11:39 AM Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote:

Hi,

We need to make it configurable, we don't require middleware when we are running in Desktop mode.

On Thu, Sep 19, 2019 at 3:52 PM Dave Page <dpage@pgadmin.org> wrote:

On Thu, Sep 19, 2019 at 11:13 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Thu, Sep 19, 2019 at 3:28 PM Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Sep 19, 2019 at 6:29 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi Hackers,

Attached is the patch to allow pgAdmin to work behind proxy with its in built server. I have used werkzeug fixer - https://werkzeug.palletsprojects.com/en/0.15.x/middleware/proxy_fix/#module-werkzeug.middleware.proxy_fix

Does this work with both X-Scheme and X-Forwarded-Proto headers as discussed?

The proxy fix work for all standard X-Forwarded-* headers. X-Scheme is not used anywhere, X-Forwarded-Proto is more robust.

Right, but our existing code uses X-Scheme (as per old advice since removed from the Flask website - see RM3149), and users have deployments that will be setup that way. We need to fall back to X-Scheme if it is present but X-Forwarded-Proto is not, to avoid breaking their installations.

 

I assume (as you haven't removed it) that it works in conjunction with the existing reverse proxy code?

Yes it should. 

Cool :-)

 

Thanks!

 

--

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

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

--

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

On Thu, Sep 19, 2019 at 4:24 PM Dave Page <dpage@pgadmin.org> wrote:

If we can do it automatically at startup based on whether or not the Python code thinks we're running under Desktop mode or not, then I suppose it's a win. That would replace one test per request with one test at startup. It'll still be a minute difference, but every little bit helps I guess.

OK. I'll try. 

On Thu, Sep 19, 2019 at 11:50 AM Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote:

It is small improvement we can do to avoid overhead of checking headers in each HTTP requests for proxies.

On Thu, Sep 19, 2019 at 4:12 PM Dave Page <dpage@pgadmin.org> wrote:

Sure, but is it going to make any real difference? I'd rather have it "just work" if possible.

This isn't like compression which we expect to use noticable CPU cycles.

On Thu, Sep 19, 2019 at 11:39 AM Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote:

Hi,

We need to make it configurable, we don't require middleware when we are running in Desktop mode.

On Thu, Sep 19, 2019 at 3:52 PM Dave Page <dpage@pgadmin.org> wrote:

On Thu, Sep 19, 2019 at 11:13 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Thu, Sep 19, 2019 at 3:28 PM Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Sep 19, 2019 at 6:29 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi Hackers,

Attached is the patch to allow pgAdmin to work behind proxy with its in built server. I have used werkzeug fixer - https://werkzeug.palletsprojects.com/en/0.15.x/middleware/proxy_fix/#module-werkzeug.middleware.proxy_fix

Does this work with both X-Scheme and X-Forwarded-Proto headers as discussed?

The proxy fix work for all standard X-Forwarded-* headers. X-Scheme is not used anywhere, X-Forwarded-Proto is more robust.

Right, but our existing code uses X-Scheme (as per old advice since removed from the Flask website - see RM3149), and users have deployments that will be setup that way. We need to fall back to X-Scheme if it is present but X-Forwarded-Proto is not, to avoid breaking their installations.

 

I assume (as you haven't removed it) that it works in conjunction with the existing reverse proxy code?

Yes it should. 

Cool :-)

 

Thanks!

 

--

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

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

--

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

--

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

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

Hi Hackers,

Attached is the updated patch. The patch will enhance the existing reverse proxy feature using ProxyFix. It is compatible with existing X-Scheme option.

Plus, as suggested, the reverse proxy feature will be applied only if SERVER_MODE is True.

Kindly review.

On Thu, Sep 19, 2019 at 4:26 PM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

On Thu, Sep 19, 2019 at 4:24 PM Dave Page <dpage@pgadmin.org> wrote:

If we can do it automatically at startup based on whether or not the Python code thinks we're running under Desktop mode or not, then I suppose it's a win. That would replace one test per request with one test at startup. It'll still be a minute difference, but every little bit helps I guess.

OK. I'll try. 

On Thu, Sep 19, 2019 at 11:50 AM Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote:

It is small improvement we can do to avoid overhead of checking headers in each HTTP requests for proxies.

On Thu, Sep 19, 2019 at 4:12 PM Dave Page <dpage@pgadmin.org> wrote:

Sure, but is it going to make any real difference? I'd rather have it "just work" if possible.

This isn't like compression which we expect to use noticable CPU cycles.

On Thu, Sep 19, 2019 at 11:39 AM Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote:

Hi,

We need to make it configurable, we don't require middleware when we are running in Desktop mode.

On Thu, Sep 19, 2019 at 3:52 PM Dave Page <dpage@pgadmin.org> wrote:

On Thu, Sep 19, 2019 at 11:13 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi,

On Thu, Sep 19, 2019 at 3:28 PM Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Sep 19, 2019 at 6:29 AM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

Hi Hackers,

Attached is the patch to allow pgAdmin to work behind proxy with its in built server. I have used werkzeug fixer - https://werkzeug.palletsprojects.com/en/0.15.x/middleware/proxy_fix/#module-werkzeug.middleware.proxy_fix

Does this work with both X-Scheme and X-Forwarded-Proto headers as discussed?

The proxy fix work for all standard X-Forwarded-* headers. X-Scheme is not used anywhere, X-Forwarded-Proto is more robust.

Right, but our existing code uses X-Scheme (as per old advice since removed from the Flask website - see RM3149), and users have deployments that will be setup that way. We need to fall back to X-Scheme if it is present but X-Forwarded-Proto is not, to avoid breaking their installations.

 

I assume (as you haven't removed it) that it works in conjunction with the existing reverse proxy code?

Yes it should. 

Cool :-)

 

Thanks!

 

--

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

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

--

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

--

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

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

--

Thanks and Regards,

Aditya Toshniwal

Software Engineer | EnterpriseDB India | Pune

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