Project

General

Profile

Session related questions

Added by Emeric Poupon about 11 years ago

Hello,

I don't figure how to handle effeciently sessions, users, session timeout, etc.

In particular, how could I make sure that :

  • a user can be connected (using login/password) in just one session at a time (possibly killing the previous session or telling the user to kill it)
  • a user gets disconnected if it does not issue any action for a time period (possibly by killing the session or telling the user the session is about to close (popup + quit() call).

Best Regards,


Replies (5)

RE: Session related questions - Added by Koen Deforche about 11 years ago

Hey Emeric,

1) you would need to handle this yourself (e.g. using a small library to keep track of where a user is logged in?)

2) you could implement this by specializing WApplication::notify() and look at the event.type(): this lets you know when the user receives a real event (Timer or User-Event) versus a keep-alive event (OtherEvent). When receiving too many keep-alive events in a row you could quit() the session. I haven't tested such a thing yet though, but I believe it should work.

Regards,

koen

RE: Session related questions - Added by Emeric Poupon about 11 years ago

Hello,

Thanks for the ideas !

2) I tried this way but unfortunately OtherEvent events do not allow fine grained timeout control. I receive such events every 1 minute or 2.

I tried to used a WTimer:

- Its callback is set on a quit/redirect method.

- When creating the Application, the timer is started.

  • It's stopped/started each time a UserEvent is received in the notify() method.
    -> Stopping/starting the timer does not work (it never fires), but delete/create it again is working just fine.

Other thing: if I kill the web browser, I have to wait a very long time in order to the sessions to be cleaned/destroyed (10 minutes?). I tried to set the timeout in wt_config.xml to 70 with no luck. But I don't understand why the WTimer does not fire its callback in order to clean the session?

RE: Session related questions - Added by Koen Deforche about 11 years ago

Hey,

A WTimer is browser-initiated (in other to be able to update the UI in response to it).

I would need to look into why start/stop does not work as expected, perhaps it is because it is being done from within the notify() method ?

I don't get why a granularity of one or two minutes is too much for a non-functional thing such as logging out a user if he is inactive ?

The keep-alive request rate is dependent on the session-timeout, so you can increase the accuracy if you want.

Regards,

koen

RE: Session related questions - Added by Emeric Poupon about 11 years ago

Hey,

The ennoying thing is that we do not seem to have any control on the timeout procedure using OtherEvent events. How is the keep alive request rate calculated? What happens if I receive a burst of OtherEvent events (is that even possible) ? Will it still work in future releases? etc.

Do you have any idea why it takes so long for a client-side "blackout" to be detected? I was expected for example a TimerEvent to make the server realize the session is dead.

Best Regards,

Emeric Poupon

RE: Session related questions - Added by Koen Deforche about 11 years ago

Hey Emeric,

Let me explain what Wt does so that we can converge to what is needed for your scenario.

Sessions will timeout +/- after x seconds of not having heard of the browser (the session-timeout parameter).

To prevent a session from timeout while a user is not actively interacting with a web page, keep-alive requests are generated.

These requests are generated so that the time between two keep-alive requests is half the session timeout. This rate is not documented, but is fairly stable (it has been the case since the very first versions of Wt).

Every event that arrives at an application session goes through WApplication::notify():

  • normal user interactivity events ("user")
  • WTimer events ("timer")
  • keep-alive events ("other")

The server does not actively keep track of this, after all, we consider session timeout as something not very tightly defined. Instead we try to make sure that sessions keep living at least as long as the browser is open. Also the server does not actively dispose of sessions, it piggy-backs this check with a new incoming browser request. Thus as long as no other new session is created, it could be that a timed out session is not actively discarded.

Regards,

koen

    (1-5/5)