Re: Experiencing issues - Mailing list pgadmin-hackers

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 <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