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 


_______________________________________________
X2Go-Dev mailing list
X2Go-Dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/x2go-dev

Reply via email to