Thank you Anthony as always very clear explanations. :)
Richard On Wed, Apr 4, 2018 at 5:19 PM, Anthony <abasta...@gmail.com> wrote: > This behavior is controlled by the following auth.settings: > > renew_session_onlogin (default=True) > keep_session_onlogin (default=True) > renew_session_onlogout (default=True) > keep_session_onlogout (default=False) > > Renewing the session causes a new session ID and therefore file to be > created -- that explains why the new files are created on both login and > logout. > > Keeping the session means that the content of the session is retained when > the session is renewed. If keep is set to False, then the old file is > deleted when the session is renewed (but the old file is not deleted when > the keep is set to True). That explains why the old file is deleted on > logout but not on login (given the above noted defaults). I believe this > should probably be considered a bug -- the old file should be deleted in > either case (the problem is that in the code, the file deletion happens in > the same method that clears the session data, and of course that method is > not called when the session is kept). Feel free to file a Github issue > about this and refer back to this thread. > > For now, if you don't need to retain any session data upon login (i.e., > session data stored before login does not need to remain available once > logged in), then you can set auth.settings.keep_session_onlogin=False, > and the old session file will be deleted upon login (so, at any given time, > there will be only one session file for a given user session). > > Alternatively, of course you can set either or both of the renew_session_* > settings to False, and no additional session files will be created on login > or logout. > > Anthony > > On Tuesday, April 3, 2018 at 1:01:21 PM UTC-4, AlighaThor wrote: >> >> Hi. I'm experimenting for the first time (but I'm quite a bit old using >> this amazing framework :)) storing sessions in the DB instead the >> filesystem, as I always did. I'm monitoring those two behaviours and >> somehow it feels (at least for me) that the DB session handling is far away >> more efficient/manteinable than the filesystem session handling. >> >> Look at this: >> >> *When using the filesystem handling:* >> >> 1 - I go to my login form. A session file is created (for the form key I >> suposse.). >> >> >> >> <https://lh3.googleusercontent.com/-XuyY5NjIj84/WsOrJi80XoI/AAAAAAAAJNY/AeC-np_I7nwI5nEmROgdityYm1iT9C1MwCLcBGAs/s1600/Selecci%25C3%25B3n_001.png> >> >> >> 2 - Then I finally log in. Another session file is created. >> >> >> <https://lh3.googleusercontent.com/-X8v1EkS5fVU/WsOsCi-9ydI/AAAAAAAAJNg/liAouwwWmGwn3HGJMVpm5fsKHD_b9mhAwCLcBGAs/s1600/Selecci%25C3%25B3n_002.png> >> >> >> 3 - Next I log out. A new file is created or somehow "moved" or "deleted" >> from the directory "165". >> >> >> <https://lh3.googleusercontent.com/-ykV8jYicHYY/WsOtBvqRv2I/AAAAAAAAJNs/pX1tGT2RkOIWvPDKcImOXh3EQmd_oX-6ACLcBGAs/s1600/Selecci%25C3%25B3n_003.png> >> >> 4 - Next I log in again. This time my form action did not create any new >> file, but a new one after the log in. >> >> >> <https://lh3.googleusercontent.com/-UF1sObfrZYc/WsOtq17PO9I/AAAAAAAAJN0/55bIXzkhQUEMIKdPiOuFte8mGhMA6xwSwCLcBGAs/s1600/Selecci%25C3%25B3n_004.png> >> >> >> 5 - Everything is repeated again. I log out, then a new file is created. >> >> >> *Now let's see the DB behaviour:* >> >> >> 1 - Login form. A session record is created. >> >> >> >> <https://lh3.googleusercontent.com/-QoMpV4-yUjg/WsOvRbUVP6I/AAAAAAAAJOA/M3fiTKl54AkqYjRkdvTT9vvCLuDBoZa6QCLcBGAs/s1600/Selecci%25C3%25B3n_005.png> >> >> >> 2 - I log in. The same record remains, but instead, as we expect, the >> unique_key is updated. >> >> >> <https://lh3.googleusercontent.com/-ljm82srMLEY/WsOvv9pkAFI/AAAAAAAAJOE/TXEuIIOAISEUyECO6AzbZc_5i1Kc98fNgCLcBGAs/s1600/Selecci%25C3%25B3n_006.png> >> >> 3 - I log out. Again, the record remains and the unique_key field is >> updated. >> >> >> >> <https://lh3.googleusercontent.com/-rPQY5jo7-Fk/WsOwUljKf2I/AAAAAAAAJOU/1w1KaZJnXQYYHeI4G6dliSb4rr1OBgF0QCLcBGAs/s1600/Selecci%25C3%25B3n_007.png> >> >> >> (Updated: My bad, after the log out, the record is deleted and a new one >> is created. I did'nt notice the new ID "17".) >> >> >> Whatever I do, only one record is stored according my session origin (IP, >> Browser, etc) and this remains true until my session expires or is deleted. >> >> Maybe I'm talking nonesenses, but it is feel "better" to me, having a >> "true one instance per session", using the DB, that many files/folders >> created over and over again related to the same origin using the filesystem. >> >> What I am missing here? >> Is this the normal/expected behaviour when the default FS session >> handling is used? >> Can we consider that is more performant using the DB alternative that the >> FS one? >> >> BTW: It seems that the admin option to "cleanup" only clear the sessions >> store in the filesystem, not the DB alternative. >> >> Thanks for reading! >> > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
