Support private repositories with authentication

[GeertvanHorrik]

Support private repositories.

[maartenba]

Would love to see this!

[GeertvanHorrik]

We could do this because we can inject custom commands into the pdb files. However currently I am a bit overloaded with work, but I hope this will change in the near future so I can implement this.

[GeertvanHorrik]

I am still considering this, but we should never store the username / password in the pdb files, so we need something to work around this (ask for credentials on the client machine).

[AArnott]

Thanks for being security conscious, @GeertvanHorrik.

Check out this guide for using the Windows Credential store to store the account information.

[GeertvanHorrik]

I'll look into it. See http://www.codeproject.com/Articles/245824/Sourcepack-indexing-PDB-files-with-source-archive, it shows how to run custom commands. We should focus on SRCSRVCMD. It might be a custom app we will ship next to the pdb files (but is that something we really want to do?).

[AArnott]

Good point. Probably not, although an exe could be shipped in the NuGet package's tools folder so at least it doesn't tend to result in the consumer shipping the .exe with their app.

[AArnott]

Maybe you can write a small powershell script that does the WinCred interaction and your SRCSRVCMD can invoke powershell with the script carried as an argument?

[GeertvanHorrik]

Yep, good idea. Will look into it as soon as I have time (a few deadlines coming up soon, and today everything I touch breaks, so not a good day).

[GeertvanHorrik]

We implemented native credential prompters in another lib. Maybe we can re-use part of that code so we can safely store the credentials inside the windows vault instead of inside the pdb files.

[ctaggart]

Visual Studio will prompt for a username and password if the source server responds with a HTTP 401. Unauthorized. In order to make GitHub private repositories compatible, I created a basic http proxy. This solution should work with GitLink users as well. Details here:
http://blog.ctaggart.com/2015/07/sourcelink-10-with-private-github.html

[marcind]

Hi all,
will you guys be able to make any progress on this soon? I'm really interested in getting this working. @ctaggart 's proxy service is good enough for my needs, however it doesn't work with GitLink because the github provider strictly matches the URL points at github.com (which is different for the proxy service). Looks like I could achieve what I want by writing my own provider, but that extensibility doesn't seem to be there either (per #36).

In general I agree that using something like the windows credential store would be the best, but until then I'd like to get a workaround going. Before I create a private build, I wanted to see if there's anything I could contribute to the project to enable this scenario.

Thanks

[ctaggart]

@marcind, have you tried using SourceLink.exe instead? It doesn't limit the URL. http://ctaggart.github.io/SourceLink/

[GeertvanHorrik]

@marcind, thanks for contacting. Would the ability to specify a custom url be sufficient? That is just a few changes:

1. Introduce parameter in context and parser
2. Override url and use custom provider

I am currently on holiday, but if you want you can try a PR if you are interested. If not, I will look into it next friday or so.

[marcind]

I've prepared a PR that with a fairly small change handles a bunch of open issues. See the PR for details.

I'm not sure how much my approach matches with what you were suggesting, but it felt like the simplest way to achieve the goal without having to modify any of the binary contracts (in case you guys subscribe to semver). Let me know what you think.

[GeertvanHorrik]

Still needs a proxy, but I will leave it to the end-users if they want to go that route (the proxy will need credentials, so might be a possible security issue if not done / hosted correctly). But custom urls are supported thanks to @marcind so this is supported.

Closing the issue, feel free to re-open if you feel this is incorrect.