Re: pgadmin4 exception: session['_id'] not in self.managers

Thanks, applied.

On Tue, Oct 10, 2017 at 8:13 AM, Harshal Dhumal <
harshal(dot)dhumal(at)enterprisedb(dot)com> wrote:

> Hi Dave,
>
> Please find attached patch (old RM2713).
> Also for server group and server module login required checks were missing,
> I have added them in same patch
>
> --
> *Harshal Dhumal*
> *Sr. Software Engineer*
>
> EnterpriseDB India: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> On Tue, Oct 10, 2017 at 11:39 AM, Harshal Dhumal <
> harshal(dot)dhumal(at)enterprisedb(dot)com> wrote:
>
>> Hi David,
>>
>> Thanks for you input. Session was not invalidated (otherwise execution
>> would not have reached to connection manager); Only value of '_id' was
>> changed for session.
>>
>> If we look at code
>> <https://github.com/maxcountryman/flask-login/blob/master/flask_login/utils.py#L333>
>> how '_id' is generated then we can see it uses remote address and user-agent
>> to generate it. I thing we should use another session identifier (sid -
>> session id) to map user connection from connection manager.
>>
>> --
>> *Harshal Dhumal*
>> *Sr. Software Engineer*
>>
>> EnterpriseDB India: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>> On Mon, Oct 9, 2017 at 10:18 PM, David Gilman <davidgilman1(at)gmail(dot)com>
>> wrote:
>>
>>> You can probably stand down on this one. The issue was that my PC was
>>> switching back and forth between IPv4 and IPv6 for whatever reason and when
>>> that happened the cookie and my session would get invalidated. Maybe it is
>>> worth making code changes so you don't get Python tracebacks dumped to the
>>> error logs every time this happens but I have been able to resolve the
>>> issue by turning off IPv6 temporarily. That was an interesting one to
>>> troubleshoot!
>>>
>>> On Mon, Oct 9, 2017 at 4:30 AM, Harshal Dhumal <
>>> harshal(dot)dhumal(at)enterprisedb(dot)com> wrote:
>>>
>>>> sure Dave
>>>>
>>>> --
>>>> *Harshal Dhumal*
>>>> *Sr. Software Engineer*
>>>>
>>>> EnterpriseDB India: http://www.enterprisedb.com
>>>> The Enterprise PostgreSQL Company
>>>>
>>>> On Mon, Oct 9, 2017 at 1:16 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>> Harshal, can you help with this please?
>>>>>
>>>>> On Sun, Oct 8, 2017 at 12:39 AM, David Gilman <davidgilman1(at)gmail(dot)com>
>>>>> wrote:
>>>>>
>>>>>> I'm trying out pgadmin4 v2.0 for the first time. It seems that after
>>>>>> only a few minutes (maybe even less than five) my pgadmin4 session will get
>>>>>> logged out and I'll need to log in again and reopen everything from
>>>>>> scratch. This exception is thrown in the mod_wsgi logs:
>>>>>>
>>>>>> mod_wsgi (pid=5965): Exception occurred processing WSGI script
>>>>>> '/home/pgadmin/venv/lib/python2.7/site-packages/pgadmin4/pgA
>>>>>> dmin4.wsgi'.
>>>>>> Traceback (most recent call last):
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask/app.py",
>>>>>> line 2000, in __call__
>>>>>> return self.wsgi_app(environ, start_response)
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask/app.py",
>>>>>> line 1991, in wsgi_app
>>>>>> response = self.make_response(self.handle_exception(e))
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask/app.py",
>>>>>> line 1567, in handle_exception
>>>>>> reraise(exc_type, exc_value, tb)
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask/app.py",
>>>>>> line 1988, in wsgi_app
>>>>>> response = self.full_dispatch_request()
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask/app.py",
>>>>>> line 1641, in full_dispatch_request
>>>>>> rv = self.handle_user_exception(e)
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask/app.py",
>>>>>> line 1544, in handle_user_exception
>>>>>> reraise(exc_type, exc_value, tb)
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask/app.py",
>>>>>> line 1639, in full_dispatch_request
>>>>>> rv = self.dispatch_request()
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask/app.py",
>>>>>> line 1625, in dispatch_request
>>>>>> return self.view_functions[rule.endpoint](**req.view_args)
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/flask_login.py",
>>>>>> line 792, in decorated_view
>>>>>> return func(*args, **kwargs)
>>>>>> File "/home/pgadmin/venv/lib/python2.7/site-packages/pgadmin4/pgadmin/dashboard/__init__.py",
>>>>>> line 169, in wrap
>>>>>> kwargs['sid']
>>>>>> File "/home/pgadmin/venv/lib/python2.7/site-packages/pgadmin4/pga
>>>>>> dmin/utils/driver/psycopg2/__init__.py", line 2000, in
>>>>>> connection_manager
>>>>>> if session['_id'] not in self.managers:
>>>>>> File "/home/pgadmin/venv/local/lib/python2.7/site-packages/werkzeug/local.py",
>>>>>> line 368, in <lambda>
>>>>>> __getitem__ = lambda x, i: x._get_current_object()[i]
>>>>>> KeyError: '_id'
>>>>>>
>>>>>> My setup:
>>>>>> pgadmin4 v2.0 . The configuration is all defaults except
>>>>>> for LOG_FILE/SQLITE_PATH/SESSION_DB_PATH/STORAGE_DIR. That
>>>>>> means MAX_SESSION_IDLE_TIME is at its default of 60 (minutes).
>>>>>> pgadmin4 is in server mode with mod_wsgi as a host.
>>>>>> PostgreSQL 9.4.14 - from the postgres apt repository. No changes
>>>>>> made to timeouts or anything in the postgresql.conf , it's all defaults.
>>>>>> Python 2.7
>>>>>> psycopg2 2.7.3.1
>>>>>>
>>>>>> I can confirm that the apache process hosting pgadmin4 is running
>>>>>> under the right UNIX user account and that it seems to have good
>>>>>> access/permissions to its scratch files on disk. I see updates being made
>>>>>> to pgadmin4.db and the sessions directory.
>>>>>>
>>>>>> --
>>>>>> David Gilman
>>>>>> :DG<
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> Blog: http://pgsnake.blogspot.com
>>>>> Twitter: @pgsnake
>>>>>
>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> David Gilman
>>> :DG<
>>>
>>
>>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company