Understanding perspective session events

Ignition Early Access
1

As suggested in another thread, I’m trying to use the message passing mechanism to communicate from a perspective client to the gateway.

On the client, I’ve set up the following startup and shutdown event scripts:

# startup
system.util.sendMessage(project = 'myproject', messageHandler = 'start_session', payload = { "session_id": session.props.id, "device_id": session.props.device.identifier})

# shutdown
system.util.sendMessage(project = 'myproject', messageHandler = 'end_session', payload = { "session_id": session.props.id, "device_id": session.props.device.identifier})

On the gateway, I’m just logging that the message is being received:

# start_session handler
log = system.util.logger("Gateway Script Logger")
log.info("START SESSION, ID: %s, DEVICE ID: %s" % (payload["session_id"], payload["device_id"]))

# end_session handler
log = system.util.logger("Gateway Script Logger")
log.info("END SESSION, ID: %s, DEVICE ID: %s" % (payload["session_id"], payload["device_id"]))

Now, I launch the perspective session in the browser from designer, and in the logs I see:

Socket connected to session. pageId=2471ea92
START SESSION, ID: 0aed7b35-3fd4-40bd-b360-5719c8a9b552, DEVICE ID:

(not sure about the empty device id). I close the browser, and in the logs I do NOT see the end session event, instead I only see:

WebSocket disconnected from session.

If I relaunch the session, again I do NOT see the start session event, but just:

Socket connected to session. pageId=1e672231

and the same if I continue to launche/close the session. Only after some time (presumably due to timeout) do I see the end session event in the log:

END SESSION, ID: 0aed7b35-3fd4-40bd-b360-5719c8a9b552, DEVICE ID: browser-cd3e7e56-e24e-40a8-9358-bdf7e508071c

(not sure why the device id now appears). Is this expected behavior? I was thinking that I would see a “start_session” event each time I launch a session.

2

The behavior you are seeing is what I would expect. HTTP is a stateless protocol, so state has to be layered on top of it (session via cookie). Disconnecting, by itself, doesn’t throw away the browser cookie, and shouldn’t, or minor network hiccups will log your users out. Which means the gateway has to infer an end of session with a timeout.

Keep in mind that your “client” scripts in Perspective are still running in the gateway.

1 Like
3

Closing a browser window doesn’t kill your session - it remains alive for 120 (maybe 60?) seconds by default, which can be configured here, in the Session Timeout section:

03%20AM
03%20AM650×574 41.8 KB

So you won’t see the “end_session” message sent from the Perspective Session for at least one minute, maybe two.

I’ll look into the device_id being empty, but I just tested it myself and it worked as expected…

4

Oh, if you’re testing from the Designer, you won’t see a device_id value - that only gets populated from an actual browser/application. I’ll see if there are any other instances which would cause it to not populate. Which browser were you using?

5

It’s also important to understand that each perspective session is tied to a specific project and if you have multiple tabs open in the same browser pointing to the same project, the session timeout will not start until the last tab for that project session disconnects. If a new tab opens and connects for that project session before the timeout elapses, the timeout is cancelled and the session lives on. Each new tab will attach to the existing project session on the gateway if it exists or if there is no project session yet (because it is the first tab open in your browser for a given project), one will be created.

For more details, see: https://docs.inductiveautomation.com/display/DOC80/Perspective+Sessions

6

Would an explicit call to system.perspective.logout() help? If so, I could tell users to quit by pressing a button that calls that.

7

I wouldn’t expect so because the session is still open, you would just no longer be authenticated.

8

Firefox. It still looks strange to me, though, since the end_session event did receive a device_id; where was that hiding when the session started?

Also, using the app on a mobile phone (tested with two so far) shows the same behavior. Phones are a koobee (can’t look up the model now) and a huawei vns-l31.

9

It looks like the session startUp script is firing during the true initialization event, before the device ID is part of the Session… I’ll look into it.

10

The fix for this has been completed, but it was not done in time for the 8.0.0 release. Use of session.device.identifier in Session Startup scripts will continue to result in empty String values until the release of 8.0.1.