On Fri, Mar 23, 2018 at 6:17 AM, Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote:
> Hi, > > On Wed, Mar 21, 2018 at 9:31 PM, Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Wed, Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira < >> jdealmeidapere...@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
