Re: Experiencing issues

On Fri, Mar 23, 2018 at 6:17 AM, Khushboo Vashi <
khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:

> Hi,
>
> On Wed, Mar 21, 2018 at 9:31 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Wed, Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira <
>> jdealmeidapereira(at)pivotal(dot)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