Repository.ListRemoteReferences needs CustomHeaders setting option

[rmadani]

Similar to FetchOptions used for PullOptions, CloneOptions or PushOptions, Repository.ListRemoteReferences needs to somehow expose a CustomHeaders option. Without it, a request to an on-premise Azure DevOps Server (in my case version 2020), throws the following exception using a Personal Access Token for authentication.

Unhandled exception: too many redirects or authentication replays | LibGit2Sharp.LibGit2SharpException | too many redirects or authentication replays

CustomHeaders are needed to enforce Basic Authorization.

Thank you.

[ethomson]

You're welcome to use custom headers to pass information to the server, but I don't think that I understand. Because you don't need to use custom headers for authentication. You're welcome to use a personal access token using basic authentication. Just set it in the username and password information.

You can treat them as if they were a username/password combination. This is what I do, and this is how we intended you to use personal access tokens when we added them to Azure DevOps.

[rmadani]

Thank you for your quick response. I have tried different combinations of username/PAT in the following sample and I am getting the error mentioned. The Azure DevOps is 2020 version on premise. CredentialsHandler handler = (url, usernameFromUrl, types) => { return new UsernamePasswordCredentials() { Username = “any random name”, Password = “PAT generated by server” //or //Username = “PAT generated by server”, //Password = string.Empty //or //Username = “actual user name”, //Password = “PAT generated by server” }; }; Repository.ListRemotePReferences(repoUrl, handler); //error occurs To provide additional details, The following method works as defined for Repository.Clone CloneOptions property: string encodedToken = Convert.ToBase64String(Encoding.UTF8.GetBytes($”:{PAT from server}”)); var fetchOptions = new FetchOptions { CustomHeaders = new[] { $”Authorization: Basic {encodedToken}” } }; While the following doesn’t work with the error mentioned: var fetchOptions = new FetchOptions { CredentialsProvider = (url, usernameFromUrl, types) => new UsernamePasswordCredentials() { Username = “any random name”, Password = “PAT generated by server” //or //Username = “PAT generated by server”, //Password = string.Empty //or //Username = “actual user name”, //Password = “PAT generated by server” } }; From: Edward Thomson ***@***.***> Sent: Friday, December 27, 2024 1:17 AM To: libgit2/libgit2sharp ***@***.***> Cc: Reza Madani ***@***.***>; Author ***@***.***> Subject: Re: [libgit2/libgit2sharp] Repository.ListRemoteReferences needs CustomHeaders setting option (Issue #2136) You're welcome to use custom headers to pass information to the server, but I don't understand this comment. You're welcome to use a personal access token using basic authentication. Just set it in the username and password information. You can treat them as if they were a username/password combination. This is what I do, and this is how we intended you to use personal access tokens when we added them to Azure DevOps. — Reply to this email directly, view it on GitHub<#2136 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJOLLHVNMYBRQAFSPT3XP3L2HULHBAVCNFSM6AAAAABUH2DTC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRTGQ4TIMRSHA>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[ethomson]

Thanks... I wonder if the problem here is that you're using an on-premises Azure DevOps Server instance, which supports both NTLM and Basic authentication. Our authentication stack prefers NTLM but if you're using a PAT, you can't use NTLM.

This is a bit of an odd case. If you (meaning, the Azure DevOps Server) specify that you allow both NTLM and Basic, then there's no mechanism to say which mechanism maps to which set of credentials. 🥴

Probably we need to be able to provide users the ability to specify not just the credentials but also the mechanisms that the credentials are supported for. That would let you pass UsernamePasswordCredentials but also indicate that they're for Basic authentication. This is a bit of a shitty leaky abstraction, but probably the sensible thing to do. Or we could drop NTLM support and just always use HTTP Basic, which might also be the sensible thing to do, if Microsoft is pushing even on-prem users to create PATs. I'll investigate.

We should also allow the CustomHeaders option to work here, but that's a tactical fix and I'm more interested in what the right long-term plan looks like.