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 1eygB7-00031J-HA for pgadmin-hackers@arkaria.postgresql.org; Wed, 21 Mar 2018 16:01:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1eygB6-0000rX-7H for pgadmin-hackers@arkaria.postgresql.org; Wed, 21 Mar 2018 16:01:28 +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 1eygB6-0000rN-0q for pgadmin-hackers@lists.postgresql.org; Wed, 21 Mar 2018 16:01:28 +0000 Received: from mail-wr0-x22b.google.com ([2a00:1450:400c:c0c::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eygAx-0000wX-RS for pgadmin-hackers@postgresql.org; Wed, 21 Mar 2018 16:01:27 +0000 Received: by mail-wr0-x22b.google.com with SMTP id f14so5723712wre.8 for ; Wed, 21 Mar 2018 09:01:19 -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=nkfNq5VUj5hE3PnhB8eiaq3PGv96CzSYyzQ+fRaI/JQ=; b=GXEMGoyFLZYpv/daDkJ7z/P0TX7BxUt/z8DEatx/wXf9AOtsKOannvKfr8ESIQclW5 sTwKwwetU49SCOEV+yQ0i976bRPhIzLpCf5S5zmo+QL93ISMyL4Gx0NiBU96L+dp8VLs +fIOIKdlx+9OWlJndXPW9UCC0m8pX4sOzCJFWUyYQj3Km1moobbF/l3o8RxmXqilcszp ksWEr0LWm3Q26IsgiExf7E8lyKpf5bXdEVLCouXdZcELba42KQ4bIE/iYaMPFhmP4gBB OfUCjxY8n1p+F+ehQUQG6gfO/mub86UIPmbsm87QKkRIlCZcVbvPpctB1sQCzyMbYE0+ ENTg== 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=nkfNq5VUj5hE3PnhB8eiaq3PGv96CzSYyzQ+fRaI/JQ=; b=Aa7Q2xgcV2+Pxqs8a3PUzh/kF73qPFo/gTQw9W2SJ0j2OTBjdJiswfJU+BeLmQe36f 8LELLaqByLIfCV7YMpqsFnVZLDyqYjrekMim4XxmPZ6+FuuxQyUa/BxtMJchoFwHb8xm aBK2PGSO+SUPYl0t3mTOW1oA5mOGnEfWKlRqXnivpzwcqU6cKYc40guhX9k7DH+3vhBe +wf++par5IAMeGbzLlw0lcGhvmF9ZAHtgXHB1FmNChtBZ1hOmF/5cXQfgnnji2wlquwg jp9Zx428FkYqlHd4CD0iSFaqBuWIdIcHc688dT1VWZqVHx0evVSO3vwQJomx+TRXAWIL 0mPQ== X-Gm-Message-State: AElRT7EC+kCXVsXT4ryqEpDON8iF8PFIZY0Mgj21GET42k5syTH0mOde QEWtSsnQwp2Z2OO+2rihDhF+Jd/tKTgJr8A3coXWxg== X-Google-Smtp-Source: AG47ELsK0ynPH8nU+BUxlMprbFmO4KIN77H8tL2+brFO90sZAhWqv63UDSwnPYIeqQC0VEE/ZYEIZYgPODNnqUx9blQ= X-Received: by 10.223.195.124 with SMTP id e57mr15798474wrg.135.1521648074986; Wed, 21 Mar 2018 09:01:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.69.220 with HTTP; Wed, 21 Mar 2018 09:01:14 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Wed, 21 Mar 2018 16:01:14 +0000 Message-ID: Subject: Re: Experiencing issues To: Joao De Almeida Pereira Cc: Khushboo Vashi , Murtuza Zabuawala , pgadmin-hackers Content-Type: multipart/alternative; boundary="f403045c4e22fbc7120567ee4c43" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --f403045c4e22fbc7120567ee4c43 Content-Type: text/plain; charset="UTF-8" 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. > > Thanks > Joao > > On Wed, Mar 21, 2018 at 11:01 AM Khushboo Vashi < > khushboo.vashi@enterprisedb.com> wrote: > >> On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira < >> jdealmeidapereira@pivotal.io> wrote: >> >>> So what you are saying is that if I have a server, I need to do >>> DEFAULT_SERVER=0.0.0.0 and then set the real domain on the COOKIE domain? >>> >>> No I am saying, whatever you set as a DEFAULT_SERVER, the app can be >> accessible with that server. >> As, we have explicitly set DOMAIN in the cookie setting. >> >>> On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi < >>> khushboo.vashi@enterprisedb.com> wrote: >>> >>>> On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira < >>>> jdealmeidapereira@pivotal.io> wrote: >>>> >>>>> Ok Murtuza you are right, >>>>> Now my question is I have the default server to 127.0.0.1 and I want >>>>> to access it using localhost as well. How can I do this? >>>>> >>>>> No, you can't. >>>> Domain based cookie will work for that domain and it's sub-domains. >>>> >>>>> On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi < >>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 21 Mar 2018 20:01, "Joao De Almeida Pereira" < >>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>> >>>>>> I tried that but still nothing. When i check in the inspector for >>>>>> cookies I have none >>>>>> >>>>>> Share your config_local file. >>>>>> >>>>>> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala < >>>>>> murtuza.zabuawala@enterprisedb.com> wrote: >>>>>> >>>>>>> Yes, that's cookie related issue (RM#3197), To fix that I added >>>>>>> below in my config_local.py and it started working again, >>>>>>> >>>>>>> DEFAULT_SERVER = '0.0.0.0' >>>>>>> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER >>>>>>> >>>>>>> Clear your browser cookies and server side sessions. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Murtuza Zabuawala >>>>>>> EnterpriseDB: http://www.enterprisedb.com >>>>>>> The Enterprise PostgreSQL Company >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira < >>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>> >>>>>>>> Where can I find information about that? >>>>>>>> >>>>>>>> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi < >>>>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" < >>>>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>>>> >>>>>>>>> Hello Hackers, >>>>>>>>> Can anyone use the current master branch? >>>>>>>>> When I try to open a server I get a 428. Is that only me? >>>>>>>>> >>>>>>>>> May be because of cookie changes. >>>>>>>>> Check your config.py and config_local.py if you have done changes >>>>>>>>> related to DEFAULT_SERVER in your config_local.py then you need to change >>>>>>>>> other 2 cookie related variables also. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Joao >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --f403045c4e22fbc7120567ee4c43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

DEFAULT_SERVER =3D '0.0.0.0'
SESSION_C= OOKIE_DOMAIN =3D DEFAULT_SERVER
COOKIE_DEFAULT_DOMAIN =3D DEFAULT_SERVER=

If the application lives in the domain pgadmin.somedomain.com do I need to hav= e in config_local:
DEFAULT_SERVER =3D '0.0.0.0'
SESSION_COOK= IE_DOMAIN =3D 'pgadmin.somedomain.com'
COOKIE_DEFAULT_DOMAIN =3D = 9;pgadmin.somed= omain.com'
?

Does this mean that= if for some reason I have a second domain like pgadmin.somedomain2.com that I want t= o use I cannot?

The issue of 127.0.0.1 to localhos= t is very cumbersome, and somehow we should be able to disable this, becaus= e when we are developing doesn't make sense to not being able to use lo= calhost and 127.0.0.1=C2=A0

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

Perhaps a better approach would be to leave th= e default cookie handling as it was, and just expose the domain and path vi= a config options that the user can set if appropriate for their installatio= n.

=C2=A0

Thanks
Joao

On Wed, Mar 21, 2018 at 11:01 AM Khushboo Vashi <khushboo.v= ashi@enterprisedb.com> wrote:
On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira <jd= ealmeidapereira@pivotal.io> wrote:
So what you are saying is that if I have a server,= I need to do DEFAULT_SERVER=3D0.0.0.0 and then set the real domain on the = COOKIE domain?

=
No I am saying, whatever you set as a DEFAULT_SERVER,=C2=A0 th= e app can be accessible with that server.
As, we have explicitly = set=C2=A0 DOMAIN in the cookie setting.
On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi <khushboo.vashi@enterprise= db.com> wrote:
On Wed, Mar = 21, 2018 at 8:10 PM, Joao De Almeida Pereira <jdealmeidapereir= a@pivotal.io> wrote:
Ok Murtuza you are right,=C2=A0
Now my question is I have th= e default server to 127.0.0.1 and I want to access it using localhost as we= ll. How can I do this?

=
No, you can't.
Domain b= ased cookie will work for that domain and it's sub-domains.
=
On Wed, Mar 21, 2018 at 10:39 AM Khu= shboo Vashi <khushboo.vashi@enterprisedb.com> wrote:


On 21 Mar 2018 20:01, "Joao De = Almeida Pereira" <jdealmeidapereira@pivotal.io> wrote:
I tried that but still = nothing. When i check in the inspector for cookies I have none
Share you= r config_local file.
On Wed,= Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <murtuza.zabuawala@enterpr= isedb.com> wrote:
= Yes, that's cookie related issue (RM#3197), To fix that I added below i= n my config_local.py and it started working again,

DEFAULT_SERVER =3D '0.0.0.0'=C2=A0
COOKIE_DEFAULT_DOMAIN =3D SESSION_COOKIE_DOMAIN = =3D DEFAULT_SERVER

Clear your browser cookies and server side session= s.

--
Re= gards,
Murtuza Zabuawala
EnterpriseDB:=C2=A0http://www.ent= erprisedb.com
The Enterprise PostgreSQL Company
<= /div>
<= br>

On Wed, Mar 21, 2018 at 7:55 PM, Joao De Alm= eida Pereira <jdealmeidapereira@pivotal.io> wrote= :
Where can I find infor= mation about that?

On = Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:


On 21= Mar 2018 19:41, "Joao De Almeida Pereira" <jdealmeidapereira@pivotal.i= o> wrote:
=
Hello Hackers,
Can anyone use the current master branc= h?
When I try to open a server I get a 428. Is that only me?
May be because of cookie changes.=C2=A0
Check y= our config.py and config_local.py if you have done changes related to DEFAU= LT_SERVER in your config_local.py then you need to change other 2 cookie re= lated variables also.

Thanks
J= oao



<= /div>


--
Dave Page
Blog: = http://pgsnake.bl= ogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com<= br>The Enterprise PostgreSQL Company
--f403045c4e22fbc7120567ee4c43--