Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tgHIX-009EIo-HB for pgadmin-support@arkaria.postgresql.org; Fri, 07 Feb 2025 05:53:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tgHIW-00FU8D-Ds for pgadmin-support@arkaria.postgresql.org; Fri, 07 Feb 2025 05:53:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tgHIW-00FU7w-5J for pgadmin-support@lists.postgresql.org; Fri, 07 Feb 2025 05:53:04 +0000 Received: from mail-yw1-x1129.google.com ([2607:f8b0:4864:20::1129]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tgHIS-004HdJ-0w for pgadmin-support@lists.postgresql.org; Fri, 07 Feb 2025 05:53:02 +0000 Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-6f99efce804so10484707b3.0 for ; Thu, 06 Feb 2025 21:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1738907579; x=1739512379; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=q3bMokpF6Rpffn1d1vVzPa1CAUj4B/kVSTJNM6wpM3o=; b=N7AiMnfecueOP7GGEcs5SKLYPo0EZCHHGv2T/zh8B8zY/oLNsfdy1faULD9Z5nqbQ9 skRMZSf0dVLDjGxilqbH4MAnn0qN6n9k1+QC6DNcHEx206LUYZbo3rbRFf7G64mBSIdB wgZLz/Z2v1hHhARa1PpXnQ3rDjBu+zltnzP4vpcClONf4EX/oTPTPx2ddfPUzQDo0hyr g4GcQNk9g6RrMnDP34dTvY0mgiVdP2LRHdhE2FqGv2q+jlT6SOrwofn6VUKiCyoXuWPS A7xZEtk9B2f22dUfVchrAmSo0hXy5KFjYiD1w3095Stb0AvY790LrOU6orNuwdft9qVF vFoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738907579; x=1739512379; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=q3bMokpF6Rpffn1d1vVzPa1CAUj4B/kVSTJNM6wpM3o=; b=nyfHOfjDWLjF1uLXM9Vsz5byraTSmMNISAi3ZflX3wQfDfuPUftSDJWOQdttLU/Pz0 olZSAcl0z4HsDdiHVmRPkyBdkquCHcXyfMy64jBHES0PIo0PxQgI37m4DmW8tTTuVqeo CvBXkZJkit581/OJlAK80DxLK+I1jF34JEgbx3mxBBuQ1VfXlYOsh8TvM2KSv4EAL5E/ QX5yZXO4n1Z/RnkPs/LGvECO2+3iyyfOQ8g0sktKAMTEXnLJaimcUN5uTOACCQ9dxbzx kMmvFxZzCAzFnOourMhMAUG5PVFYlhHeKJqeeh/kPDFBVOZ67WYKDOmfuSum7JLanm3A x3Mw== X-Gm-Message-State: AOJu0Yy3lZgcZ0blUfvMc8tPwCMoUzRo+/JW/2kivM9cxmGYBjPsiSw1 VWNCsFRYYK7PTRPgHkUrAX8vCTDt6uLmPWCkDLZ/cGur8Tn65+K2Tm+5n1W4vhebFx50QyXu0Af kl1OF/ZxFb9U7mwJ3N8NtlFb4/SJ/eypf65aD X-Gm-Gg: ASbGncvLqSIVVggqSMotn9hDEBx1FrkD3Nsx4g+S7ve4lZKX7b7QF4eIamnP3OYkA+p tsxf/7w+BNVQEz+LlMjHRTf3NWh4vGD4hsZXg0YbeGsVMZCXVRp3/zoW2D7DEQGliGtJydhUgV8 tvPkvR+4EgfGMsvwqWDuinC71tFq6BSA== X-Google-Smtp-Source: AGHT+IHj/XlccOY384Qs9hCijJleK7AcNK65yVFvIQJSd9GegWk5HJyrtLGxu7VAIbtVVzkiL6rl7DexzrlrJNw0xCA= X-Received: by 2002:a05:690c:640c:b0:6f9:acb3:4434 with SMTP id 00721157ae682-6f9b287a308mr18627217b3.19.1738907578828; Thu, 06 Feb 2025 21:52:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yogesh Mahajan Date: Fri, 7 Feb 2025 11:22:22 +0530 X-Gm-Features: AWEUYZnsmz_Ee0ik7q7jcTjPsRJd0C0gVaXwC9V3al5lm-EP0I7ezD1aGIeE3pM Message-ID: Subject: Re: Issue running pgAdmin behind a reserve proxy To: Eamon Doyle Cc: pgadmin-support@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000088a826062d86f8bc" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000088a826062d86f8bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, If everything is working with Apache TLS port, then something is wrong with the Cloudfare proxy. Can you please share details for Cloudfare proxy configuration? Thanks, Yogesh Mahajan EnterpriseDB On Fri, Feb 7, 2025 at 12:57=E2=80=AFAM Eamon Doyle wrote: > Hi all, > > tl;dr, I'm running pgAdmin on a nonstandard ssl port and it breaks after > first use. > > Long version: I am currently running pgAdmin4 in server mode using the > standard Apache configuration included with Debian 11 (installed via the > pgAdmin instructions, pgadmin4-web and pgadmin4-server packages > installed). The apache instance serves pgadmin over ssl on port 8443 > (running a different tool on port 443) and we have a cloudflare reverse > proxy in front of that that proxies on port 443 for a particular subdomai= n > to port 8443 on our backend server. The first time I go to > https://example.com/pgadmin4 and log in, pgAdmin loads as expected. > However, if I log out and try to log back in, I briefly receive the pgAdm= in > loading animation followed by a blank white screen rather than the > browser. If I watch the network tab of Chrome, I see 401 errors on the > following requests: > - pgadmin4/preferences/get_all > - pgadmin4/browser/check_corrupted_db_file > - pgadmin4/misc/bgprocess/ > > Looking at the logs, I see the 401 errors being generated in the Apache > logs on my backend server. Restarting the web server has no effect. If= I > then replace https://example.com/pgadmin4 with > https://example.com:8443/pgadmin4 (ie I add the port of my Apache TLS > port rather than the expected 443 that the Cloudflare reverse proxy > expects) in my browser, pgAdmin will load again and work as expected. Du= e > to the security limitations of our organization, I cannot directly connec= t > to the backend VM on port 8443, only through the Cloudflare reverse proxy= . > > This seems like a bug with pgAdmin, but I'm wondering if anyone knows > whether or not I missed a configuration option that would solve this. > > My Apache config is as follows: > > >> SSLEngine on >> SSLCertificateFile /secrets/pgadmin-cert.pem >> SSLCertificateKeyFile /secrets/pgadmin-key.pem >> >> # enable HTTP/2, if available >> Protocols h2 http/1.1 >> >> >> # modern configuration >> SSLProtocol -all +TLSv1.3 >> SSLOpenSSLConfCmd Curves X25519:prime256v1:secp384r1 >> SSLHonorCipherOrder off >> SSLSessionTickets off > > > Apache pgAdmin config > > WSGIDaemonProcess pgadmin processes=3D1 threads=3D25 >> python-home=3D/usr/pgadmin4/venv >> WSGIScriptAlias /pgadmin4 /usr/pgadmin4/web/pgAdmin4.wsgi >> >> >> WSGIProcessGroup pgadmin >> WSGIApplicationGroup %{GLOBAL} >> Require all granted >> > > > > Any ideas? > > Thanks > Eamon > --00000000000088a826062d86f8bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

If everything=C2=A0is working with Apache=C2=A0TLS port, then something is= wrong=C2=A0with the Cloudfare proxy.
Can you please share = details for Cloudfare=C2=A0proxy configuration?

Thanks,
Yogesh Mahajan
EnterpriseDB
<= /div>

On Fri, Feb 7, 2025 at 12:57=E2=80=AFAM Eamo= n Doyle <eamon@turnaroundf= actor.com> wrote:
Hi al= l,

tl;dr, I'm running pgAdmin on a nonstandard ssl p= ort and it breaks after first use.

Long version: I= am currently running pgAdmin4 in server mode using the standard Apache con= figuration included with Debian 11 (installed via the pgAdmin instructions,= =C2=A0pgadmin4-web and pgadmin4-server packages installed).=C2=A0 The apach= e instance serves pgadmin over ssl on port 8443 (running a different tool o= n port 443) and we have a cloudflare reverse proxy in front of that that pr= oxies on port 443 for a particular subdomain to=C2=A0port 8443 on our backe= nd server.=C2=A0 The first time I go to https://example.com/pgadmin4 and log in, pgAdmi= n loads as expected.=C2=A0 However, if I log out and try to log back in, I = briefly receive the pgAdmin loading animation followed by a blank white scr= een rather than the browser.=C2=A0 If I watch the network tab of Chrome, I = see 401 errors on the following requests:
= =C2=A0- pgadmin4/preferences/get_all
=C2=A0- pgadmin4/browser/check_corrupted_db_file
=C2=A0- pgadmin4/mis= c/bgprocess/

Looking at the logs, I see the= 401 errors being generated in the Apache logs on my backend server.=C2=A0 = =C2=A0Restarting the web server has no effect.=C2=A0 If I then replace https://example.com/= pgadmin4 with https://example.com:8443/pgadmin4 (ie I add the port of my Apach= e TLS port rather than the expected 443 that the Cloudflare reverse proxy e= xpects) in my browser, pgAdmin will load again and work as expected.=C2=A0 = Due to the security limitations of our organization, I cannot directly conn= ect to the backend VM on port 8443, only through the Cloudflare reverse pro= xy.=C2=A0

This seems like a bug with pgAdmin, but I'm wondering = if anyone knows whether or not I missed a configuration option that would s= olve this.

My Apache config is as follows:

= <VirtualHost *:8443>
=C2=A0 =C2=A0 SSLEng= ine on
=C2=A0 =C2=A0 SSLCertificateFile =C2=A0 =C2=A0 =C2=A0/secrets/pga= dmin-cert.pem
=C2=A0 =C2=A0 SSLCertificateKeyFile =C2=A0 /secrets/pgadmi= n-key.pem

=C2=A0 =C2=A0 # enable HTTP/2, if available
=C2=A0 =C2= =A0 Protocols h2 http/1.1
</VirtualHost>

# modern configura= tion
SSLProtocol =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -all +TLSv1.3=
SSLOpenSSLConfCmd =C2=A0 =C2=A0 =C2=A0 Curves X25519:prime256v1:secp384= r1
SSLHonorCipherOrder =C2=A0 =C2=A0 off
SSLSessionTickets =C2=A0 =C2= =A0 =C2=A0 off

Apache pgAdmin config

WSGIDaemonProcess pgadmin processes=3D1 th= reads=3D25 python-home=3D/usr/pgadmin4/venv
WSGIScriptAlias /pgadmin4 /u= sr/pgadmin4/web/pgAdmin4.wsgi

<Directory /usr/pgadmin4/web/>=C2=A0 =C2=A0 WSGIProcessGroup pgadmin
=C2=A0 =C2=A0 WSGIApplicationGr= oup %{GLOBAL}
=C2=A0 =C2=A0 Require all granted
</Directory>


Any ideas?

Thanks
Eamon
--00000000000088a826062d86f8bc--