http /machine/connect session timeout

stuartofmt

I'm using 3.6.0 rc.2 SBC on bookworm.

TLDR; Session timeout of 8 seconds seems too short. More-or-less forcing an explicit reconnect before any other call (to be safe) seems wasteful.

Is there a better way? Am I misinterpreting?

Some plugin code (which I would have sworn before was working) has stopped.
Essentially, this is what is happening:

I use /machine/connect to connect and get a session key
Some time later (more than 8 seconds) I try to use /machine/code to send a M291 Message however it errors out with code 401

Looking in the journal I can see the session key being expired

Apr 26 21:21:01 srsender DuetWebServer[699]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://192.168.10.140/machine/connect?password=reprap - - -
Apr 26 21:21:01 srsender DuetWebServer[699]: DuetWebServer.Singletons.SessionStorage[0] Session dbd8f686859c46a188512afad6e3a8cd added (readWrite)
<snip>
Apr 26 21:21:09 srsender DuetWebServer[699]: DuetWebServer.Singletons.SessionStorage[0] Session dbd8f686859c46a188512afad6e3a8cd expired

This document https://github.com/Duet3D/DuetSoftwareFramework/wiki/REST-API
States:
The resulting session is maintained at least 8 seconds but it may last as long as

a WebSocket is open
a long-running HTTP request is being processed (code, upload, and package requests) When the session has expired, HTTP code 403 is returned by other requests.

An implication of this is that any application that doesnot interact with DSF needs to more-or-less, reconnect every 8 seconds. This seems wasteful.

Compare this to rr_connect which has a session timeout of 8000 seconds.

stuartofmt

A small update: I did some tests with /machine/connect and /rr_connect Not sure if this behavior is intended or not.

The /machine/connect API has a session timeout of ~ 8 seconds independent of whether a password is required/used or not.

The /rr_connect API appears to have an 8000 second timeout when no password is required but has an 8 second password when a password is required.
Also /rr_connect?sessionKey=yes does not provide a sessionKey (at least when called from a browser).

EDIT: Programatically using /rr_connect?sessionkey=yes&password=<password if used> returns (i.e. no session key also).

{"apiLevel":1,"err":0,"isEmulated":true,"sessionTimeout":8000,"boardType":"duet5lcunknown"}

chrishamm

@stuartofmt If you do not have a password set and don't specify a session key, then there should be no need to use one. For the same reason requests like /machine/model work from a plain browser tab. If you have a password set, there is no alternative, though. The reference implementations all depend on those keys because we cannot assume users never specify passwords.

In addition to that, the session timeout is configurable via /opt/dsf/conf/http.json - see SessionTimeout in there.

chrishamm

@stuartofmt said in http /machine/connect session timeout:

Compare this to rr_connect which has a session timeout of 8000 seconds.

I guess you mean ms here - that's what the value indicates.

stuartofmt

@chrishamm said in http /machine/connect session timeout:

@stuartofmt said in http /machine/connect session timeout:

Compare this to rr_connect which has a session timeout of 8000 seconds.

I guess you mean ms here - that's what the value indicates.

I misinterpreted that as seconds because of the behavior when I did not have a password set..

stuartofmt

@chrishamm said in http /machine/connect session timeout:

@stuartofmt ..... If you have a password set, there is no alternative, though. .....

In addition to that, the session timeout is configurable via /opt/dsf/conf/http.json - see SessionTimeout in there.

As a practical matter then, if a password is set and when the time between calls is not known: It looks like every call ought to disconnect, connect, make the desired call. An alternative would be to keep track of how long its been since the last connect call and if >= 8 seconds: connect , make the desired call

I'd be loath to "hijak" a system wide variable for the sake of a plugin

Thanks for the clarity. The documentation does not make it entirely clear that there is a different behavior between the no-password vs password scenario.