intercept closing session

[Giuseppe D'Amico]

Hi, I am new with web2py, is there a way to intercept  the closing of a session?

[Alan Etkin]

El martes, 7 de enero de 2014 14:40:38 UTC-3, Giuseppe D'Amico escribió:

Hi, I am new with web2py, is there a way to intercept  the closing of a session?

You mean you want to catch a user logout from the scaffolding app?

You could modify the user action at controllers.py so it checks wether the "logout" action was asked:

def user():
    if request.args[0] == "logout":
        <do something>

There's also the auth.settings.logout_onlogout which can be a function that receives auth.user as argument (undocumented) and auth.settings.logout_next (a URL for redirection after logout).

EDIT: The user action is at controllers/default.py

[Richard Vézina]

tornado and websocket_messaging.py in contrib

Richard

On Tue, Jan 7, 2014 at 12:40 PM, Giuseppe D'Amico <damicogi...@gmail.com> wrote:

Hi, I am new with web2py, is there a way to intercept  the closing of a session?

--
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+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Richard Vézina]

You may found more info with comet_messaging.py since it have been rename to websocket_messaging,py recently

Richard

[Richard Vézina]

You need websocket_messaging.py if you want to know who is actually connected... Alan solution may works if you only want to catch logout event, but you don't have logout event in case user closer the browser...

Richard

[Giuseppe D'Amico]

thanks I will do like you say

2014/1/7 Alan Etkin <spam...@gmail.com>

El martes, 7 de enero de 2014 14:40:38 UTC-3, Giuseppe D'Amico escribió:

Hi, I am new with web2py, is there a way to intercept  the closing of a session?

You mean you want to catch a user logout from the scaffolding app?

You could modify the user action at controllers.py so it checks wether the "logout" action was asked:

def user():
    if request.args[0] == "logout":
        <do something>

There's also the auth.settings.logout_onlogout which can be a function that receives auth.user as argument (undocumented) and auth.settings.logout_next (a URL for redirection after logout).

--
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 a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/rzS37obsTI4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.

[Giuseppe D'Amico]

what if someone does not do the logout, but for some reason the session end?

2014/1/7 Giuseppe D'Amico <damicogi...@gmail.com>

[Richard Vézina]

The same I guess, you will need websocket_messaging.py and tornado server...

This video is great even if in portuguese : http://vimeo.com/38972256

Richard

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+un...@googlegroups.com.

[Richard Vézina]

There is also this vid : http://vimeo.com/18399381

Richard

[Anthony]

What exactly do you need to do?

[Giuseppe D'Amico]

I have to  connect to a database known only at runtime, I create the  model on the fly, but it is not thread safe, so I thought that a possible solution could be to give to the model the name of the session_id, but I believe that there is a better solution, how do you think a  thing  like that should be done?

2014/1/7 Anthony <abas...@gmail.com>

[Anthony]

On Wednesday, January 8, 2014 1:48:28 AM UTC-5, Giuseppe D'Amico wrote:

I have to  connect to a database known only at runtime, I create the  model on the fly,

Do you have to create the database or a database table on the fly (or something else)?

 

but it is not thread safe,

Why is it not thread safe?

 

so I thought that a possible solution could be to give to the model the name of the session_id

Do you need a model per session or just per user? In any case, why does this require knowing when the user terminates the session -- do you have to destroy the data at that point?

Anthony

[Giuseppe D'Amico]

I have to create the database, using the same model  for every user it is not safe, so I use the session_id as name file for the model, I need to intercept when a user's session ends, to delete its model  

2014/1/8 Anthony <abas...@gmail.com>

--

[Anthony]

On Thursday, January 9, 2014 10:02:23 AM UTC-5, Giuseppe D'Amico wrote:

I have to create the database, using the same model  for every user it is not safe, so I use the session_id as name file for the model, I need to intercept when a user's session ends, to delete its model  

It's not clear whether you are talking about models or databases. The model is defined during the request and exists only during the request. You don't have to change the name of the model or delete it at the end of the request. You could do:

db = DAL([connection string that is specific to this user], ...)

db.define_table('mytable', ...)

When User A makes a request, db will be a connection to that user's database, and db.mytable will therefore be a model of the "mytable" table in User A's database. When User B makes a request, db will be a connection to a different database, and db.mytable will be a model of the "mytable" table in that database. These objects will be created in different threads and exist only as long as the request lasts.

The question is, what happens with all of these databases? Do you really want one for every session, or just one for every registered user. If the latter, do you want the data to persist over time (i.e., beyond the session)? If so, don't use the session ID to name the database.

Note, it can be tricky to figure out when a session ends. Technically, the session cookie should last until the user closes their browser, but you can't know when that happens. As an alternative, you could define some time limit of inactivity and automatically expunge any data associated with a session that has been inactive for too long.

Anthony