Mantaining session open for authenticated users

[Chris]

Hi, there is a way to keep the session open forever  for authenticated users untile they click in logout button ?

I have a dashboard with authentication but it closes the session after x time, the cookie session in browser is marked to expire at session, so the session should be open until i click logout, but is not happening.

Cheers!

Chris.

[Jim Steil]

You can set the session timeout in common.py

auth.param.login_expiration_time = 60 * 60 * 24 * 30 # expire 30 days

However, there is currently a bug that is preventing this from working.  I have submitted a PR to fix it.  So, until the PR is merged I'm not sure it will work.  But rest assured, it is being addressed.

-Jim

[Massimo]

I do not think I have seen this PR. Was it merged already?

[Jim Steil]

It is buried in PR #369

Not sure what I did, but all my commits since that PR have shown up under that PR for me.

-Jim

[tyoc213]

Most probably commiting to the same branch, if you have made another for the issue 369, or all are being packed in your master (I mean all new commits on a branch taht will be merged are taked as part of the PR).

[Jim Steil]

Yes, there are 4 commits in master. Do I need to change that or are you able to review all of them together?

-Jim

[tyoc213]

Im not the one checking PR, but what can I suguest is that when you do a PR, start with doing a new branch, so when you send your PR and start adding new commits based on review all of them go to that branch and it will automatically update the PR and in this way, you keep clean master (so that you can sync if needed).

[Jim Steil]

Thanks for the advice.  I did break that PR back down in to 4 separate ones using different branches as you recommended.  I'll be doing all my PRs from separate branches from now on.

-Jim

[tyoc213]

Yeah!, just remember one branch per PR and you can attach extra commits afterwards to each branch/PR

Happy xmas ppl!

--
You received this message because you are subscribed to a topic in the Google Groups "py4web" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/py4web/S4YI6LEztTY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to py4web+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/143f6384-b02b-4d65-8449-86f436f5f6f9n%40googlegroups.com.

[Larry_W]

I'm not sure what the status of this issue is, but I assume that it's closed. I'm testing it now in my application. 

It seems like this parameter should be set from settings.py rather than hacking the common.py file.

[Larry_W]

I changed the parameter in common.py, but it doesn't seem to be working, at least not on a mobile device with chrome browser. Is there a way to make this work? Is it still in an open issue?

[Kevin Keller]

Can you show us the relevant lines in your common.py please. Should be around line 86. 

And if you can the py4web JWT cookie of your app?

Thanks!

You received this message because you are subscribed to the Google Groups "py4web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to py4web+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/9d18074a-f661-494e-bcf1-37e9c158590fn%40googlegroups.com.

[Larry_W]

OK, I signed out on all browsers and then signed back in again. I'll watch and see if it respects the expiration time now. 

This is what I have in common.py. This was started yesterday:

auth.param.login_expiration_time = 604800

The decoded client-side JWT token looks like this:

{'uuid': 'xxxxxxx',
'secure': True,
 'recent_activity': 1620930448,
 'timestamp': 1620930448.8622918,
 'user': {'id': 1},
 'recent_timestamp': '2021-05-13T18:27:28.832565'}

The only timestamps I see are for my current time. I would expect that the expiration time would be sometime next Wednesday.

[Larry_W]

It's still expiring in < 24 hours on my mobile browser. I'm not sure how long the sessions last on my desktop browser.

[Jacinto Parga]

I have set session expiration in common.py but something is wrong the Expires On field

 session = Session(
        secret=settings.SESSION_SECRET_KEY, storage=DBStore(db), expiration=7200
    )

There is more than two hours 2042-01-02

[Massimo]

I cannot say for sure something is wrong. The 2hrs do not start when the session is created. It starts when it last used.

Please double check it and if indeed there is a problem I will investigate further.

Massimo

[Jacinto Parga]

Thanks Massimo, you're right I don't think it's wrong. 

I think there is a problem with the server deployment (nginx in ubuntu) or something like that because I had found a strange behaviour with _dashboard similiar to the session issue that I saw. It is browser-dependent, if I run _dashboard in a private browser window it works perfectly, but  if I run it in a browser in which I ran it previously, it doesn't load the apps neither the tickets or databases.

Any hint about what happens?

Thanks!

[Jacinto Parga]

It happens in localhost too, so it is not a server misconfiguration:

This is the error

ERROR:root:Traceback (most recent call last):
  File "/home/jacinto/.pyenv/versions/py4web382/lib/python3.8/site-packages/py4web/core.py", line 935, in wrapper
    ret = func(*func_args, **func_kwargs)
  File "/home/jacinto/.pyenv/versions/py4web382/lib/python3.8/site-packages/py4web/core.py", line 920, in wrapper
    raise context["exception"]
  File "/home/jacinto/.pyenv/versions/py4web382/lib/python3.8/site-packages/py4web/core.py", line 897, in wrapper
    call(fixture.on_request, context)
  File "/home/jacinto/.pyenv/versions/py4web382/lib/python3.8/site-packages/py4web/core.py", line 882, in call
    return f(context)
TypeError: on_request() takes 1 positional argument but 2 were given

[Massimo]

Looks like to me somewhere there is a custom fixture incorrectly defined and the on_request method takes one argument instead of (self, context).

maybe edit the line call(fixture.on_request, context) in py4web.py and try log what app and what fixture it is.

[Jacinto Parga]

I find the error, it was caused by a COOKIE:

[Jacinto Parga]

The problem with this cookie is explained here: https://support.google.com/admanager/thread/98343511/bug-funding-choices-cookie-uses-unencoded-characters-that-can-crash-older-web-servers?hl=en

I don't know it something could be done from py4web code.

[Larry_W]

I don't understand the implications of this. Is it specific to py4web? If not, why is not happening in other implementations? Does anybody have an idea how to fix it or work around it?

[Jacinto Parga]

If you are talking about my previous
answer the explanation is here: https://groups.google.com/g/py4web/c/feEOjmFSN10

[Larry Woodring]

I missed the part about AdSense. I'm having a problem with expiration on mobile devices, and I'm not using AdSense.

To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/da3576c5-0e53-477e-a00f-d7491056c21dn%40googlegroups.com.

[Massimo]

One problem could be the size of the cookies. By default they store the whole session. So if you put too much stuff in there, the device may not handle it. You should consider server-side session. But I am not sure this is the problem. Is there any pattern in the logout?

[Larry_W]

I tried using cookies and now I have SESSION_TYPE = "database" with SESSION_EXPIRATION = 604800

This works ok using Chrome on a desktop, but with Chrome on a mobile device, the session times out after about 2 hours or less.