xpra icon
Bug tracker and wiki

Opened 4 months ago

Last modified 8 weeks ago

#1690 assigned enhancement

request access to session

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 2.3
Component: core Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

Follow up from #1368: a user may want to request access to a session which is already connected. The server could forward the request to the existing client(s), delay the new client's connection timeout, and depending on the response from the existing client(s) either allow the connection or reject it.

We could then start the sessions with sharing disabled and let the user decide at runtime when to allow others to connect.

This would be even more useful for shadow mode, where the request to access the session could be presented to the user of that session as an alert.

Change History (4)

comment:1 Changed 4 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned

comment:2 Changed 4 months ago by Antoine Martin

Milestone: 3.02.3

comment:3 Changed 3 months ago by Antoine Martin

Stackable authentication modules moved to #1728

Still TODO: add UI prompt authentication via built-in GTK based prompt, "dialog"?

Last edited 8 weeks ago by Antoine Martin (previous) (diff)

comment:4 Changed 3 months ago by Antoine Martin

Implemented for shadow servers using the new "exec" auth module in r17780.
With platform support for macos added in r17781 + r17825 + r17822, win32 in r17783, and RPM + DEB packaging in r17782.


xpra shadow --bind-tcp= --tcp-auth=exec

This will popup a dialog asking if the new connection should be allowed or not.

This new auth module has two configuration options:

  • timeout: the delay in seconds before we terminate the command and fail, ie: tcp-auth=exec:timeout=60
  • command, ie: tcp-auth=exec:command=/bin/true. The command will be given the request message (ie: Connection request from ...) and the timeout as arguments. It should return 0 to allow the connection, any other value to reject it. By default, we use the "auth_dialog" tool that we ship. (just a simple yes-no dialog)

As per #1728, this can now be combined with other auth modules. (ie: password + request, or tcp-wrappers + request, etc)

This is only useful for "shadow" sessions since there will be an existing display connected where the user can accept the request.

Still TODO:

  • maybe rename or alias this module? (keep "exec" for generic configurable exec)
  • maybe make this the default for shadow sessions (at least on win32?)
  • rate limiting: we don't want to flood the user's display with requests
  • deal with regular servers (non-shadow): probably not using authentication modules but client-server messages

We could piggyback onto #1735

Last edited 2 months ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.