xpra icon
Bug tracker and wiki

Opened 2 years ago

Closed 14 months ago

Last modified 14 months ago

#1796 closed enhancement (fixed)

modularize client authentication handlers

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 3.0
Component: client Version: trunk
Keywords: Cc:


The same way this was done for the server modules. The modules can then be configured more easily using the challenge-handlers string.
Making it easier to test and to implement new ones (ie: "exec" handler which calls an external binary)
We can also define a clearer interface so modules can claim a particular challenge mode, or be used as fallback.

Change History (3)

comment:1 Changed 17 months ago by Antoine Martin

Status: newassigned

See also #1861

comment:2 Changed 14 months ago by Antoine Martin

At the moment, the process_challenge_uri comes first and is only used once: we clear the password value after use to give the other authentication handlers a chance to run. (details and examples in ticket:1691#comment:8)

The other handlers behave differently... for some this doesn't matter too much (ie: prompt), but for others this prevents other modules from being tried (ie: file, env, etc)

Last edited 14 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 14 months ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

Done in r22711 + r22713 + r22714 + r22715.

All the authentication handlers now live in xpra.client.auth.*.
Each instance can be configured separately, and the same handler type can be used more than once.


  • authenticate using "env" module twice:
    PASSWORD1=foo PASSWORD2=bar xpra attach tcp:// -d auth --challenge-handlers=env:name=PASSWORD1 --challenge-handlers=env:name=PASSWORD2
  • use a password file (--password-file command line argument is deprecated)
    xpra attach tcp:// -d auth --challenge-handlers=file,filename=pass.txt
Last edited 14 months ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.