How are sessions handled in Zotonic?

Hello,

I’d like to know how sessions are being handled with Zotonic 1.x. I’ve noticed they are now linked with MQTT sessions. Cotonic also uses it.

We are migrating a system that uses heavily the z_sid cookie and the z_session_manager module. We sell usually 5 active sessions per company to access the system, so we need to verify if the company has empty sessions for new logins, disconnect inactive sessions and set some information by session.

Is there an equivalent API for this on zotonic 1.x? Should the mqtt_sessions be used or is it another module?

Cheers,

2 Likes

Hi,

What are you currently doing to track the counts? Check when a new session is created and track the session processes?

The MQTT process is just a connection process, we try to keep the MQTT-session-id stable between pages, so that the topic for routing MQTT messages to the page is stable.

There is also an unique sid which is used, for example, in things like server side storage.

I have to think what the best solution is to your problem. How are you currently handling timeouts/inactivity of sessions?

Cheers, Marc

3 Likes

Sounds similar to what we have in zotonic 0.x. We use z_session_manager to track sessions of visitors of client sides, so it is possible to easily start cobrowsing sessions. We have set a 5 minute timeout on sessions, so they are recycled fast, and just monitor the session’s pid.

This does not work for 1.0 though. We didn’t look into this yet, but we should probably solve this with what MQTT is offering for this via clean sessions or persistent sessions, and last will and testament messages. That should probably be configurable from cotonic and mqtt_sessions should get an api to monitor this.

3 Likes

Hello,

What are you currently doing to track the counts? Check when a new session is created and track the session processes?

Yes, we use auth_logon, auth_autologon e auth_logoff notifications + z_session_manager:foldl and z_session:session_info to keep track of how many sessions are active for a company. We also store some info in each session regarding the current access id and other user options.

Sounds similar to what we have in zotonic 0.x . We use z_session_manager to track sessions of visitors of client sides, so it is possible to easily start cobrowsing sessions. We have set a 5 minute timeout on sessions, so they are recycled fast, and just monitor the session’s pid.

Very similar indeed, but we just track logged users.

This does not work for 1.0 though. We didn’t look into this yet, but we should probably solve this with what MQTT is offering for this via clean sessions or persistent sessions, and last will and testament messages. That should probably be configurable from cotonic and mqtt_sessions should get an api to monitor this.

A clean API for this would be awesome, I can help with the code. First I have to understand how the mqtt_sessions and z_mqtt_sessions_runtime work and how you guys think this could be resolved. Who is the owner of the session processes? Are they still erlang processes? Is there any tricky part or risk to breaking something?

I’ll study the current code today.

Cheers,

3 Likes

The module mod_server_storage can be interesting, that one is already tracking sessions.

I was thinking of some generic presence like functionality. Which could be done with periodic pings to a topic, and/or with tracking/linking the MQTT session processes.

When a MQTT process disappears then it is not guaranteed that the client is gone as well. Could also be process renaming, or some timeout.

The big difference between the 1.x and the 0.x session management is that in the 1.x the client is in charge, where in the 0.x the server kept all session information.

This change means that in the 1.x people are not logged off if the server has an hiccup.

3 Likes