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 1eyg7f-0002j1-NX for pgadmin-hackers@arkaria.postgresql.org; Wed, 21 Mar 2018 15:57:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1eyg7c-0000Bs-R7 for pgadmin-hackers@arkaria.postgresql.org; Wed, 21 Mar 2018 15:57:52 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eyg7c-0000BV-AA for pgadmin-hackers@lists.postgresql.org; Wed, 21 Mar 2018 15:57:52 +0000 Received: from mail-io0-x242.google.com ([2607:f8b0:4001:c06::242]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eyg7X-0000GZ-W6 for pgadmin-hackers@postgresql.org; Wed, 21 Mar 2018 15:57:50 +0000 Received: by mail-io0-x242.google.com with SMTP id 141so7220111iou.12 for ; Wed, 21 Mar 2018 08:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=io1cxzfVoRhZU542UhXAUItQS950Ro4BrNmubBmzGck=; b=MQgwsahJnQz45CTbQuNbv75vYorRgnoiERjfNa6Pzr6GZrqzkhBQPLp8KZYhVDSOVE kjEd1CTnePMhaksCi6G9Cwjasx3uSQuzJUNLfcWU8sCjmxsAL7gOHW+fbocM5K0P463J RDgiLS7mUp48nR2gW4l4FMXk4e6lzm8FeXf4y0H1gPNQtAs4Ooff6tiPAj/jsnH/uGpD vl0I6PmIOZ1oXmVbcX4yLJTuS+vU5AiDedzI7SCcGjk5Hix/nLLmq7suKLX7q9JqyU2N 9o/sFy5IM4c9KUL+oHzYOWQ+yxu5DVblHWnRdIIDnlXRWWbSHQe5e+BMlRRTSsxIlOte tWZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=io1cxzfVoRhZU542UhXAUItQS950Ro4BrNmubBmzGck=; b=sTEB/zpF/a5r4ffUBuDNUZgkUSHahT/3Uut2f8acEa7fSPy02utbz8hJLesptryQcp n6AzYoL2XWrSu9CTTw8CiQa00KOh4RfDhCxEbSFX1mWkn11UUEmhKAOzmzkdUeWzMJP6 64t+5d0XuBIIE0VB+i0HvBjLG4u4QWQxxVpx4WQOma2v+QEoOWgx2vb3lzmUT+QcQmog WV9cJVwPCLe8231LqMC9owzv8TlU+seuLDs9MhXNG+3fCL+N/1YGc4aByhKUSv3YcX6V w3QAkwC2I6k8bMUcqP8gHbGEg+JFd/MARmrORx8O69RHFnfi/jxAjRgG9loijT2nBENr rE5Q== X-Gm-Message-State: AElRT7GPwG9j+CxJyem9t/s7gUAS6xGfwT35GPNjAgLwuoUfsc0S6ptC g7qUlpWTdA/7yfCQ5phb9rjdEJXaMz0sJWybW6NrYw== X-Google-Smtp-Source: AG47ELtHMpU1pzwjBzOWMtynAqUI8L6+GMp+ntVvmD22si23vlEWBc50+OPAfqS1dYT7QUlDeaT9MczMPmzj93CjJ38= X-Received: by 10.107.39.5 with SMTP id n5mr20822891ion.189.1521647866080; Wed, 21 Mar 2018 08:57:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joao De Almeida Pereira Date: Wed, 21 Mar 2018 15:57:35 +0000 Message-ID: Subject: Re: Experiencing issues To: Khushboo Vashi Cc: Murtuza Zabuawala , pgadmin-hackers Content-Type: multipart/alternative; boundary="001a11406f18881a440567ee4067" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --001a11406f18881a440567ee4067 Content-Type: text/plain; charset="UTF-8" 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 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> --001a11406f18881a440567ee4067 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry I did not understand what you said.
This configu= ration:

DEFAULT_SERVER =3D '0.0.0.0'
SESSION_COOKIE_DOM= AIN =3D DEFAULT_SERVER
COOKIE_DEFAULT_DOMAIN =3D DEFAULT_SERVER

I= f the application lives in the domain pgadmin.somedomain.com do I need to have in config_local:
DEFA= ULT_SERVER =3D '0.0.0.0'
SESSION_COOKIE_DOMAIN =3D 'pgadmin.somedomain.com'
COOKIE_DEFAULT_DOMAIN =3D '= pgadmin.somedomain.com'
?

Does t= his 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 whe= n we are developing doesn't make sense to not being able to use localho= st and 127.0.0.1=C2=A0

Thanks
Joao
On Wed, Mar 21, 2018 at 11:01 AM Khushboo Vashi &l= t;khus= hboo.vashi@enterprisedb.com> wrote:
On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira <j= dealmeidapereira@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 s= et as a DEFAULT_SERVER,=C2=A0 the 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@enterprisedb.com&= gt; wrote:
On Wed, Mar 21, 2018 at 8:10= PM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.io&= gt; wrote:
Ok Mur= tuza you are right,=C2=A0
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-domain= s.
On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <khushboo.vashi@enter= prisedb.com> wrote:


On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <jdealmeidapereira@pi= votal.io> wrote:
I tried= that but still nothing. When i check in the inspector for cookies I have n= one
Share your config_local file.
On Wed, Mar 21, 2018 at 10:30 AM M= urtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote:
Yes, that's cookie related iss= ue (RM#3197), To fix that I added below in my config_local.py and it starte= d working again,

DEFAULT_SERVER =3D '0= .0.0.0'=C2=A0
COOKIE_DEFAU= LT_DOMAIN =3D SESSION_COOKIE_DOMAIN =3D DEFAULT_SERVER

Clear your bro= wser cookies and server side sessions.


=
--
Regards,
Murtuza Zabuawala
EnterpriseDB:=C2=A0h= ttp://www.enterprisedb.com
The Enterprise PostgreSQL Company<= /font>


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<= /a>> wrote:


On 21 Mar = 2018 19:41, "Joao De Almeida Pereira" <jdealmeidapereira@pivotal.io= > wrote:
Hello Hack= ers,
Can anyone use the current master branch?
When I try to = open a server I get a 428. Is that only me?
<= /div>
May be because of cook= ie changes.=C2=A0
Check your config.py and config_lo= cal.py if you have done changes related to DEFAULT_SERVER in your config_lo= cal.py then you need to change other 2 cookie related variables also.
=

Thanks
Joao



<= /div> --001a11406f18881a440567ee4067--