|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
How would this be fixed? The second problem with CLIRegisterer seems easy enough: just use a ClassParser on the CliAuthenticator to configure it; an oversight, apparently. (Need to have tests which actually pass --username and --password to CLI commands rather than assuming transport authentication!)
But the first problem, with CLICommand.main, seems tricky due to the design of CliAuthenticator, specifically the fact that there is no syntactic delineation in argv between the authenticator’s options and the command’s options and arguments. We want to half-parse the command to configure the authenticator; authenticate; then finish parsing the command with that authentication set.
I thought of calling getCmdLineParser() twice, once just to configure the CliAuthenticator, then again with a fresh instance to really configure the command. But then GenericItemOptionHandler (for example) is going to throw a CmdLineException during the first parse, which will be thrown up and out of parseArgument. If --username and --password are both at the front of the command (rather than after the job names), then I guess these will already be set and we could just swallow the exception, but this seems fragile, and the behavior would be confusing since these arguments would work in some cases (where anonymous can see jobs) but not others (no anonymous read access).
Or we could specially extract --username and related arguments and configure the authenticator with a special argument line. This will work only for a AbstractPasswordBasedSecurityRealm however; would break if someone introduced a security realm with another kind of authenticator. I am not sure if that would ever happen; the one plausible extension would be support API tokens rather than passwords, but this cannot be done as a CliTransportAuthenticator (since it would be command-line args, not transport) and cannot be done as a CliAuthenticator either (since it cuts across all security realms).
Or we could somehow try to automatically determine which portions of the argument line belong to the authenticator, but this would be delving deeper into args4j than I dare at the moment.