I've been working on a x2go setup using a session broker. The issue I'm having is our auth uses 2-factor with tokens which I wrote a working auth_mech for. The problem is the client resends the initial username and password with each request to the session broker which in turn tries to re-authenticate with them. Our system doesn't allow reuse of token codes so all requests after the first fail.
I've taken a look at the beginnings of the dynamic cookie code in the session broker to see if I could make it work for our needs. As I understand the code that's there, the client would first connect with the static cookie value then a new random uuid4 is created for that user. That new random cookie would then need to be sent to the client so it can use it for its next auth, but I can't find any intent on how it should be communicated toward the client. From then on each request gets a new uuid5 created cookie based on the prior uuid and username, these could theoretically be generated independently on both client and server (assuming client knows the initial random one to see with).
I'm happy to work on finishing this feature up but would like to make sure I'm roughly inline with where you guys where going with the feature so I have a few questions.
How were you planning on communicating the randomly generated cookie back to the client?
Were you intending to send the new next cookie to the client on every request or only do it once and have client and server keep generating independently? (the later could be an issue for QT client as QT4.8 doesn't support creating v5 UUIDs)
How were you planning on handling multiple simultaneous connections from one user? (looks like next cookies would clash with each other in map)
Thanks,
-Josh