No luck getting Source Link to work with Cloud hosted Bitbucket

[mdemler]

Our code is stored on Bitbucket's hosted platform. We're attempting to debug private NuGet packages that we are the author of.

For the package that I'm testing, I've set the following in its .csproj:

  <PropertyGroup>
    <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
    <IncludeSymbols>True</IncludeSymbols>
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.SourceLink.Bitbucket.Git" Version="1.1.1">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>

On the consuming end, I've ensured that symbols are loading as well unchecked Enable Just My Code and checked all options for Enable Source Link support and Enable source server support.

I'm attempting to access the code for a call in the callstack that lives in the nuget package. When I do so, it's getting a 404 when it attempts to access the file using http://api.bitbucket.org. When I try to access the file outside of the API via https://bitbucket.org, the path that it's using works.

It would appear to be some sort of authentication issue, but I'm not certain how to troubleshoot that, as I don't know which credentials are being passed into the API, nor am I ever prompted for credentials. We are using Bitbucket with 2FA and SSH, as is required to utilize their CI pipelines anymore.

Can you provide guidance on where to go from here?

[dominoFire]

@tmat would you please help me triaging this issue. Thanks!

[tmat]

@chuckries Authentication issue.

[mdemler]

I've further investigated this issue, and I've been unable to get Visual Studio 2022 to ever pass auth credentials when calling into Bitbucket Cloud. When using Postman and passing the credentials via Basic auth, the URL that it is failing in Visual Studio does indeed work. I've set the Fall back to Git Credential Manager authentication for all Source Link requests option without any change in behavior.

[LightWeight-POS]

Hi,

Will this issue be fixed soon ? I am also facing the same issue.

[chuckries]

@mdemler @Muhammad-Hunain-Dev how are you authenticating when you clone these BitBucket repos?

[chuckries]

Are you ever seeing a page in VS that says <Source File>.cs not found: Source Link authentication failed?
If so, this page has a link on it to authenticate the request and try again. I have been able to use private BitBucket Cloud sources by authenticating from this page. I see an Atalassian branded login UI, at which point I can login with my browser or I was able to authenticate directly from the pop up using a Bitbucket "App Password" with repository read scope.

[mdemler]

I don't receive any sort of auth prompt. I remember seeing doc that I was supposed to, but I couldn't ever get it to trigger. I just get a 404, which it mentions might be related to some sort of auth issue.

[chuckries]

Are you able to use fiddler to check if any Authorization header is included on the request VS is making? Can you provide me the exact URL that Source Link is trying to reference for you (with the exact account/repo info edited out)? In windows credential manager, do you see any Windows Credential > Generic Credentials that start with git: and reference BitBucket or Atlassian?

[mdemler]

No, there is no authorization header in the request that it's sending.

Here's a raw request that was sent:

GET https://api.bitbucket.org/2.0/repositories/private/src/daf7db5aef3b2e43905d71c62ed952778709298f/private.cs HTTP/1.1
User-Agent: Microsoft.VisualStudio.Debugger.SourceLink.17.0.0.0
X-TFS-FedAuthRedirect: Suppress
Host: api.bitbucket.org

Yes, I have three generic credentials in Credentials Manager for various forms of git:https://bitbucket.org. I have no issues pulling and pushing to the same repositories that I attempt to utilize with Source Link from within Visual Studio.

[chuckries]

@mdemler do you recall how you originally would have authenticated the clone/push on your box? Did you get a popup when you cloned? Or did you set up SSH keys?

[mdemler]

Fortunately, we have that process documented, so I can say with certainty how it worked. It absolutely does prompt for granting access. Here's a screenshot:

That's when accessing our repo via https://bitbucket.org. Curious if Source Link using https://api.bitbucket.org is somehow introducing a wrinkle.

[mdemler]

I'm back trying to get this working. I have been able to determine that if I build the NuGet package locally, and copy it into the referencing assembly that I'm debugging, Source Link is working properly and does pull down the code as expected. But, anything that we build from our server environment is not able to load the code.

In looking at the differences in requests with Fiddler, for the locally built assemblies, I see Git-Credentials-Manager making requests to Bitbucket before the file is requested and auth credentials being passed with its request. But, this step is missing and no credentials are ever passed when using the assemblies built via our pipeline. They are using the same code, project file, and build steps, so this is definitely odd. Hopefully, that is able to help with the diagnosis.

[mdemler]

We've been able to pinpoint the culprit. We're using Bitbucket Pipelines to build our packages. From with it, the repository url is http and not https. This http is being built into the packages. Accessing http://api.bitbucket.org results in a redirect, which does not get handled.

As a workaround, we're forcing the git URL to https before doing the build, so that Source Link can pick up on that, and then reverting it immediately thereafter. @chuckries Is there a better way to handle this via Source Link?

[chuckries]

I'm not sure why anything would be using an http url over an https by choice. Visual Studio will refuse to provide authentication to any http URL.

[mdemler]

I didn't check with them, but I believe it's all internal to them, so they're avoiding the HTTPS overhead in their pipeline environment. All other public access is over HTTPS.