xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Changes between Initial Version and Version 1 of Ticket #2125, comment 14


Ignore:
Timestamp:
04/02/20 03:46:01 (18 months ago)
Author:
brief
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #2125, comment 14

    initial v1  
    11> * {{{--proxy-sessions=auth,sys,mdns,register}}} so the proxy can be told where to get the list of sessions from (and maybe those options can be combined?):
    22Combining seems like a good idea.
    3 
     3[[BR]]
    44> * the sessions can be identified using their uuid, and maybe other attributes? the display string is not a good match as multiple servers running on different systems can use the same display number. uids are not usually portable either (not without things like ldap - which we can't require)
    55The server could send its desired display name, e.g. "Facility 7, Room 5" and forwarded application. Furthermore, the session is tied to a proxy user (from e.g. server_users, see above(and could be shared with a proxy_group)). Clients requesting sessions from the proxy are only getting their accessible sessions, thus the displayname has limited scope.
    6 
     6[[BR]]
    77> * do we want to think about load-balancing?
    88To balance register/list requests? Or to balance connections between client and server in TURN mode?
    9 
     9[[BR]]
    1010> * how do we select a session easily?
    1111> * if more than one is available?
    1212A session has to be selected choosen from prior requested list of accessible sessions.
     13[[BR]]
     14> * only allow registration on some tcp / ws / wss / ssh sockets?
     15Allow on all specified authenticators?
     16[[BR]]
     17> * support multiple proxies: register with all of them, or the first one, or random, or...
     18Take a xpraUri[][] as proxies. Server will connect to one of each inner in all outer.
     19[[BR]]
     20> * the proxy needs to keep track of those sessions in memory, return them before or after the ones from the client auth module?
     21Can they be stored using the Authenticator?
     22[[BR]]
     23> * the proxy servers could also listen for mdns broadcasts and expose those servers
     24Are mdns broadcast receivable via client packets?
     25[[BR]]
     26> * I would like to re-use all the socket code and authentication configuration options for the server registration (so servers can use ssl / ssh / whatever), but ideally without letting the servers have the same privileges as regular authenticated users (ie: no ability to connect to sessions or start new sessions, just registering) - not sure how to do that yet (comment:4 suggested using a new authentication module, but this would be too difficult to tie with other features: keepalive, etc), should this be configured at the socket level (as part of the {{{--bind-XXXX}}} option), or as part of the authentication module? (ie: {{{access=full,register,info,...}}} to specify what the authentication gives access to)
     27Is this still a problem?
     28[[BR]]
     29> * the server code will need a new option for telling it to register with the proxy, something like: {{{--register=tcp://host:port/?options}}}, it will need options like keepalive and re-connect, we should detect authentication failures and not retry too often in that case
     30I would consider to specify a list of proxies where keep-alive packet are send to (including a token). Registering using credentials should be a one time (interactive) action to get a token.