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.
See also #1861
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)
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.
Examples:
PASSWORD1=foo PASSWORD2=bar xpra attach tcp://192.168.1.7:10000 -d auth --challenge-handlers=env:name=PASSWORD1 --challenge-handlers=env:name=PASSWORD2
--password-file
command line argument is deprecated)
xpra attach tcp://192.168.1.7:10000 -d auth --challenge-handlers=file,filename=pass.txt
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1796