Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ezJiZ-0001dS-JJ for pgadmin-hackers@arkaria.postgresql.org; Fri, 23 Mar 2018 10:14:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ezJiY-0007gI-Hu for pgadmin-hackers@arkaria.postgresql.org; Fri, 23 Mar 2018 10:14:38 +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.89) (envelope-from ) id 1ezJiY-0007g8-Ck for pgadmin-hackers@lists.postgresql.org; Fri, 23 Mar 2018 10:14:38 +0000 Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ezJiR-00039U-0d for pgadmin-hackers@postgresql.org; Fri, 23 Mar 2018 10:14:37 +0000 Received: by mail-wm0-x22e.google.com with SMTP id r82so2546874wme.0 for ; Fri, 23 Mar 2018 03:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TlM3/ukjTfE5ccepxnDWtxYjB2t059HytPH0VqPckXw=; b=c+9tUWID7zlKleRpkTuI0pncookpcLrVOGzFFMCXAgtNEP3G8ZVsEjSilnss28b+TB fGzTw0u+V7RGvJL/3VLW1kv0zJF6cnHjfddzwbd95ntFC+e5vNNnE9xBLiN71GLJhhb0 Hv4HmGIbfAz8uCOHTS0zIcLklTUL5l7mOzSAn9eoTKyy8IKx04F944QJN/BF7GdsgSeT zBKIp77WsCzFG0JcZViLwHQQJwNljkoFGs05FaUU8y9e0eN59fm7K5TVld9XHdjhGzQ/ EB50Fi5nJREmBu1JX6yEv65178POcMjyZQZpCbnhmYZAZSLXUYPF8ZXTuS01MgTQTAxL lhFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TlM3/ukjTfE5ccepxnDWtxYjB2t059HytPH0VqPckXw=; b=iu3otxrfq8PibIwwhy1eJxM6iHnz0nqzXPhSwHoE9PsoTSEKI2xr3SEMSnZmENw67Y RfPtMP2kl0f+ufYuREyD8QCC86yjlDPACSC2LTbUBaeGrfyOJj3gGUDa+7TdTVOUPkCu fu7w4wlCogebIsjYknY5cxFluBwuOmrQF8WvBziMG6Y/BdIyjyl+9UNOqsxxhttKvqK2 t07EnRol+YyIclS00Nym+/nfvgp5gCDPMJJTgChw46r6yHwSpe3zScCEi/txiDc8IyvP tG/q4BU7UqBYDHDEWlFqF7tAhaeyzWDHkBNk15Kb4/T340uHkyEZLj/PTHwgE2TVhnAx G/7A== X-Gm-Message-State: AElRT7FWRV6/9c7AA/BjiBkrNUIP2z7C23hwNOvtt3tBxdy/oOxocUgi Jp59yjU63+QTLxJ3VSeH0oQTGC2X4DvgGU3mePkQpQ== X-Google-Smtp-Source: AG47ELu3iNNUOlXizXnxbGWkG8F9e+J25S5mAyDu7FxlW5wYRMu7BCvxKKv1xdGUsXW3M7eSyiszfuVg5vHgSTo0aSo= X-Received: by 10.28.27.211 with SMTP id b202mr4211993wmb.154.1521800068475; Fri, 23 Mar 2018 03:14:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.69.220 with HTTP; Fri, 23 Mar 2018 03:14:27 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Fri, 23 Mar 2018 10:14:27 +0000 Message-ID: Subject: Re: Experiencing issues To: Khushboo Vashi Cc: Joao De Almeida Pereira , Murtuza Zabuawala , pgadmin-hackers Content-Type: multipart/alternative; boundary="001a114b3ab8804477056811b007" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --001a114b3ab8804477056811b007 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 23, 2018 at 6:17 AM, Khushboo Vashi < khushboo.vashi@enterprisedb.com> wrote: > Hi, > > On Wed, Mar 21, 2018 at 9:31 PM, Dave Page wrote: > >> >> >> On Wed, Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira < >> jdealmeidapereira@pivotal.io> wrote: >> >>> Sorry I did not understand what you said. >>> This configuration: >>> >>> DEFAULT_SERVER = '0.0.0.0' >>> SESSION_COOKIE_DOMAIN = DEFAULT_SERVER >>> COOKIE_DEFAULT_DOMAIN = DEFAULT_SERVER >>> >>> If the application lives in the domain pgadmin.somedomain.com do I need >>> to have in config_local: >>> DEFAULT_SERVER = '0.0.0.0' >>> SESSION_COOKIE_DOMAIN = 'pgadmin.somedomain.com' >>> COOKIE_DEFAULT_DOMAIN = 'pgadmin.somedomain.com' >>> ? >>> >>> Does this mean that if for some reason I have a second domain like >>> pgadmin.somedomain2.com that I want to use I cannot? >>> >>> The issue of 127.0.0.1 to localhost is very cumbersome, and somehow we >>> should be able to disable this, because when we are developing doesn't make >>> sense to not being able to use localhost and 127.0.0.1 >>> >> >> +1. I didn't realise we'd added this restriction when I tested the patch. >> >> Perhaps a better approach would be to leave the default cookie handling >> as it was, and just expose the domain and path via config options that the >> user can set if appropriate for their installation. >> >> Please find the attached updated patch as discussed. > > If one has to set cookie domain and path then below *config variables* > should be changed. > > COOKIE_DEFAULT_PATH > COOKIE_DEFAULT_DOMAIN > SESSION_COOKIE_DOMAIN > Thanks, applied. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --001a114b3ab8804477056811b007 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 23, 2018 at 6:17 AM, Khushboo Vashi <<= a href=3D"mailto:khushboo.vashi@enterprisedb.com" target=3D"_blank">khushbo= o.vashi@enterprisedb.com> wrote:
Hi,

On Wed, Mar 21, 2018 at 9:31 PM, Dave Page <= dpage@pgadmin.org> wrote:


On Wed, = Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira <jdealmeidaper= eira@pivotal.io> wrote:
Sorry I did not understand what you said.<= div>This configuration:

DEFAULT_SERVER =3D '0.0.0.0'
SE= SSION_COOKIE_DOMAIN =3D DEFAULT_SERVER
COOKIE_DEFAULT_DOMAIN =3D DEFAULT= _SERVER

If the application lives in the domain pgadmin.somedomain.com do I need= to have in config_local:
DEFAULT_SERVER =3D '0.0.0.0'
SESSI= ON_COOKIE_DOMAIN =3D 'pgadmin.somedomain.com'
COOKIE_DEFAULT_DOMAIN= =3D 'pgadm= in.somedomain.com'
?

Does this m= ean that if for some reason I have a second domain like pgadmin.somedomain2.com that = I want to use I cannot?

The issue of 127.0.0.1 to = localhost is very cumbersome, and somehow we should be able to disable this= , because when we are developing doesn't make sense to not being able t= o use localhost and 127.0.0.1=C2=A0

=
+1. I didn't realise we'd added this restriction when I= tested the patch.

Perhaps a better approach would= be to leave the default cookie handling as it was, and just expose the dom= ain and path via config options that the user can set if appropriate for th= eir installation.
<= div>
Please= find the attached updated patch as discussed.

If = one has to set cookie domain and path then below config variables sh= ould be changed.

COOKIE_DEFAULT_PATH
COOKIE_DEFAULT_DOMAIN
SESSION_COOKIE_DOMAIN=

Thanks, applied.
=C2=A0
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgs= nake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Co= mpany
--001a114b3ab8804477056811b007--