Determining which authentication method [message #1731236] |
Tue, 03 May 2016 16:21 |
Dave Musicant Messages: 15 Registered: May 2016 |
Junior Member |
|
|
I'm trying to use JGit to determine which authentication method should be used for an existing repo. With the regular command-line Git client, this info is baked into the remote definition; issuing a "git fetch," for example, knows whether HTTP or SSH (or whatever) is the right one to use.
I've written the following code to perform the same auto-detection using JGit. It seems to work, but I've got some questions as to whether there is a better way:
... repo is the Repository of interest ....
Config storedConfig = repo.getConfig();
Set<String> remotes = storedConfig.getSubsections("remote");
// challenges here if I have more than one remote, but that's a separate problem
String repoUrl = storedConfig.getString("remote", remote, "url"));
List<TransportProtocol> protocols = TransportGitSsh.getTransportProtocols();
List<String> repoURLs = getLinkedRemoteRepoURLs();
for (TransportProtocol protocol : protocols) {
String protocolName = protocol.getName();
try {
if (protocol.canHandle(new URIish(repoURL))) {
if (protocolName.equals("HTTP"))
// do whatever I want from here, point is I've discovered HTTP is the right protocol
else if (protocolName.equals("SSH"))
// do whatever I want from here, point is I've discovered SSH is the right protocol
else
continue;
}
} catch (URISyntaxException e) {
throw new RuntimeException(e);
}
}
This seems to work, but I've got the following concerns:
- Is using the protocol name a reliable way to do this? Is that likely to be stable over multiple versions of JGit?
- Iterating over all possible protocols and testing the name to see if it's the one I want seems clunky. Is there a way for me to more directly just ask: does this repo support SSH?
- Can it be the case that canHandle returns true for more than one protocol? I'll need to rig up a priority structure in that case.
I think all of the above can be summarized by asking "is there a better canonical way to do what I'm trying to do?"
|
|
|
|
|
|
|
Re: Determining which authentication method [message #1731911 is a reply to message #1731904] |
Tue, 10 May 2016 20:33 |
Rüdiger Herrmann Messages: 581 Registered: July 2009 |
Senior Member |
|
|
Hi Dave,
the two suggested methods don't exactly match the "Which Authentication
Method to Use?". The latter would make a third method, but similar to my
first suggestion.
Both, in essence, try to determine beforehand which protocol will be
used and configure the JGit operation accordingly. Method one however
wouldn't be "ripping the protocol out of the URL". The ideas is -
similar to what the blog post suggests - inspect the URL to find out
which protocol will be used.
But again, I think it won't harm to configure the operation with all
known authentication methods (method two) and have the operation "pick"
the appropriate one.
HTH
Rüdiger
On 10.05.2016 20:16, Dave Musicant wrote:
> Rüdiger -
>
> I appreciate the response, thank you.
>
> Of your two approaches, does either of those match the "Which
> Authentication Method to Use?" section of your blog posting? If I
> understand what you're suggesting (and I may not, so I'd appreciate the
> help if I'm confused), method 1 is ripping the protocol out of the URL
> as a strong operation. That sounds different than testing via a
> TransportProtocol canHandle method. Regarding method 2: the blog posting
> mentions using callbacks for ssh (password or public key), but not for
> HTTP. Is your method 2 here recommending adding a callback for HTTP as
> well?
>
> Dave
--
Rüdiger Herrmann
http://codeaffine.com
|
|
|
|
|
Re: Determining which authentication method [message #1732892 is a reply to message #1732491] |
Sun, 22 May 2016 09:35 |
Rüdiger Herrmann Messages: 581 Registered: July 2009 |
Senior Member |
|
|
Dave,
the instaneof tests are the best I could come up with. While this works
in practice, there is certainly room for improvement in readability and
maintainability. You may for example consider a generic
TransportConfigCallback that let others contribute 'configurers' for
certain protocols.
From a practical POV, SSH is the only protocol I know of that requires
an extra configuration step. For the remaining protocols a credentials
provider is sufficient.
Hence the TransportConfigCallback I have in use looks like this:
@Override
public void configure( Transport transport ) {
transport.setCredentialsProvider( new MyCredentialsProvider() );
if( transport instanceof SshTransport ) {
SshTransport sshTransport = ( SshTransport )transport;
sshTransport.setSshSessionFactory( new MySshSessionFactory() );
}
}
where MyCredentialsProvider is a ChainingCredentialsProvider that chains
a NetRCCredentialsProvider and a user/password credentials provider.
HTH
Rüdiger
On 17.05.2016 17:54, Dave Musicant wrote:
> Hi folks, I'm back. I'm trying to work with Rüdiger's suggestion to
> "configure the operation with all known authentication methods (method
> two) and have the operation 'pick' the appropriate one."
>
> I've ended up with some prototype code that looks like:
>
>
> LsRemoteCommand command = Git.lsRemoteRepository();
> //command.setRemote("https://github.com/....repo1...");
> command.setRemote("git@xxxxxxxx:...repo2...");
>
> SshSessionFactory sshSessionFactory = new
> JschConfigSessionFactory() {
> @Override
> protected void configure(OpenSshConfig.Host host, Session
> session ) {
> // do nothing
> }
> };
>
> command.setTransportConfigCallback( new TransportConfigCallback() {
> @Override
> public void configure( Transport transport ) {
> System.out.println(transport.getClass());
> SshTransport sshTransport = ( SshTransport )transport;
> sshTransport.setSshSessionFactory( sshSessionFactory );
>
> }
> } );
> command.call();
>
>
> When I run the code as given, I'm setting the remote to an SSH remote.
> The callback receives a TransportGitSSh transport object, and setting up
> the SshSessionFactory works as expected. When I comment out the line
> with repo2 and instead use repo1, the callback instead receives a
> TransportHttp object, and then of course casting the transport object to
> an SshTransport fails. I could solve this via an instanceof test, but
> that felt to me like I wasn't understanding the spirit of Rüdiger's idea
> of "configuring with all known authentication methods." I would only be
> able to configure it for ssh if the transport object was of the
> appropriate type. Am I headed in the right direction with instanceof
> tests, or am I missing the point?
|
|
|
|
Powered by
FUDForum. Page generated in 0.03547 seconds