Support for a corporate http proxy

Sep 20, 2010 at 7:33 PM

Hey guys,

I tested the latest bits against my corporate proxy server and I cannot access the public feed.  I created an issue for this http://nupack.codeplex.com/workitem/96.

I also posted a Proof of Concept which resolves the issue. ie It works on my machine. http://nupack.codeplex.com/SourceControl/network/Forks/erichexter/np1

Any chance we can resolve this for the announcement release?

 

Sep 20, 2010 at 11:14 PM

I see, so this one line makes it work:

System.Net.WebRequest.DefaultWebProxy.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;

I'm kind of surprised that the default proxy credentials are not set by default to DefaultNetWorkCredential.  That would seem logical :)

We don't see this issue from inside Microsoft, probably because our proxy doesn't require credentials.

 

Sep 20, 2010 at 11:22 PM

Yes, our access is locked down by users. I am not sure what side effects this could cause.

Sep 20, 2010 at 11:40 PM

Here with the MS proxy, I see DefaultNetworkCredentials has Username/Password set to "", and the new line of code doesn't seem to break anything.  Before that line, I see System.Net.WebRequest.DefaultWebProxy.Credentials being null.

To be safe, we need to also try this code in the scenario where there are is proxy at all (e.g. from home).

Sep 21, 2010 at 12:40 AM

I'll try the latest bits at work tommorw. I've been doing all my package work against a local repo or from home. I think the proxy support is critical to the release as many people will need it (and gem supports this and it's a very frequent question).

Sep 21, 2010 at 2:07 AM

Agreed that the proxy support is critical.  Note that Eric's change is only in his fork, so if you want to test with it you'll have to merge that in (it's just one line).

Sep 25, 2010 at 2:19 AM

The proposed fix is a bit scary because it affects the entire app domain.  Instead, we should be able to just set UseDefaultCredentials=true on the WebClient object (in nupack\NuPack.Core\Packages\FeedPackage.cs).

Eric, could you please verify that this works in your scenario?  We don't have a proxy with credentials that we can test with here.

Developer
Sep 25, 2010 at 2:53 AM

Hey eric can you test the fix out here.

https://hg01.codeplex.com/forks/dfowler/proxyfix

Sep 25, 2010 at 3:10 AM

I will remote in over the weekend and try it out.  Thx for the fork.

On Sep 24, 2010 8:53 PM, "dfowler" <notifications@codeplex.com> wrote:
> From: dfowler
>
> Hey eric can you test the fix out here.https://hg01.codeplex.com/forks/dfowler/proxyfix
>
>
Sep 25, 2010 at 5:00 AM

I see you addressed the webclient to download the package but you did not address the xmlreader that downloads the atom feed.  http://nupack.codeplex.com/SourceControl/changeset/view/47bacc0704b7#NuPack.Core%2fRepositories%2fAtomFeedPackageRepository.cs Look at the call to the XmlTextReader.Create .

Developer
Sep 25, 2010 at 5:27 AM

Try out the fork, it has both fixes.

Sep 27, 2010 at 5:49 PM

This fix is not working for me behind my proxy.  I just loaded the extension from the build server. I will pull the source and debug into it.

Here is the Stack trace

Exception calling "GetPackages" with "0" argument(s): "Unable to read feed. Verify that a feed is hosted at the remote server and is available."
At C:\Users\eric_hexter\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\CodePlex Foundation\NuPack Tools\0.1\Scripts\nupack.ps1:257 char:35
+     return $repository.GetPackages <<<< () | Select-Object Id, Version, Description
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : DotNetMethodException

Developer
Sep 27, 2010 at 5:52 PM

Can you reopen the bug. I think we'll need to work closely on this, can we use the irc channel to discuss potential solutions.

Editor
Sep 27, 2010 at 6:02 PM
I think we are going to need to pop a credentials dialog...
>
Sep 27, 2010 at 6:36 PM

We shouldn't have to ask for credential when the system already has them.  The fact that Eric's initial fix was working shows that it can work (though it was too drastic).  It should be a matter of correctly setting the proxy wherever we need it.

Sep 27, 2010 at 6:53 PM
I agree with David.
 
On Mon, Sep 27, 2010 at 12:36 PM, davidebb <notifications@codeplex.com> wrote:

From: davidebb

We shouldn't have to ask for credential when the system already has them.  The fact that Eric's initial fix was working shows that it can work (though it was too drastic).  It should be a matter of correctly setting the proxy wherever we need it.

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Developer
Sep 27, 2010 at 7:13 PM

Maybe we were setting the wrong thing. Eric can you try messing around with 

http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.proxy.aspx.

Try:

if (request.Proxy != null) {
    request.Proxy.Credentials = System.Net.WebRequest.DefaultWebProxy.Credentials;
}

Btw I'm just guessing here. Put that code in the AtomFeedRepository and see if it works for you.

Sep 27, 2010 at 7:15 PM

I got this working.. but let me try your version as well.

http://nupack.codeplex.com/SourceControl/network/Forks/erichexter/np2

Sep 27, 2010 at 7:29 PM

This worked for me as well.

if (request.Proxy != null) {
    request.Proxy.Credentials = System.Net.WebRequest.DefaultWebProxy.Credentials;
}
I just do not know if that could hurt a proxy that is not NTLM.  My changeset tried the approach of only setting those on a failure.
Developer
Sep 29, 2010 at 7:00 AM
Edited Sep 29, 2010 at 7:57 AM

I'm gonna check this fix in for now. If we see issues from customers we'll change it then.

Sep 29, 2010 at 7:07 PM

The current build works for me on the NTLM based proxy server!!! Close that issue out.

Sep 29, 2010 at 9:19 PM

Will do.

Coordinator
Oct 25, 2010 at 6:58 PM

This issue was re-opened and we're having trouble reproducing it. Does anyone here have an environment that can reproduce this that we can remote into? http://nupack.codeplex.com/workitem/231

We need to understand exactly what the issue is and what we need to do to fix it.

Oct 26, 2010 at 10:15 AM
haacked wrote:

This issue was re-opened and we're having trouble reproducing it. Does anyone here have an environment that can reproduce this that we can remote into? http://nupack.codeplex.com/workitem/231

We need to understand exactly what the issue is and what we need to do to fix it.

Dear Guys,

I'm the one opened the Issue no. #231 . As from my understandings, the "missing piece" could be the one creating Network Credentials to pass to the Proxy (in the class 
HttpWebRequestor / InitializeRequest method ).

Proxy Credentials should be set by the end-user thru a custom command / cmdlet or thru an Option page for NuPack Extension.

I've never developed a VS Extension before but ALL our piece of software are aware of Proxies like the one we use internally (Basic Authentication). 

My (useless? :)) 2 cents.

Igor.

Oct 26, 2010 at 3:09 PM

I am getting this error using the latest build from my corp environment. I will step through the code.

Coordinator
Oct 26, 2010 at 5:22 PM

@igoran, Yeah, I think this will need to be another option. I'm not sure what is required. Do you have a screenshot for how you configure your other proxies? Is it just an URL?

Oct 26, 2010 at 5:37 PM

haacked,

normally, we set the following information to be used for a Proxy:

  • Proxy URL
  • Proxy Port (eventually included in the URL)
  • Proxy UserName / Password
  • Checkbox to "bypass proxy for local address" 

All these information will be used thru the NetworkCredential / Proxy properties for the WebRequest (as in my previous post in this thread).

If you prefer, I can post / send source code for a "Proof of Concept" of a tool retrieving a web page / anythingelse thru an HTTP Proxy with Basic Authentication.

Probably you already know how to do that ... it'd be just a little contribution to a great project :-)...

Oct 26, 2010 at 6:09 PM

@Erci: that probably got broken when we moved to oData.  We need to add similar logic in that code path as we added in the non-oData code path.

 

@igoran: are you seeing this with the official non-oData build as well, or just the latest?

Developer
Oct 26, 2010 at 6:18 PM

@Eric, you shouldn't have been broken since we used the same code for odata when configuring the WebRequest. I'm curious to see what your find.

Oct 27, 2010 at 6:15 PM

I stepped through the code and it was an issue with setting up the feed url properly.. Once I added the odata/v1 to the url. everything worked.  I missread the exception comming back from the feed. So it looks like the current bits work with the windows auth proxy.

Oct 27, 2010 at 6:41 PM

Thanks Eric.  So that leaves igoran's issue as unsolved.  Normally, if you set up your proxy correctly in the IE settings, we should be picking it up.  If you can debug your scenario, maybe we can get to the bottom of it.

Jan 7, 2011 at 8:58 AM

This does not work on our proxy but I have an example of what does work.

I have not yet downloaded the nuget source but I have a proof of concept.

It is VB.Net however.

Console.WriteLine("Opening stream")
Dim webReq = WebRequest.Create("http://wiki.lessthandot.com/index.php/Special:WikiFeeds/rss/newestarticles")
webReq.Proxy = New WebProxy(proxyaddress, portnumber)
webReq.Proxy.Credentials = New NetworkCredential(username, password)
Dim stream = webReq.GetResponse.GetResponseStream
Dim dat As New DataSet()
Console.WriteLine("reading stream")
dat.ReadXml(stream)
Console.WriteLine("writing stream")
Console.WriteLine(dat.Tables(0).Rows(0).Item(0))
Console.WriteLine(dat.Tables(0).Rows(0).Item(1))
Console.ReadLine()

Is it possible to add this? Or should I fork it?

Coordinator
Jan 7, 2011 at 5:06 PM

When you use Internet Explorer to browse a site, does it work? As I mentioned before, we should be picking up the same proxy credentials that IE uses. So if you can browse with IE, NuGet should work. So can you try browsing with IE and let us know what happens?

Jan 7, 2011 at 7:18 PM

I don't really use IE. IE has been setup to connect to the internet and updates and such work just fine. The credentials never get saved by IE just the proxyaddress and portnumber. Could be that it only works if IE is open but that is far from ideal.

As I said I will give more feedback on tuesday. In case it might help it is a squidproxy.

Jan 7, 2011 at 7:25 PM

Is it a proxy with an auto configuration script set up in IE?

If you could attach a picture of your ie connections settings minus any sensitive data that might be helpful.

We had an auto configuration script in IE and had to do something different with firefox, git, svn, and other tools to set up their proxies.

That was before opendns.

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

Jan 7, 2011 at 7:33 PM

No it isn't an autoconfig file, everything is set via a grouppolicy for IE, all other things like FF, Git (tortoisegit), SVN get their own setup.

Jan 7, 2011 at 7:33 PM

And I will post it on tuesday but it is pretty standard.

Jan 12, 2011 at 10:24 AM

OOps is it wednesday already. Anyway

I openend IE8 and can surf normally. I tried to go to the online nuget packages and still get a Remote server returned an error: (407) Proxy Authentication Required.

I have an image of the proxysettings here http://forum.lessthandot.com/viewtopic.php?f=121&t=13416 it also works without the config script (the internet not nuget).

 

BTW the latest news page on the start page does give me some information albeit the last one was from dec 17 2010 and without asking to log in.

I guess I will have to download the sourse and figure it out myself huh ;-)

 

Jan 13, 2011 at 9:30 AM

So I downloaded the source and got to it. I made a small project and copied HttpClient into it and set about testing it.

The problem I'm having is well documented. http://dasgarner.blogspot.com/2008/03/webrequest-proxy-authentication.html and http://ilvyanyatka.spaces.live.com/Blog/cns!1pd2dVb-lPLLY1vqAckmYW8A!124.entry?sa=192146346 among others. Our credentials are just not cached. In short CredentialCache.DefaultCredentials only works with NTLM but not with other types of authentication. And I guess I'm on the other types of authentication (for now anyway).

The solution I found to do this

if (request.Proxy != null)
{
  // If we are going through a proxy then just set the default credentials
  request.Proxy.Credentials = CredentialCache.DefaultCredentials;
  // if the defaultcredentials are empty we will have to provide them
  if (String.IsNullOrEmpty(request.Proxy.Credentials.GetCredential(request.RequestUri,"NTLM").UserName))
  {
    request.Proxy.Credentials = new NetworkCredential(Settings.Username, settings.password);
  }

I'm pretty sure the above will not break the NTLM authentication but I can't test.

but I still need to test it behind a none-proxy and I will have to either make it possible to store the username and password in a config file somewhere or to ask for them on connecting. ASking for them would be the more difficult option. Making it a setting somewhere would be eassier.

Do you guys see a problem with this approach? What would be the best approach?

Feb 8, 2011 at 8:21 AM

Can anyone confirm this works with an NTLM proxy, I would like to have this added to nuget but I have no way of checking if this works with NTLM, otherwise nuget is useless to me and other people with non-NTLM proxies.

 

Thanks for considering my request.

Mar 30, 2011 at 11:44 PM

haacked,

Thanks for replying to my email.
I guess I just wanted to continue working on a solution to this one problem that looks like a few people are running into.
In your response to my email you've mentioned that NuGet is using the same proxy settings as Internet Explorer to make requests which makes total sense
as long as the proxy server is capable or is properly setup to pass through the user's credentials when a web request is made.
However in a situation where that is not the case then the user get's prompted to provide credentials to this proxy in order for IE to be able to successfully navigate
to the requested url which is the case for me and it seems like a few other people.
The current implementation of the HttpClient in NuGet code is currently assuming that using default credentials is sufficient.

There are many ways to get around this issue but one nice way that I've found however is to set the WebRequest.DefaultWebProxy static property
to the correct proxy settings that will allow the request to be successfully generated. Setting this static DefaultWebProxy setting will automatically
set the Proxy settings correctly for any newly created WebRequest or derived from WebRequest object to the provided configuration.
This would enable a simple scenario where the Package Manager settings dialog box can expose to the user the functionality of saving and retrieving
of the required network credentials so that when a WebRequest is made it can automatically use the given credentials.

Any further thoughts or ideas around this issue and how we can go about resolving this problem are greatly appriciated as I would love to be able to use
NuGet in my corporate environment.

Coordinator
Mar 31, 2011 at 12:07 AM

Windows has a Proxy Credential store called the Credential Manager Service. I “thought” you could add credentials to that and it would just work.

However, I’m no expert on Windows Networking. Anyone know of anybody who is? If we implement this, we want to get it right.

One concern we have is how do we store these credentials securely? We don’t want to get in that business unless we absolutely have to. But if there’s no other way to do it, we’d be happy to look into it.

In fact, I have a fork (though probably very outdated) that implements a dialog for setting Proxy credentials: http://nuget.codeplex.com/SourceControl/network/Forks/Haacked/HaackCredentialsDialog

Phil

Mar 31, 2011 at 1:22 AM

Phil,

I have not tried to use the "Credential Manager" functionality with NuGet or "Manager Passwords" feature in Windows XP (which is what I am stuck with at work still) to get NuGet to see the outside world.
I will try that once I am back in the office.
Just fyi I found another example of using the Credential Management API with full source code that we might be able to leverage in order to securely store the credentials for the user.
You can find the implementation here: http://www.developerfusion.com/code/4693/using-the-credential-management-api/

One other thing that I would like to mention and this is just my personal opinion as a user is that I would hate to be prompted by a separate dialog box for credentials and would rather want
to be able to control the proxy settings from a dialog box in the options page somewhere so that I can change it any time I wanted to from within visual studio and not have to rely on using
a feature that is not part of visual studio or NuGet to get this functionality however I am not sure how that would work for the command line version of NuGet.

Apr 5, 2011 at 10:26 PM
Edited Apr 6, 2011 at 12:11 AM

The issue is that the CredentialCache.DefaultCredentials property applies only to NTLM, negotiate, and Kerberos-based authentication.  From the MSDN documentation page it specifically states "This method does not work for HTTP or FTP protocols."  So if your corporate firewall happens to support supplying proxy credentials using one of those mechanisms, you're good to go.  But there are many of us out here who simply have to supply our plain text credentials each time.  Personally, I am comfortable with being prompted for my credentials each time I need to download a packge (I'm already prompted every time Visual Studio needs to check for updated versions of Extension Manager plugins as well as when the Start page attempts to download the news feed).  My corporate policy forces me to change my password so often that I never check the "Remember My Password" type options when presented with them (it's a sure way to get my account locked out the next time I do change it and the software that remembers it "helpfully" retries more than 3 times with my old password).  So may I suggest at the minimum incorporating the logic that has been floating around for some time where in the presence of a non-null Proxy object on the WebClient you  test for the existence of non-null NetworkCredentials under that and if not found you prompt the user to enter just the username and password? (You don't need to deal with any other proxy settings as those are all managed through Internet Explorer and respected by the WebClient).  If you want to offer a "Remember My Password" option, then you would want to leverage DPAPI through the System.Security.Cryptography.ProtectedData class (a good example of using it is posted on Jon Galloway's blog at http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx under the section titled Encrypting Strings With ProtectedData).

Hope this helps and please do consider implementing this...otherwise many of us have to wait until we go home every day to be able to download a new package...

Cheers,

-Brian

Coordinator
Apr 6, 2011 at 12:29 AM

Thanks Brian! That's the best description of the issue we've had and now it finally makes sense to me. We already have an issue in our backlog. http://nuget.codeplex.com/workitem/231

I removed it from our backlog so that our triage team will see it again.

Apr 6, 2011 at 3:34 AM

If I understand Brian's exposition correctly it doesn't fully match my experience with this issue.

We're behind a Threat Management Gateway proxy at work, using NTLM to pass AD credentials to the proxy before allowing http traffic.  Downloading NuGet packages under this configuration from within Visual Studio, either using the console or either of the Add Library Package Reference links, fails every time.  I can access the feed in a browser without any difficulty.

The workaround I'm using now is to use NuGet Package Explorer to save the package I'm interested in to our network share/uGet feed, and then install it from there.  This always works, but is a little bit cumbersome....

Coordinator
Apr 6, 2011 at 4:10 AM

Could it be that your threat management proxy is actively blocking .nupkg files since it doesn’t recognize them?

Apr 6, 2011 at 4:59 AM

I wouldn't think that's it, since I can get them with Package Explorer, but I can confirm with our proxy administrator.

Coordinator
Apr 6, 2011 at 5:00 AM

Ah, so Package Explorer works, but NuGet dialog doesn’t? That’s odd. Yeah, any information you can get would help. If PackageExplorer works, we need to understand why that does and NuGet doesn’t.

Apr 6, 2011 at 7:30 AM

Yes, that's quite odd as they use the same logic to make requests. Two things to try:

  1. Does it work using the 'nuget.exe install' command?
  2. If you run fiddler in the working vs non-working cases, do the requests look much different?
Apr 6, 2011 at 7:41 AM

@corischlegel: In VS, when you open the dialog, do you even see the packages listed? I'm trying to figure out if it fails while downloading Odata feed or fails downloading package bytes.

This is important because Package Explorer uses the same code to load OData feed as NuGet, but it has different code to download the package bytes.

Apr 6, 2011 at 2:51 PM
Edited Apr 6, 2011 at 3:10 PM

@corischlegel: Actually, my real point wasn't so much about the CredentialCache working with proxies that support NTLM/Kerberos/Challenge auth (like Forefront in your case) but rather that it definitely does *not* work with proxies that support only basic auth.  I would recommend (as has been mentioned above) that you try to capture a trace with Fiddler or Wireshark.  It's hard to know what exactly is going on in your case...it could be anything from administrator-defined policy to problems with using different pooled TCP connections during a multi-round authentication (that's less likely to be the case...I just recall that being a problem with an older build of the Chrome browser).

Oh, and silly question but I assume you are using Internet Explorer when you say you are able to get at them through a browser?  Just want to make sure you're using the same client side proxy settings as what the WebRequest would be using.

Cheers.

Apr 6, 2011 at 3:11 PM

Yes, I do get the package lists in both the Add Library Package Reference in VS and the Package Explorer window.

I'll post more details later when I have a few minutes to trace the requests with Fiddler.

Apr 6, 2011 at 5:54 PM

OK, that's what I expected. So here's the deal. In NuGet, the code to download package bytes has this snippet:

            if (request.Proxy != null) {
                // If we are going through a proxy then just set the default credentials
                request.Proxy.Credentials = CredentialCache.DefaultCredentials;
            }

Apparently, it always uses default credentials. Maybe that's why it doesn't work for your case.

Package Explorer, on the other hand, doesn't set the credentials at all. This is an oversight on my part, but lucky that it works for your environment :)

We'll try to fix this in NuGet 1.3

 


Coordinator
Apr 6, 2011 at 5:58 PM

I thought we added that bit of code to ensure that downloading worked in environments with NTLM proxies. Wasn’t this the fix for a bug that Hexter created?

http://nuget.codeplex.com/workitem/96

Apr 6, 2011 at 6:30 PM

Yes, as BrianHartung pointed out, the default crendential work for NTLM proxies but does not for basic auth ones.

Apr 6, 2011 at 6:44 PM

So many different types of proxies... The hard part will be to do proper testing on all the various scenarios, since it's non trivial to set up the environments. We'll need to enlist the help of various users to make sure we cover all cases.

Apr 6, 2011 at 6:57 PM

I'm more than happy to pitch in for the basic auth style scenario.

Apr 6, 2011 at 7:19 PM

Brian, can you try installing Package Explorer (http://nuget.codeplex.com/releases/view/59864) and see if you can download packages through your proxy?

Apr 6, 2011 at 8:09 PM

Sure.  My first attempt to download Package Explorer failed because I am currently behind the firewall.  In a moment I'll connect from outside the firewall just so I can get it installed and then I'll try actually downloading a package from back behind the firewall and I'll post my results.  For reference, here are the error details I got from the attempt using the ClickOnce link:

 ERROR DETAILS
        Following errors were detected during this operation.
        * [4/6/2011 3:03:20 PM] System.Deployment.Application.DeploymentDownloadException (Unknown subtype)
                - Downloading https://nuget.codeplex.com/releases/clickOnce/NuGetPackageExplorer.application did not succeed.
                - Source: System.Deployment
                - Stack trace:
                        at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem next)
                        at System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
                        at System.Deployment.Application.FileDownloader.Download(SubscriptionState subState)
                        at System.Deployment.Application.DownloadManager.DownloadManifestAsRawFile(Uri& sourceUri, String targetPath, IDownloadNotification notification, DownloadOptions options, ServerInformation& serverInformation)
                        at System.Deployment.Application.DownloadManager.DownloadDeploymentManifestDirectBypass(SubscriptionStore subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState, IDownloadNotification notification, DownloadOptions options, ServerInformation& serverInformation)
                        at System.Deployment.Application.DownloadManager.DownloadDeploymentManifestBypass(SubscriptionStore subStore, Uri& sourceUri, TempFile& tempFile, SubscriptionState& subState, IDownloadNotification notification, DownloadOptions options)
                        at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
                        at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
                --- Inner Exception ---
                System.Net.WebException
                - The remote server returned an error: (407) Proxy Authentication Required.
                - Source: System
                - Stack trace:
                        at System.Net.HttpWebRequest.GetResponse()
                        at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem next)

Apr 6, 2011 at 8:15 PM

If you have trouble installing through ClickOnce, you can download the bits directly from our CI machine (http://ci.nuget.org:8080/repository/download/bt4/1553:id/PackageExplorer/PackageExplorer.zip). Download it, unblock it, unzip it, and run the .exe file.

Apr 6, 2011 at 8:26 PM
Edited Apr 6, 2011 at 8:29 PM

I am also having trouble installing using ClickOnce but I was able to successfully download and run the Package Explorer from the CI server however I am not able to see/open
the list of packages when I click on "Open From Feed" menu item.
Another issue that I've noticed is that when I try to navigate to the URL provided in the "Select package" window when you click on "Open From Feed" menu item using IE 7
The URL is: https://go.microsoft.com/fwlink/?LinkID=206669
I get the following message.

The XML page cannot be displayed

Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.


Access is denied. Error processing resource 'https://go.microsoft.com/fwlink/?LinkID=206669'.

However when I go directly to the packages feed: http://packages.nuget.org/v1/FeedService.svc/

I get the correct data coming back.

Apr 6, 2011 at 8:31 PM

I was able to download and install successfully once I got out from behind the firewall.  Before going back behind the firewall, I also opened the feed list and downloaded the EFCodeFirst package just fine.  Then I got back behind the firewall and now whenever I choose the Open From Feed option and click the Refresh button, nothing happens.  I performed a Fiddler trace and all that's happening is a CONNECT go.microsoft.com:443 is being issued and an HTTP response code of 0 is returned...classic symptom of a proxy being in the way with no auth header having been included.

Apr 6, 2011 at 8:32 PM

@ilyalozvyy: Are you also behind proxy? Does your proxy modify any of the reponse header? Can you send us the Fiddler trace?

Apr 6, 2011 at 8:36 PM

@BrianHartung: OK, that matches my expectation. However, when downloading package feed data, Package Explorer does set proxy credential but it sets to the default credential as in the code I provided above.

Apr 6, 2011 at 8:54 PM

dotnetjunky,

Yes I am also behind a proxy with basic authentication and this is what I am seeing.

I get 3 items showing up when try to navigate to this url

  1. Navigating to url
    CONNECT go.microsoft.com:443 HTTP/1.0
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
    Proxy-Connection: Keep-Alive
    Content-Length: 0
    Host: go.microsoft.com
    Pragma: no-cache
  2. Get Prompted for credentials
    CONNECT go.microsoft.com:443 HTTP/1.0
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
    Proxy-Connection: Keep-Alive
    Content-Length: 0
    Host: go.microsoft.com
    Pragma: no-cache
    Proxy-Authorization: Basic [ENCODED PASSWORD DELETED]

    The data sent represents an SSLv3-compatible ClientHello handshake. For your convenience, the data is extracted below.

    Major Version: 3
    Minor Version: 1
    Random: 4D 9C C0 90 E1 3F BE 0B E0 05 DE 51 62 A8 A5 3A 57 51 AB 73 59 D7 51 2C 9A 3A 1B AD 35 17 6B 70
    SessionID: empty
    Ciphers:
        List of Ciphers listed here
  3. Credentials provided and now I am able to see the content of the feed
    GET http://packages.nuget.org/v1/FeedService.svc/ HTTP/1.1
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-quickviewplus, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
    Accept-Language: en-us,fr-CA;q=0.5
    UA-CPU: x86
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
    Host: packages.nuget.org
    Proxy-Connection: Keep-Alive
    Proxy-Authorization: Basic [ENCODED PASSWORD DELETED]
Apr 6, 2011 at 9:19 PM

For now, we know that NuGet and Package Explorer don't work with basic auth proxy at all. I don't know why IE7 doesn't load package feed for your case. I'm really no expert on that. Maybe try installing IE9? :)

So here's the plan. I'll try to implement the credential dialog in Package Explorer for two of you to try. If it works, then we'll do it for NuGet. Stay tuned.

 

Apr 6, 2011 at 10:00 PM

@dotnetjunky: Awesome thanks for looking at this issue for us. Let me know if I can be of any assistance in implementing this feature I will be glad to help.

Apr 6, 2011 at 10:15 PM

Just in case you haven't seen it, I'd suggest taking a gander at Kenny Kerr's managed wrapper to the Credential Management API at http://msdn.microsoft.com/en-us/library/aa480470.aspx.  Also, as explained on the MSDN page for the CredUIPromptForCredentials call (http://msdn.microsoft.com/en-us/library/aa375177(v=vs.85).aspx) there's a newer version called CredUIPromptForWindowsCredentials that respects the current Vista/Win7 style (the former call which is the one used in his article is specific to XP/2003).

Also, I discovered that the approach outlined earlier in this thread (where you take the DefaultCredentials object and call GetCredential(uri, "NTLM") and then look for a non-empty Username value) will not work because the Username will always be empty (unless you constructed the CredentialCache yourself but that doesn't apply here).  So it would seem that the best thing to do is detect the 407 response code (which is in the exception returned within your HttpClient::InitializeRequest method...I stepped through the code in a debugger to verify that) and prompt for credentials in response to that (not sure if you want to refactor the code around that).  Otherwise you'd be forced to do something like have the user specify in some settings dialog whether they want to use integrated or basic auth...no real need for that.

Cheers,

-Brian

Apr 6, 2011 at 10:27 PM

Thanks for the tip, Brian. Since you can repro it in your environment, and you already steppe through the code, I wonder if you can try implementing the credential dialog yourself and see if it works? We have difficulty setting up a proxy with basic auth on our end. Let me know.

Apr 6, 2011 at 10:30 PM

Sure...sounds fun.  I won't be able to get to it until tomorrow though...I've actually got a hallpass tonight and there's a tall glass of Guinness with my name on it. :)

Cheers!

-Brian

Apr 6, 2011 at 10:36 PM

Great, thanks. No pressure. Let us know if you need explanation on the code.

Coordinator
Apr 6, 2011 at 11:07 PM

Enjoy your Guiness!

When you get around to implementing this, be sure to check out the Contributing to NuGet section below for help in setting up your dev environment etc. http://nuget.codeplex.com/documentation

Summary: Create a fork, implement it there, submit a code review, submit a pull request, get your kudos (http://www.ohloh.net/p/nuget/contributors)!

Apr 7, 2011 at 12:02 PM

Hi Guys,

I'm the one opened the discussion as I'm in the same scenario as BrianHartung. 

If you need one more tester for the Basic Authentication Proxy, I can download any test version of the nuget / Package Explorer and test it...

Thank you

Igor.

Apr 7, 2011 at 2:10 PM
Edited Apr 7, 2011 at 2:12 PM

OK, I was finally able to repro my issue and capture the details.

There are two separate problems that I'm dealing with as far as I tell, and the behavior that I see isn't always consistent, but here's what I captured.

  1. The ssl issue (documented in a different thread, if I recall correctly) is a blocker for the https url for the feed.  My machine cannot negotiate a secure channel through the proxy for either client (VS/NuGet or Package Explorer). I suspect that's got something to do with ssl certificate validity, and it's possible that I could resolve it at the machine level, but it's also possible that the proxy won't let me connect at all..  However if I switch to the http url for the feed it works like a charm, at least while I had fiddler on.
    1. When I have fiddler turned off, I can't get the list from even the non-ssl url, which respond with the error message in this screenshot: http://kinrowan.net/miscellany/nuget/vs-nuget-log4net-search.png
  2. Searching for a package in VS/NuGet did not work at all, no matter what address returning the same error message noted above. Interestingly, even though I have log4net in my network drive package source, once the VS client encounters this error for the NuGet source it bails and doesn't search locally, no matter what order I have the sources in. Searching in Package Explorer works fine.
  3. Downloading the found-by-search log4net package in Package Explorer worked great. when I got the package list in VS and browsed it to where log4net was, the first hit to install failed.  When I clicked install again it worked fine.  This is not consistent for what I experienced when trying to download Json.net a week ago, where repeated install attempts failed.  However there were other things that were different (I don't think I had to change the url, for one, and still got the list).

Sorry this is a little scattery, but as I said my experience isn't consistent, so I'm trying to get the best info out there.

FWIW, I don't think the 407 response mechanism will be ideal for NTLM proxy users - if I understand NTLM correctly the response to the first connection attempt is always a 407 which the client is supposed to respond to with the credentials. If you pop a dialog after the 1st 407 then you'll be popping a dialog for NTLM users who shouldn't need one at all.

I've loaded the fiddler capture archives at http://kinrowan.net/miscellany/nuget/packageexplorerlog4net.saz and http://kinrowan.net/miscellany/nuget/vslog4net.saz.  If I can trace something else I would be happy to do so, and also would be happy to guinea pig solutions against my use-case, to whatever extent that's helpful.  I would definitely be interested in helpign develop the solution, but it's probably not realistic that I will be able to do so in the short term. However thanks for the link to the contribution docs above.

Thanks!

cori

Apr 7, 2011 at 3:38 PM

@Cori: You raise a good point.  I wonder if we can eliminate the initial round of "papers, please!" using the UseDefaultCredentials and/or PreAuthenticate properties.  Then there's the whole Expect100Continue issue (near and dear to Phil's heart)...not sure if that might be going on with squid proxy issue reported up above.  This is clearly going to take some testing...</obvious_conclusion>

Coordinator
Apr 7, 2011 at 4:40 PM

We really appreciate the investigation folks. This is something we’ve been wanting to fix but it’s very hard for us to set up an environment to repro it. J

Apr 8, 2011 at 1:07 AM


In that case, what's the best way to distinguish NTLM proxies from Basic Auth proxies? Or is it even possible?

Apr 8, 2011 at 2:08 AM

@dotnetjunky: Would it be bad if one was to try the round robin approach and try one method first and then the others until you get a successfully response? Based on the number of scenarios that i've been seeing in this thread is that we are running into a situation where
the person either has NTLM authentication or Basic and we can try to implement the NTLM by default and if that fails then fail over and ask the user for basic and see if that works. This should solve most of the cases.

Apr 8, 2011 at 2:28 AM
Edited Apr 8, 2011 at 2:28 AM

Yeah, I was thinking along those lines as well.  But I have to say after having spent a good couple of hours researching this issue, this is an extremely common problem and based on the volume of questions out there (90+% of which are "hey I'm having that too...did you ever figure it out?" with no reply), it's not at all straightforward.  I've seen a lot of common themes: HttpWebRequesting to an SSL endpoint via a proxy server that supports NTLM is the most frequent problem scenario...lots of mentions of squid proxy, ISA, "NTLM auth requires keepalives", "mismatch in encryption levels supported between proxy and client", client OS versions ("it works on XP/2003 but not on Win7"), , ".net 4 solves it, there was a bug in 2.0/3.0/3.5"...no definitive answers I've seen yet.  I'm going to keep plugging away though.  More to come...

Apr 8, 2011 at 4:07 AM

OK, sounds good. We can try that round robin approach. So what is the error code when the NTLM request fails?

Apr 8, 2011 at 2:58 PM
Edited Apr 8, 2011 at 4:20 PM

Based on some of the discussion above (in particular the part about not having used the DefaultCredentials trick being lucky and explaining why it worked), I'm thinking the sequence of operations should be:

1) Just send the request, no explicit credential manipulation

2) If we get a 407 back, then assign DefaultCredentials and try again

3) If we still get a 407, pop the dialog and gather explicit credentials.

Clearly the first case works best for non-proxy users (and at least the one case discussed above).  In theory the only ways to get to the third case are if 1) you really do need basic auth, or 2) you really are passing the wrong credentials (maybe you're impersonating or flat out have to supply different credentials for the firewall than what you're logged in as)...either way it would behave just like hitting an IIS page using integrated auth where you don't have permission and you get a prompt for credentials.  We'll also want to do some testing where we play around with some of the other settings like PreAuthenticate, Expect100Continue, KeepAlive...just to try to maximize test coverage.  As I mentioned before, I have access to a proxy that requires basic auth...I know Cori has access to NTLM/ISA.  We'll need someone with a Squid proxy to volunteer as well.  Anyone see any other issues (e.g. do we need to consider any other response codes like 417, are we putting anyone at undue risk for account lockout using this approach, etc.)?  Clearly we'll need to handle other errors than proxy authentication required (e.g. maybe they fat-fingered the password and need to be re-prompted)...Ultimately I'd like us to end up with a user experience in the error case other than "nothing seems to happen".

(I keep hoping for some kind soul to swoop in and say "hey morons, you're making this way too complicated...you just keep forgetting to assert the undocumented "make-it-work bit")...

Coordinator
Apr 8, 2011 at 4:48 PM

I’ll tweet about this and see if any experts come in to help. J

From: BrianHartung [email removed]
Sent: Friday, April 08, 2011 6:58 AM
To: Phil Haack
Subject: Re: Support for a corporate http proxy [nuget:227886]

From: BrianHartung

Based on some of the discussion above (in particular the part about not having used the DefaultCredentials trick being lucky and explaining why it worked), I'm thinking the sequence of operations should be:

1) Just send the request, no explicit credential manipulation

2) If we get a 407 back, then assign DefaultCredentials and try again

3) If we still get a 407, pop the dialog and gather explicit credentials.

Clearly the first case works best for non-proxy users (and at least the one case discussed above). In theory the only ways to get to the third case are if 1) you really do need basic auth, or 2) you really are passing the wrong credentials (maybe you're impersonating or flat out have to supply different credentials for the firewall than what you're logged in as)...either way it would behave just like hitting an IIS page using integrated auth where you don't have permission and you get a prompt for credentials. We'll also want to do some testing where we play around with some of the other settings like PreAuthenticate, Expect100Continue, KeepAlive...just to try to maximize test coverage. As I mentioned before, I have access to a proxy that requires basic auth...I know Cori has access to NTLM/ISA. We'll need someone with a Squid proxy to volunteer as well. Anyone see any other issues (e.g. do we need to consider any other response codes like 417, are we putting anyone at undue risk for account lockout using this approach, etc.)?

(I keep hoping for some kind soul to swoop in and say "hey morons, you're making this way too complicated...you just keep forgetting to assert the undocumented "make-it-work bit")...

Coordinator
Apr 8, 2011 at 4:51 PM

Actually, ask the question on http://stackoverflow.com/ and post the link here. That provides good incentive for people to answer. :) Then I can tweet about it to help drive people to the question. J

Apr 8, 2011 at 4:54 PM

Hi Haacked,
I'd be a volunteer as squid user ...

I initiated the discussion / request as I'm behind a proxy (squid) with Basic Auth in place...

Igor.

Coordinator
Apr 8, 2011 at 4:58 PM

Great! Are you volunteering to test as a squid user? Or volunteering to ask the question on StackOverflow.com? J

I think you can probably summarize the write-up that Brian Hartung has done in this thread to make a good question. Go get your Stack Overflow points!!! J

Apr 8, 2011 at 5:03 PM

Hi Phil,

I was proposing myself as volunteer to be a squid user BUT I'm very happy to get my "StackOverflow points" and summarize the whole issue.

I'll do it tomorrow as here in italy the day is coming to the end...

Please send me any temporary version of NuGet (or Package Explorer) I can test behind Squid Proxy.

Igor.

Coordinator
Apr 8, 2011 at 5:16 PM

Ah, I see. Well if you’re going to wait till tomorrow, might as well see if Brian can do it today as it’s morning here in the US. J

At any time, you can grab the latest build from here: http://ci.nuget.org:8080/viewLog.html?buildTypeId=bt4&buildId=lastSuccessful

Just click the Artifacts tab and select the VisualStudioAddIn node. I’m not sure this build will work for you yet, but worth reporting back what you find. J

Apr 8, 2011 at 5:33 PM

Actually, this question has been asked many, many times on S.O.  It was one of the first places I checked when I started researching.

Coordinator
Apr 8, 2011 at 5:37 PM

Is there one we should drive people to try and answer?

I thought our question might be different. The question we’re asking is if our round-robin approach is the best way, right? If there’s already a question out there, post the URL here and we’ll get the Hanselman-effect going and have him drive people to it. J

Apr 8, 2011 at 5:41 PM

I'll see if I can find something very close.  In any event, in my mind the Hanselman idea is strong to quite strong... :)

Apr 8, 2011 at 7:39 PM

After a couple more hours of reading, it became clear that the best folks to ask about this are over at the System.Net community forum since they own HttpWebRequest.  So here's the link to the question I posted in case you want to follow along from home.  http://social.msdn.microsoft.com/Forums/en-US/ncl/thread/7aba20d5-7e40-49fe-a180-5d653ffd3383

Apr 8, 2011 at 7:41 PM

Phil, could we contact the .NET team directly and ask them for their guidance on this issue?

Coordinator
Apr 8, 2011 at 7:44 PM

Yeah, I can follow up internally.

Phil

Apr 11, 2011 at 5:16 PM
Edited Apr 11, 2011 at 5:17 PM

I just posted a fix for the Package Explorer into my fork and I was able to test it out using Basic and No proxy setup.
It requires some testing with NTLM proxy so if anyone can test it that would be great.
Also let me know if the implementation is totally wrong and or something that you think
can change at least we can start getting a working implementation.
The code can be found here:
https://hg01.codeplex.com/forks/ilyalozovyy/proxy

Apr 11, 2011 at 5:52 PM

Very cool. Thanks for trying to look into my spaghetti code. :) I'll pull your fork and take a look. If others don't want to do this yourself, I can build it and provide a .zip file for you to try and test it.

Apr 11, 2011 at 6:52 PM
Edited Apr 11, 2011 at 6:53 PM

Just briefly read through the code. One question I have is in this snippet:

WebProxy ntlmProxy = GetSystemProxy(url);
ntlmProxy.UseDefaultCredentials = true;
ntlmProxy.Credentials = CredentialCache.DefaultNetworkCredentials;
If you already set UseDefaultCrednetials=true, why do you still need to set the Credentials property? According to MSDN (http://msdn.microsoft.com/en-us/library/system.net.webproxy.usedefaultcredentials.aspx), you don't need to set it if UseDefaultCredentials is true.
Apr 11, 2011 at 6:56 PM
dotnetjunky wrote:

Just briefly read through the code. One question I have is in this snippet:

WebProxy ntlmProxy = GetSystemProxy(url);
ntlmProxy.UseDefaultCredentials = true;
ntlmProxy.Credentials = CredentialCache.DefaultNetworkCredentials;
If you already set UseDefaultCrednetials=true, why do you still need to set the Credentials property? According to MSDN (http://msdn.microsoft.com/en-us/library/system.net.webproxy.usedefaultcredentials.aspx), you don't need to set it if UseDefaultCredentials is true.

Very good point. I guess I just wanted to ensure that the credentials are set. Since I can't really test the NTLM setup I would recommend that whomever actually does should test it without the UseDefaultCredentials property being set to true and we can update the code.

Apr 11, 2011 at 7:00 PM

I compiled ilyalozovyy's code and uploaded it here: http://nuget.codeplex.com/Project/Download/AttachmentDownload.ashx?ProjectName=nuget&WorkItemId=942&FileAttachmentId=227338. Others on this thread please try it on your proxy and let us know.

 

Apr 11, 2011 at 11:29 PM
Edited Apr 11, 2011 at 11:36 PM

@Ilya - That's a great start.  Here's a list of some of the things that I think still need to be worked through:

- I would consider abstracting your HttpClientUtility code in a couple of custom interfaces like ICredentialService and IProxyAuthService to facilitate automated unit testing (obviously you don't want a dialog popping up during test runs and it would make it easy to test the different proxy type permutations)

- For your proxy auth mode enum...I might consider using values like None, IntegratedAuth and BasicAuth since the one called NTLM really represents NTLM, Kerberos. and (at least half of) Negotiate.  Or maybe "SSPAuth" since interpreting the credential requires an SSPI.  Just a thought.

- As far as the current technique of issuing the user-specified URI as a test to sniff out the proxy type...I don't recall but are you ensuring it's only accessed successfully one time (well, at least only once as part of the Initialize sequence)?  I'm just thinking about the potential of having that URI accessed more than once...on the one hand it could result in extra network traffic but on the other hand there could be side-effects like the possibility of double-submission in cases like Package upload.  Also, are we forcing the request to be made prematurely?  As it stands in today's code, there's no explicit assumption in the interface that the user has to call GetRedirectedUrl so they could be instantiating the web request, initializing it, and then potentially doing other things before expecting it would ever go over the wire...wasn't sure if we could be short-circuiting that by sniffing out the proxy auth scheme as part of initialization.

- Consider putting in a check like the one you have with Environment.OSVersion and if the version is Vista or higher, call the newer CredUIPromptForWindowsCredentials function (which respects the newer user interface style)

- In digging through all the different places in Package Explorer and the NutGet Core that involve making any kind of remote call, there seem to be 3 different ways it's done: 1) using HttpWebRequest directly, 2) using the WebClient (an out-of-the-box wrapper over HttpWebRequest that makes certain things like Progress Reporting a little less syntax-intensive at the cost of a little less control) as is the case with the GalleryService, and 3) using WCF Data Services (which internally wrap HttpWebRequests and expose them in an argument passed to the SendingRequest event, an example of which is in the DataServicePackageRepository::OnSendindRequest method).  We need to ensure that all of these places leverage this new service.

- I would suggest not attempting to use the GetSystemProxy call.  In the .NET 1.1 days, it was necessary to get involved in the proxy determination process only because it lacked full support for autoconfig scripts and the like.  Ever since .NET 2.0 however, a lot of work has gone into the detection algorithm and it is the expectation that the default value of the HttpWebRequest.Proxy object is for all intents and purposes exactly what Internet Explorer would have come up with (there being a couple of small edge cases like the way bypass strings are interpreted).  In addition, there's always the possibility that an administrator has disabled default proxy detection in a machine.config file for example and inserted some other custom configuration.  We could be unintentionally defeating that if we tried to imperitively mess with the proxy object.  If anything, by leaving it alone, the System.Net config file section can be the last line of defense allowing a customer to fine tune anything beyond the default settings that would have otherwise been detected.

There are probably more things to think through...this was just what I came up with off the top of my head.

Cheers,

-Brian

Apr 12, 2011 at 1:12 AM

Brian, thanks for the detailed analysis. Have you tried the code I posted in your environment? Did it work?

Note that at this state, we're more focused on determining the right workflow to detect the proxy and ask for credentials. The actual implementaiton is not important for now.

Apr 12, 2011 at 2:23 AM

Yes, I tested the current build and it works in my environment.  I was able to test it much like Ilya...with no proxy at all and again with a proxy that supports basic auth.  I was able to browse the package feed and download a package under both scenarios.

Apr 12, 2011 at 2:27 AM
Does it ask you to type password every time? We will need to implement the remember password feature too.

Sent from either Windows Phone or iPhone. You don't know.

From: BrianHartung
Sent: Monday, April 11, 2011 6:23 PM
To: Luan Nguyen
Subject: Re: Support for a corporate http proxy [nuget:227886]

From: BrianHartung

Yes, I tested the current build and it works in my environment. I was able to test it much like Ilya...with no proxy at all and again with a proxy that supports basic auth. I was able to browse the package feed and download a package under both scenarios.

Apr 12, 2011 at 2:39 AM

It only asked me to provide a password when the proxy was there.  And as for the remember password feature, it's already built in to the Credentials Management API.  Ilya put the PInvoke signatures directly in the code...if you want to leverage Kenny Kerr's component (a wrapper written in Managed C++...one benefit being it's time tested and includes its own unit tests), you can download source and binaries from MSDN: http://msdn.microsoft.com/library/aa480470.aspx.

Apr 12, 2011 at 3:05 AM

I have actually downloaded Kenny Kerr's component last weekend and integrated it into Package Explorer. However, as far as I understand from the code, the remember password is an all or nothing feature. If we want it to remember password, we have to hide the "Remember password" checkbox. Which means you can't opt to not to remember password. Or am I missing something?

 

 

Apr 12, 2011 at 3:22 AM

@dotnetjunky: I'll take a look at Kenny Kerr's library and see if I can easily integrate it into the current code that I have. It seems that at least in Windows 7 if you select the remember password checkbox then it persists it and what we can do is if we detect that the credentials are not working then we can turn on a flag and re-display the credentials dialog box to the user again however it would be up to the user to make sure that they don't lock out their account. If the user decides that they no longer want to persist the credentials then they can go to the manager network passwords settings and remove the credentials from there. The only thing is I would have to test this out in Windows XP which is what we are still using at work.

I also have to try and re-compile the library in .NET 4.0 as it is complaining right now that it is not able to run in mixed .NET framework configuration and I can either add configuration settings or just recompile in .NET 4.0

Apr 12, 2011 at 3:35 AM
I'm pretty sure it supports both scenarios depending on the values you pass to the ShowSaveCheckBox and Persist properties...I think the way the documentation is worded is what makes it confusing. I can play around with it tomorrow and validate my understanding but for now it's getting late and i have to be up early.

Good night all.

From: dotnetjunky
Sent: Monday, April 11, 2011 10:05 PM
To: bhartung@columbus.rr.com
Subject: Re: Support for a corporate http proxy [nuget:227886]

From: dotnetjunky

I have actually downloaded Kenny Kerr's component last weekend and integrated it into Package Explorer. However, as far as I understand from the code, the remember password is an all or nothing feature. If we want it to remember password, we have to hide the "Remember password" checkbox. Which means you can't opt to not to remember password. Or am I missing something?

Apr 12, 2011 at 5:13 AM

@ilya: I also had to re-compile the library in .NET 4.0. I had to make some small changes to the code to make it compile. I attach the library here so that you don't have to doit again. (http://nuget.codeplex.com/workitem/942)

Apr 12, 2011 at 5:39 AM
Edited Apr 12, 2011 at 5:40 AM
dotnetjunky wrote:

@ilya: I also had to re-compile the library in .NET 4.0. I had to make some small changes to the code to make it compile. I attach the library here so that you don't have to doit again. (http://nuget.codeplex.com/workitem/942)

@dotnetjunky: Thanks. I was able to rebuild the library without any problems. I did not bother trying to fix the Unit Tests :( but I'll leave it for someone more enthusiastic at this point its been a 20 hr day for me.
I've updated the code with the Kerr library for prompting of credentials and updated the code based on Brian's suggestions however some of them I did not implement like the Windows 7 style as I don't care for the looks at this point.
I think the next step once people can validate that the current code is working is to refactor the code a bit so it is unit testable an I think it might be better if we simply pass around the HttpClient object instead of using the WebRequest.DefaultWebProxy static property this way we can make sure that the settings are based on the per request basis and are not impacting other scope of requests. Let me know your thoughts and what else we can do to clean up.
I have updated my fork with the latest changes. Please take a look when you get a chance. I am going to sleep so that I can get up in 4 hrs.

Apr 12, 2011 at 5:48 AM

Thanks a lot. That's a great effort. I feel guilty that I make you lose your sleep.

Yeah, don't worry about the Windows 7 style. I can add it myself after we have verified that it works in all scenarios.

I agree that we shouldn't set the DefaultWebProxy directly because if we use it for NuGet, it would affect the whole VS. I'll take care of the refactoring.

I'll try to compile your fork and post it for others to try.

Apr 12, 2011 at 7:37 AM

That version from 8 pm works without even asking anything. Strange. Not sure where it gets it's credentials from.

Apr 12, 2011 at 12:44 PM
dotnetjunky wrote:

Thanks a lot. That's a great effort. I feel guilty that I make you lose your sleep.

Yeah, don't worry about the Windows 7 style. I can add it myself after we have verified that it works in all scenarios.

I agree that we shouldn't set the DefaultWebProxy directly because if we use it for NuGet, it would affect the whole VS. I'll take care of the refactoring.

I'll try to compile your fork and post it for others to try.

@dotnetjunky: Heh, I wouldn't do it if I did not enjoy it :).

@chrissie1: Do you know if you are behind an NTLM based firewall where your windows credentials are automatically used to login? or were you being prompted to always provide credentials? Also if you were prompted for the first time did you try and save your credentials? Try looking at the Manager Passwords windows configuration and see if you see a password for this location: "packages.nuget.org" this would indicate that your credentials are saved and you will not get prompted. I still need to refactor the code so that it checks the saved credentials and prompts the user for new ones if the saved are not working any longer.

Apr 12, 2011 at 2:21 PM
Edited Apr 12, 2011 at 2:21 PM

@Ilya...looking up above in this crazy long thread, Chrissie described being behind a non-NTLM squid proxy so at this point we still need someone who can represent the NTLM scenario.  Cori Schlegel did mention being behind one so that should be a good test.

Apr 12, 2011 at 2:49 PM

I am behind one - I'll try to grab the bits later today and give it a run-through....

Apr 12, 2011 at 3:14 PM
ilyalozovyy wrote:

 I still need to refactor the code so that it checks the saved credentials and prompts the user for new ones if the saved are not working any longer.


Would it be even better if we don't save the entered credential if it's wrong? I saw that the credential dialog has that option but I'm aware that it will make the code more complicated. If it requires too much code, then don't bother. We can just save by default, and re-prompt if it's incorrect, at least for now.

Apr 12, 2011 at 3:28 PM

@dotnetjunky:

That makes sense. I was also thinking about another scenario where if the user saved credentials and they are valid at the point and time when they are saving and then they change their credentials later basically invalidating their saved credentials then we need a mechanism to validate/invalidate the stored credentials also. The same mechanism can be used for both of these scenarios.

Apr 12, 2011 at 3:32 PM

Yes, it's really not much extra code..in order to do that you simply set the ExpectConfirmation property to true and then once you're satisfied the credentials are valid, you call ConfirmCredentials() and they'll be persisted.

Apr 12, 2011 at 7:53 PM

I'm on the non NTML variety and it never asked for any credentials it just worked. Not even FF or IE login automatically between sessions, no matter if you set it to remember the password. They always ask if you want to login. But that could be an implementation detail. This whole proxy thing is very weird. Anyway I hope squid dies soon.

Apr 12, 2011 at 8:05 PM
chrissie1 wrote:

I'm on the non NTML variety and it never asked for any credentials it just worked. Not even FF or IE login automatically between sessions, no matter if you set it to remember the password. They always ask if you want to login. But that could be an implementation detail. This whole proxy thing is very weird. Anyway I hope squid dies soon.

@chrissie1: This is very good news. I am hoping @corischlegel will be able to test this implementation from behind the Integrated Authentication/NTLM based proxy and we get some basic coverage of the most common scenarios that people are using this tool in.
In the mean time I have started refactoring the current implementation of the code that I wrote to make it easier to unit test and have already built in logic to persist credentials along with performing credential validation so that if the credentials are not valid then the user will be re-prompted to provide new credentials even if they were persisted.

Apr 12, 2011 at 8:08 PM

@ilya: That's great news. Thanks for take your time contributing to the project.

Apr 12, 2011 at 8:34 PM

I grabbed the binaries from http://nuget.codeplex.com/Project/Download/AttachmentDownload.ashx?ProjectName=nuget&WorkItemId=942&FileAttachmentId=227338, and it works as expected behind my NTLM-based proxy.  The 1.0.0.1 version I already had installed also still works (Package Explorer has always worked for me) so as far as I can tell there's no regression here.

Apr 12, 2011 at 8:40 PM

That's great news.  So the basic approach seems sound.  We got some good feedback on the System.Net community from a couple of the well-known guys there and it sounds to me like they agree with the approach as well.

Did anyone catch the MIX keynotes today?  A lot of nugety love from the Gu, Hanselman, and others...

Apr 12, 2011 at 8:59 PM

Fantastic. Once ilya posts hist final refactored code, I'll go ahead a pull it into both package explorer and nuget.

Apr 13, 2011 at 3:23 AM
dotnetjunky wrote:

Fantastic. Once ilya posts hist final refactored code, I'll go ahead a pull it into both package explorer and nuget.

@dotnetjunky: Well a few check ins later and some pain in my eyes from staring at the computer all day long I think I was able to refactor the code to make it a bit more testable and more readable. Hopefully someone besides me can understand it now :)
I was hoping that you can check out the latest changes in my fork and if you are happy with it then go ahead and post an additional build for people to play with since the refactoring was pretty significant.
Please let me know if you run into any issues or need me to look at something.

Apr 13, 2011 at 4:05 AM

Yup, I'll check out your changes and build a new drop from it. Been busy today with some other bug fixes.

Apr 13, 2011 at 3:20 PM
Edited Apr 13, 2011 at 3:20 PM
dotnetjunky wrote:

Yup, I'll check out your changes and build a new drop from it. Been busy today with some other bug fixes.

@dotnetjunky: Thanks. By the way I just checked in another change into the fork. Apparently I did not even try to open a package yesterday which downloads the actual package from the server and because we are no longer setting the HttpWebRequest.DefaultWebProxy static property this functionality stopped working. Thankfully my refactored code makes it easy to get the proxy now so I was able to add this logic to both the DownloadProgress window and the GalleryServer also. I was also wondering if there is a way to test publishing to the gallery server with a dummy package so that we can test all of the different proxy types?

Apr 13, 2011 at 4:53 PM

There is a command to publish package. Choose File - Publish.

Apr 13, 2011 at 6:13 PM
dotnetjunky wrote:

There is a command to publish package. Choose File - Publish.

:) Yep. I knew that there was a button to publish I guess what I was asking was about a test account that you might have to test this feature but I guess I've solved this issue by just registering a separate account for my self and just trying to publish using my own account. I simply pushed the package into the gallery not published it but I did not see it show up anywhere. Not sure if that is by design or not but the code was able to connect and push the data correctly. I have compiled and attached the debug build of Package Explorer to the following work item: http://nuget.codeplex.com/workitem/942 and so you can get it from there or click on this LINK.

Apr 13, 2011 at 6:40 PM

If you go to the Manage My Contributions link, you should see the unpublished packages there. http://nuget.org/Contribute/MyPackages

Apr 13, 2011 at 6:55 PM
dotnetjunky wrote:

If you go to the Manage My Contributions link, you should see the unpublished packages there. http://nuget.org/Contribute/MyPackages

Hmm Strange,

I've tried pushing multiple times and it seems to be happy and tells me that it pushed successfully but yet I don't see any packages showing up.

Apr 14, 2011 at 5:15 PM

Hmm, has others people on this thread tried the build that ilya uploaded? Can you try publishing packages and see if they appear on the My Contributions page?

Apr 14, 2011 at 6:32 PM
Edited Apr 14, 2011 at 6:33 PM

I got the same result...it looked like the package uploaded ok but nothing appears on My Contributions.

@ilya, btw, I noticed that when I clicked the Open From Feed link in Package Explorer I was prompted twice for my firewall credentials (to be specific, I don't mean it prompted me and then after I entered them it prompted again...I mean that two credential dialog boxes appeared on top of each other at the same time).  It still worked though.

Apr 14, 2011 at 6:55 PM

OK, this seems like an issue with the nuget.org website. I tried it with the current public Package Explorer version and I saw the same problem. Don't worry about that for now. I'll follow up internally with the guys in charge of the gallery.

Apr 14, 2011 at 6:56 PM

Oh wait, I spoke too son. It seems like they have created a different page for unpublished packages. It's here: http://nuget.org/Contribute/MyUnfinishedPackages

 

 

Apr 14, 2011 at 6:59 PM
dotnetjunky wrote:

Hmm, has others people on this thread tried the build that ilya uploaded? Can you try publishing packages and see if they appear on the My Contributions page?

@dotnetjunky: I think I might have discovered another issue which I am looking into and it is basically that we are not only using HttpClient class to access the web resources but other ways such as WebClient and WebRequest and I will now have to go through and find out where are all of those places and make sure that we are properly setting the proxy on them.
Another thing I ran into at around 1:25 PM EST is that the following URL: http://go.microsoft.com/fwlink/?LinkID=207106  which is used as the DefaultGalleryServerUrl in the GalleryServer class is giving me a 403: Forbidden Access Denied error so when I try to publish to that URL it throws an exception. The link that the above link is pointing to is forwarding me to the following URL in the browser: http://packages.nuget.org/v1/. Can you validate that this is the correct location or am I just missing something.

@BrianHartung: Were you prompted twice when you first opened up the Open From Feed dialog? or was it when you were paging? Just trying to nail down the scenario in which you have seen this behavior. With the latest code base you should only be re-prompted when:
1) You've entered invalid credentials
2) The URL that you are navigating to is different from the one that you've saved credentials for
3) You did not click on save credentials and because of that we have to ask you for credentials every time that we are creating a new request to the server.
So based on the above listed scenarios it would make sense that you get prompted if you've done either 1 or 3.

Apr 14, 2011 at 7:08 PM
ilyalozovyy wrote:

@dotnetjunky: I think I might have discovered another issue which I am looking into and it is basically that we are not only using HttpClient class to access the web resources but other ways such as WebClient and WebRequest and I will now have to go through and find out where are all of those places and make sure that we are properly setting the proxy on them.
Another thing I ran into at around 1:25 PM EST is that the following URL: http://go.microsoft.com/fwlink/?LinkID=207106  which is used as the DefaultGalleryServerUrl in the GalleryServer class is giving me a 403: Forbidden Access Denied error so when I try to publish to that URL it throws an exception. The link that the above link is pointing to is forwarding me to the following URL in the browser: http://packages.nuget.org/v1/. Can you validate that this is the correct location or am I just missing something

That's a very old link. You should use the latest link, which is: https://go.microsoft.com/fwlink/?LinkID=206669. Let me know if you still have any issue with this.

 

Apr 14, 2011 at 7:26 PM

Btw, I've just briefly looked at your code. There're lots of changes in there, so it'll time some time for me to look at them more carefully. Overall though, I like the changes.

Also, I now remember why I had to make some changes to the KennyKerr.dll. I wanted to avoid reference to the Windows.Forms.dll assembly. I think that is only for the DialogResult type, which doesn't justify adding reference to the whole Windows Forms assembly. But that's a minor details. Don't worry about it. I'll swap it with mine which does not have the dependency. Just an FYI.

Apr 14, 2011 at 7:48 PM

Yeah I saw that dependency and decided that for the time being I did not want to invest too much time in fixing that but since you've mentioned it I have gone ahead and used the one that you attached for me earlier and I have updated my existing fork with it and removed the dependency on the System.Windows.Forms assembly. I am now able to successfully connect to the package feed however I am getting a BadRequest exception when I try to publish my package that I have created for testing so when you get a chance please take a look at the latest version of my code and see if you can pin point the issue. I will look at it from my end and see if I can find something my self but I am not too familiar with the data structure of the packages just yet to figure out what is causing this issue just yet.

Apr 14, 2011 at 7:56 PM

Oops, sorry my bad. The url http://go.microsoft.com/fwlink/?LinkID=207106 is the correct url for publishing/pushing packages. The link 206669 is for loading packages. The reason why you saw the Forbidden Access Denied error in the browser is that the url only accepts POST request with the API key supplied.

Apr 14, 2011 at 7:59 PM

As a result, your change in SettingsManager.cs to set the api key to ActivePackageSource is not correct, because ActivePackageSource is for loading packages and you can't push/publish packages to it.

Apr 14, 2011 at 8:20 PM
dotnetjunky wrote:

As a result, your change in SettingsManager.cs to set the api key to ActivePackageSource is not correct, because ActivePackageSource is for loading packages and you can't push/publish packages to it.

It is all fixed now. I have now added a new configuration setting called PublishPackageLocation so that we can have the publish url be configurable just like the Package Source. The original implementation was using a hard coded value in the GalleryServer to get packages published and not exactly sure how that was working. You can see my latest revision in my fork.

Apr 14, 2011 at 8:27 PM

Right, I hard-coded the publish url because I didn't have time to implement the UI to to allow changing to publish location. And besides, the publish protocol that I'm using only works against nuget.org gallery. There's no guarantee that it will work against other gallery sites (if any exists). Why do you want to create a configuration setting value for it? What's the benefits?

Also, have you looked at the url http://nuget.org/Contribute/MyUnfinishedPackages and see your unpublished packages there?

Apr 14, 2011 at 8:45 PM

Oh sorry, I forgot to mention that the publishing functionality is now working for me. I was able to successfully publish from behind the proxy and normally.
The only benefit that I can see is that one can change the URL without changing the code and having to worry about code changes. Instead you can simply update
the configuration just like the Package Source config and you are done. Is it that big of a deal for me, no not really but I thought that it makes sense.
If you think that you don't want it in there I can go ahead and back it out. The only change that I've made is to refactor the code so that the GalleryServer class is now
accepting the URL as a constructor argument and that is being passed in from the consumer of the GalleryServer.

Apr 14, 2011 at 8:46 PM

No, it's fine. No need to change it back. It's a good change.

Apr 14, 2011 at 9:22 PM

Sorry for spamming everyone so much but can the people who have tested the last build try this new one: Link

Apr 14, 2011 at 11:32 PM

I'm having some issues.  Here are the actions I take and the results I get (this is always repeatable for me):

- Launch Package Explorer and select Open from Feed -> Proxy Auth dialog pops up

- Enter credentials -> Package list is displayed

- 1st attempt to select any package -> Downloading dialog pops up, no credential dialog, eventually times out

- Select Open from Feed again -> Package list is displayed

- 2nd attempt to select any package -> 2 Proxy Auth dialogs pop up on top of eachother

- Enter credentials (into one or both) -> Package contents is displayed

- Select Publish, check "Only push package to gallery, do not publish it" box, paste in Publish Key, click Publish -> 20-30 seconds later, crash (Unhandled Exception, Null reference in OnPublishButtonClick->ShowDialog)

This is on an XP SP3 system.  I haven't tried it on my Win7 home system yet but that's not behind a proxy.

Apr 15, 2011 at 12:03 AM
Edited Apr 15, 2011 at 12:03 AM

@BrianHartung:
Thanks for posting your findings. Off I go again troubleshooting them issues :)

  1. It is very interesting that you are getting multiple credential dialog boxes. Maybe it is because I've saved my credentials and that is why I no longer see the prompts. I will have to clear out all of the saved credentials and test it again.
  2. I did notice that once in a great while I will see a time out error and that I am not sure about. I wonder if it would be OK if we simply increased the timeout period of the requests since the default is probably set to 30 seconds and I wonder if some of the redirect requests are causing us this timeout issue.
  3. In regards to the error I think that we need might need to introduce an error logging/error notification component so that we can capture stack traces for troubleshooting these kinds of issues.

@dotnetjunky:
What do you think about the following:

  1. Implementing something like log4net to capture errors in a log that one can send to the person working on an issue
  2. Increase the time out that is used for requests to read and publish using Package Explorer
Apr 15, 2011 at 12:12 AM

@BrianHartung: Can you pull the changes from ilyalozovyy's fork and debug the last issue to see what is causing the exception?

@ilyalozvyy:

  1. Eventually, we'll implement the tracing/logging feature, but I'm trying to avoid using third party libraries as much as possible, because they will increase the ClickOnce download size. I'm considering using the built-in tracing feature of .NET, which may not be as fancy as log4net but still serves the purpose well.
  2. Are we certain that the crash is due to the timeout issue? It seems like not. It's not a big deal to increase the timeout but I want to understand the error first before increasing the timeout.
Apr 15, 2011 at 12:25 AM

Downloading now...

Apr 15, 2011 at 12:33 AM

@ilya: You probably already know this (so I'm posting it mostly as a tip in case anyone else would find it useful), but you can use that utility that comes with Kenny Kerr's source (Kerr.CredentialSetManager.exe) to easily remove the credentials you saved by checking that box.

Apr 15, 2011 at 12:50 AM

The problem is in GetSafeRedirectedUri.  The exception handler assumes the Response object will be non-null, but in this case it is null.  The specific exception returned is "Unable to connect to the remote server" and the Inner Exception is "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 64.4.11.160:80".  That's the same timeout message I get when first trying to pull up any package from the feed.

        private string GetSafeRedirectedUri(string uri) {
            try {
                Uri originalUri = new Uri(uri);
                IWebProxy proxy = _cachedProxy;
                RedirectedHttpClient client = new RedirectedHttpClient(originalUri,proxy);
                return client.Uri.ToString();
            }
            catch (WebException e) {
                return e.Response.ResponseUri.ToString(); ;
            }
        }
Apr 15, 2011 at 12:56 AM

Interestingly, because I was in a debugger this time, I could play around with the instruction pointer and bypass the unhandled exception that was tearing down the process so that I could see what happened if I tried to upload the package a second time (after all, the first attempt to download a package always times out and then works on the second attempt, so maybe there's a pattern).  Sure enough, the upload started the second time.  Ultimately I got an Unauthorized (401) exception, but at least it was progress.  I have a funny feeling there's a chicken v. egg thing going on with the proxy object you're caching behind the scenes.

Apr 15, 2011 at 2:33 AM

@BrianHartung:

  1. Thanks for that suggestion about the CredentialSetmanager. I knew it was there and I've used it when I was looking at the library but did not even think about it. I ended up removing all of those saved credentials and validated that we are only requesting the credentials for the proxy and not other urls like it was before. There is a fundamental issue that we need to resolve in the current codebase and that is the way that we create the WebRequest objects. Currently some code paths are using the HttpClient and some are using WebClient and some are using WebRequest. This means that we don't have a central way to manage creation and setting of the proxy object and that is why you are seeing the multiple prompts for credentials.
  2. In the mean time what I can do is to update the HttpClient code so that it increases the Timeout value of the request object so that it does not time out as fast and that might solve your issue that you are seeing right now I am also going to fix up the handling of the retrieval of that redirected url so that it does not try to return the e.Response.ResponseUri when it times out but rather rethrows the WebException that was caught in the first place so that the user knows that there was a problem.
  3. In regards to the cached proxy object that you see there, it was put in there so that when a GalleryServer class is asked to upload and publish the package it does not ask the user multiple times to login but only does it once when the class is initialized. Otherwise you would see up to 3 or more prompts for credentials unless  you've saved your credentials.

@dotnetjunky:

  1. Good point about the logging. I did not think of the current deployment model that you are supporting. I have created a new fork for creating the logging mechanism and I'll start working on it unless you finish it faster than me :) but I know you've been busy implementing everything else.
  2. As to the timeout issue I have seen it my self intermittently. I have noticed that sometimes I have to wait quiet a long time for the responses to come back but I've always attributed that to my development environment because I've never seen this behavior when I am at home and not behind a firewall. So a quick fix/patch that I can do is to increase the timeout value however that is a patch like you've said so let me know how exactly you would like to handle this scenario.
    Also let me know what you think about using 200 seconds as the timeout value instead of the default 100 that HttpWebRequest has. This seems like such a bad hack but not sure if there is a better way.
    Here is an interesting statement that is made on the MSDN site for the HttpWebRequest class found HERE: "A Domain Name System (DNS) query may take up to 15 seconds to return or time out" which might make it possible that going through some corporate firewalls will hit the forwarding link first and take a long time and then take the same time or longer to initialize the actual request to publish the packages.
  3. I was also thinking about possibly adding some sort of a Service Locator feature unless the MefServices is using a similar concept so that we can share instances of objects like Credential Services, Proxy Services, and Logging services among many other(s) that we might/will have later.
    Let me know what you think about that also.
  4. I am also going to update the GetSafeRedirectedUri method in the GalleryServer class so that if it times out that it does not try to return the exception's response uri but it throws an exception so that we don't try to navigate or execute anything else if there was a problem getting a valid response from the server about the url that we are going to try and query for packages.

 

Apr 15, 2011 at 3:37 AM

@ilya: I really appreciate that you're willing to contribute to Package Explorer. This is great news. Though I'd suggest we create a separate topic for that instead of discussing here. Sounds good? Just let me know what you're planning to do, (and preferably, describe your design) so that we don't step on each other's toes.

Apr 15, 2011 at 8:22 AM

I concur with the things Brian is seeing Sometimes the package gets downloaded and sometimes it doesn't. I only got one request for auth though, never again after that. I can download source and hack at it next week if needed.

Apr 15, 2011 at 3:32 PM
chrissie1 wrote:

I concur with the things Brian is seeing Sometimes the package gets downloaded and sometimes it doesn't. I only got one request for auth though, never again after that. I can download source and hack at it next week if needed.

@BrianHartung & @chrissie1: I have checked in an update to the proxy detection logic which should speed up the detection of the proxy and getting the correct credentials for it. When you have a chance please get the latest code from my fork and check the new implementation. The current flow of proxy detection work like this:

1) Check if a proxy is set in Internet Options
     i) Check for existing credentials for the given proxy url -> If Found then Validate Proxy with saved credentials
    ii) If no saved credentials found then Use Integrated Authentication/Default Credentials -> Validate Proxy with Default Credentials
   iii) If no valid proxy has been detected then Prompt the user for credentials -> While loop cValidate Proxy with user credentials until valid credentials provided or user cancels the action.
2) Proxy is not set
     i) return null proxy for direct connection.

This new detection logic significantly improves the detection and validation of a proxy if one exists because if one saves the credentials then the saved credentials are attempted first without
trying to use the other methods first and creating web requests to validate each request before a valid one is used.

Also let me know if you would like me to build a release and attach it again to that work item if you can't get to the source code repo at this moment or when you have the time to test.

Apr 16, 2011 at 5:17 PM

Hi Ilya...sorry I haven't had a chance yet to download the latest code.  One thing I wanted to mention however...if I understand your explanation above, it sounds like you are checking in the registry for a proxy configured within Internet Explorer.  If that's true, then I think that's a problem because default proxy configuration can be done outside of Internet Explorer (in machine.config for example) and you would miss properly detecting that scenario.  I think any determinations about the proxy should be made based on the default proxy object that is automatically generated and assigned to the WebRequest.Proxy property by the framework.  Again, I haven't looked at the code yet (I really hope to get to that today or tomorrow) but I thought I'd throw this out there in case it saved any work.  (I know one thing: at this point I can really appreciate the effort the System.Net team must have gone through to get this all working themselves! :)

Cheers,

-Brian

Apr 16, 2011 at 6:42 PM

@BrianHartung: You make a very good point. I love working with people who can find all sorts of scenarios. By the time I am done implementing this logic we will have one hell of a proxy detection service.
I was using an Interopt call to wininet.dll -> InternetGetConnectedState to see if there was a proxy set in the Internet Options. However I think that you are correct when you say that we also need to be accounting for the user changing app.config/machine.config settings of the application. On top of that the user can set the WebRequest.DefaultWebProxy static property directly like I was doing initially and if they do so then we can use that setting also. I have updated the code to cover this additional scenario so that now I am doing a check to see if we have both Internet Options proxy and then the DefaultWebProxy set then we will use that, otherwise I'll just fall back to no proxy option. Another option that I've added was if the url that we are going to is bypassed then we also just go directly to it instead of trying to go through the proxy. I was able to test both behind proxy and no proxy scenarios and both of them are working as expected.

Please let me know if you run into any other scenarios. This is a fun piece of functionality to work on. I've would have never thought that this much work would need to be done. But at least I know how it work now. Thanks for all of the help.

Apr 16, 2011 at 7:26 PM

I have the feeling that this is getting a bit more complex. Is it really necessary to do interop call into wininet.dll? I want to avoid that if possible. I'm happy if we only address 80% of the case with simple code rather than trying to achieve 100% with much more code.

Apr 16, 2011 at 7:43 PM
dotnetjunky wrote:

I have the feeling that this is getting a bit more complex. Is it really necessary to do interop call into wininet.dll? I want to avoid that if possible. I'm happy if we only address 80% of the case with simple code rather than trying to achieve 100% with much more code.

It is definitely possible to avoid doing interop for proxy detection and now that I think about it the updated code should in theory be capable enough of detecting Internet Options proxy setting since I switched from using WebRequest.GetSystemProxy() to WebRequest.DefaultWebProxy property
which seems to be better for doing both .NET settings detection and Internet Options detection. I will test it out without the Interop call in my environments and if everything will work ok, then I'll go ahead and get rid of that dependency.

Apr 16, 2011 at 7:50 PM

Cool. Thanks ilya.

Apr 17, 2011 at 7:54 PM

Hi Ilya...I wasn't sure from reading above whether the code was ready for testing, but I went ahead and cloned the latest code and ran it from behind my proxy.  When I clicked Open from Feed it prompted me for my credentials and then displayed the list of packages as expected.  However, when I selected a package for download, it immediately returned the "407 proxy auth required" exception in the downloading dialog box.  Thinking I should try again to see if the second time worked I found that the same sequence repeats (prompted for credentials every time when trying to open the feed and get a 407 exception every time I choose a package after re-entering the credentials).  Again, this may all be a moot point if the fork isn't ready for testing yet so I apologize for getting ahead of myself if that's the case.

Apr 18, 2011 at 4:42 AM
BrianHartung wrote:

Hi Ilya...I wasn't sure from reading above whether the code was ready for testing, but I went ahead and cloned the latest code and ran it from behind my proxy.  When I clicked Open from Feed it prompted me for my credentials and then displayed the list of packages as expected.  However, when I selected a package for download, it immediately returned the "407 proxy auth required" exception in the downloading dialog box.  Thinking I should try again to see if the second time worked I found that the same sequence repeats (prompted for credentials every time when trying to open the feed and get a 407 exception every time I choose a package after re-entering the credentials).  Again, this may all be a moot point if the fork isn't ready for testing yet so I apologize for getting ahead of myself if that's the case.

Brian it was nice to finally talk to you to try and figure out a solution to the problems that you were seeing.
Just for everyone's benefit I am going to document what we've discovered and please correct me if I've missed something.
It seems as through the proxy detection logic was failing in Brian's case because for what ever reason a valid response would come back from the request when we were testing for Integrated Authentication even though he is not using the Integrated Authentication proxy.
However this would cause the ProxyService to return an invalid WebProxy instance and thus causing the issue that he was seeing. The strange part was that it would happen only some times and not others.
To temporarily resolve this issue at least until either something else or I have enough time and implement a Service Locator pattern/framework into the Package Explorer tool is to have a static cache of proxies that would be kept for each Uri that we are using
and in most scenarios it would only be one proxy but it is possible to see more than one. This implementation ended up solving the issue that Brian was seeing. I have updated my fork to include this change.

@dotnetjunky: if you have any thoughts and or questions about this let me know.

Apr 18, 2011 at 5:29 AM

That's great. Glad to hear that you have resolved the issue with BrianHartung. Let's wait for the other users to try the latest code the last time. Hopefully, it will work well with the other proxies.

I have one small question. You said you want to implement a Service Locator pattern. Care to explain why it is needed? Does MEF meet your needs? I'd like to keep the codebase as small as possible without adding additional custom frameworks.

Apr 18, 2011 at 2:57 PM

@luan: the issue was that the current algorithm tries to detect the presence of a proxy as well as which authentication strategy to employ (none, integrated or basic auth) with each attempt to contact a new NuGet endpoint.  This was causing issues because for some reason in my environment, the first attempt at this detection works perfectly, but sometimes a subsequent request will seem to go through without needing any explicit credentials (most likely there's a cache somewhere inside our corporate network that's fulfilling the reqeust without really having to go across the proxy...I haven't had a chance to look at the cache control headers to see if that should even be possible so it may not be the explanation).  This is causing the any subsequent attempt to hit the same endpoint to fail (since we would not have included the necessary credentials thinking they weren't needed).  The solution is to "remember" the initially detected authentication strategy for any proxy we encounter (for most environments with proxies I'd think there would only be one proxy URI but we'll support the potential for more than one...that's no big deal).  What Ilya is referring to by the service locator pattern is simply a way to cache that proxy object in a way that would make it available across all the places in NuGet where calls are made (sometimes using WebClient, sometimes using HttpWebRequest, sometimes implicitly using ADO.NET Data Service calls, etc.)  Clearly that'll take a bit of doing, but in any event that's what he's referring to.

Apr 18, 2011 at 7:21 PM
dotnetjunky wrote:

That's great. Glad to hear that you have resolved the issue with BrianHartung. Let's wait for the other users to try the latest code the last time. Hopefully, it will work well with the other proxies.

I have one small question. You said you want to implement a Service Locator pattern. Care to explain why it is needed? Does MEF meet your needs? I'd like to keep the codebase as small as possible without adding additional custom frameworks.

@dotnetjunky: I am not familiar with MEF so I'll have to look into that and if it gives me the ability to be able to pass around the same instance of the Proxy Service then it would be my preference of choice because I definitely agree with you on the matter of not adding any new dependencies especially because of the way that this application is being deployed through ClickOnce (even thought ClickOnce is also having this proxy issue :) so I can't install Package Explorer that way)

@BrianHartung & @chrissie1: Can you please download and test the latest build of the Package Explorer: PackageExplorer_WithProxyAuth_4_18_2011_1.zip
This should have the latest changes that I have put in to account for this strange behavior that we've discovered over the past couple of days.

Apr 18, 2011 at 7:22 PM

@BrianHartung: I understand the solution from ilya's post above. I totally agree that a central service to provide proxy credential is a good thing to implement. I was just saying that we can make use of MEF for that purpose instead of adding some custom service locator/IoC framework.

Apr 18, 2011 at 7:25 PM

@ilya: The current code is already using MEF to share services between the view and viewmodel projects. You can take a look at several classes in there to get familiar with MEF. Let me know if you need any explanation.

Apr 18, 2011 at 8:02 PM

I will do so first thing in the morning when I get back in the office.

Apr 19, 2011 at 12:09 AM

Works like a champ.  I tested listing and downloading packages with and without saving credentials and it worked perfectly every time.

Apr 19, 2011 at 12:40 AM
Can you test publishing package and see if it works? Check if it is on the gallery?

Sent from either Windows Phone or iPhone. You don't know.

From: BrianHartung
Sent: Monday, April 18, 2011 4:09 PM
To: Luan Nguyen
Subject: Re: Support for a corporate http proxy [nuget:227886]

From: BrianHartung

Works like a champ. I tested listing and downloading packages with and without saving credentials and it worked perfectly every time.

Apr 19, 2011 at 1:16 AM

I just created a test package and was able to successfully push it (without publishing...I was able to see it under MyUnfinishedPackages).  Nice work, Ilya.

Apr 19, 2011 at 2:32 AM

I concur. Very nice work, Ilya.

Apr 19, 2011 at 3:00 AM

oh come on guys, you are making me blush here, but thank you for the complements.

@dotnetjunky: once @chrissie1 can confirm that it is also working for him, what is the process for going forward? I know that when I try to build in release mode I get a bunch of error messages because of the Code Analysis. Is that something that you would like me to fix?
Also if you think that this is working as you would like it are you planning to move this implementation into the NuGet project? If so I would like to volunteer to help you in that task.

Apr 19, 2011 at 5:04 AM

@ilyalozvyy: The next step is that I will merge your change into the default branch. Don't worry about the fxcop errors. I'll fix them when I merge. I'll also likely to make some minor refactoring of your code to conform to our coding guidelines.

About integrating your changes into NuGet, my take is that we'll release Package Explorer with your fix, and see how it goes. If all goes well and nobody complains about proxy issue anymore, then we'll take in the change for NuGet 1.4. The upcoming 1.3 release is pretty much locked down at this time.

I'm glad that you volunteer to help with this task. Of course, we're more than happy to let you do it. After all, it's your code :) However, please take note that since this is a relatively big chunk of code, we will require you to sign some legal paper before accepting your contribution. It's just a formality thing with the Outercurve Foundation. Are you OK with that?

Apr 19, 2011 at 8:24 AM

I can confirm that it works like a champ now. It never asked for my credentials. I will have to peek into the code to see how that works.

Are you planning to blog about it ilya? Seems like many people would benefit from it.

 

Thanks ilya and dotnetjunky and brian for all the great work. If you ever come to Belgium I will all buy you a beer.

Apr 19, 2011 at 8:53 AM

Hi Guys,

I was following you and I discovered you finally fixed the issue with Basic Auth Corporate Proxies.

I'd be part of the testing phase but, as I lost the post where you specified the URL to get the private build, may you specify it so I can test it
behind my corp. proxy ?

It's a squid with Basic Auth...

Thank you
Igor.

Apr 19, 2011 at 10:49 AM
Edited Apr 19, 2011 at 10:49 AM
igoran wrote:

Hi Guys,

I was following you and I discovered you finally fixed the issue with Basic Auth Corporate Proxies.

I'd be part of the testing phase but, as I lost the post where you specified the URL to get the private build, may you specify it so I can test it
behind my corp. proxy ?

It's a squid with Basic Auth...

Thank you
Igor.

The link to the latest Debug build of Package Explorer is actually listed above but here it is again: PackageExplorer_WithProxyAuth_4_18_2011_1.zip

Apr 19, 2011 at 12:33 PM

@chrissie1: I am definitely planning to blog about this implementation however to better assist me in sharing not only the code but also expose some of the more interesting functionality of what we've done here I am writing a couple of NuGet packages that would help me do that. Once those packages are completed I will post a link to the article here.

@dotnetjunky: When you mentioned the legal papers are you talking about the following document? Outercurve Foundation Contribution Agreement if so then I would not have a problem signing it.

Coordinator
Apr 19, 2011 at 5:06 PM

Yes, please fill out the Contribution Agreement and email it to me (philha@microsoft.com) and I’ll take care of the rest.

Apr 19, 2011 at 5:49 PM

@ilya: I've just checked with Phil and he told me that I can only pull in your change into Package Explorer after you have signed the agreement and sent to Phil. So, we are waiting for you, but no pressure.

@ilya and Brian Hartung: I'd like to put your names into the credit box of Package Explorer in recognition of your contribution, if you don't mind. Let me know what names you want me to put in there :)

Apr 19, 2011 at 6:03 PM

@Haacked: I have sent you the signed agreement document.

@dotnetjunky: thank you for the opportunity to help out and you can use my full name which is: "iLya Lozovyy"

Developer
Apr 19, 2011 at 6:04 PM

@ilya Thanks for all of your hard work, this is why open source rocks! Before we integrate this into nuget proper, we need to review the code closely and figure out which parts go into NuGet.Core and each of the clients. We also need to do a formal code review (make sure you read our guidelines on contributing http://nuget.codeplex.com/documentation?title=Contributing%20to%20NuPack).

Apr 19, 2011 at 8:03 PM

@luan: I am more than happy to have my name appended to the list.  Since my legal name as displayed on my birth certificate ("Stud Hammerpants") is probably inapproriate, I'd simply go with my informal handle, Brian Hartung.

Cheers and thanks again for putting together such a fantastic product (you guys deserve the real credit)! :)

Apr 20, 2011 at 6:15 PM

Thanks Brian.

@igoran: Have you tested the fix with the squid proxy? How was it?

Apr 21, 2011 at 1:00 AM

Hi guys,

I have finally taken time to pull ilya's code into the nuget tree. The build is on our CI machine now at (http://ci.nuget.org:8080/repository/download/bt18/1657:id/PackageExplorer/PackageExplorer.zip).

Everyone, please download it and test it again with your proxy. Please do all kinds of crazy things to make sure it doesn't regress any functionality. I really appreciate your help on this.

 

Apr 21, 2011 at 1:56 AM

@dotnetjunky: Just wanted to confirm that I was able to successfully Load the list of packages from the feed, download a few packages, then publish the package to the gallery and everything seems to be working as expected and all of it was with and without the firewall.
I am getting quiet excited at the prospect of being able to use NuGet from behind a proxy now especially with the symbol server and the possibility of using it on a build machine to retrieve dependencies :)
Brian was correct when he said that you guys have created a truly amazing tool for the development community. Awesome job!!

Apr 21, 2011 at 2:47 PM

@luan: I downloaded the update from your link and successfully tested all functionality from behind our basic auth proxy: querying the feed list, downloading several packages, and uploading a custom package all worked perfectly and I was only prompted for credentials once as expected.

Apr 21, 2011 at 3:30 PM

Hi Guys,

sorry for my delay in testing...and, unfortunately the version linked above by dotnetjunky is not working.

I'm just opening the Package Explorer and "Open from feed". Once the window is open, I click on "Apply" (the default
link is already in the combobox) but nothing happens...

No Credentials required for proxy ... just blank listview...

May I help in some way ?

Thank you
Igor.

Apr 21, 2011 at 3:44 PM

@igoran: I was wondering if you can confirm the following for me:

  1. Were able to use the debug build that I posted a few days ago that can be found here: PackageExplorer_WithProxyAuth_4_18_2011_1.zip
  2. What do you see when you try to navigate to the feed url: https://go.microsoft.com/fwlink/?LinkID=206669 in your browser. Do you get prompted for credentials?

Some times for me when I try to navigate to the URL it does not work so I have to retry but it seems that it is not working for you at all.

Thanks

Apr 21, 2011 at 3:45 PM

@igor: I assume you downloaded and tested with the version dotnetjunky provided...out of curiosity, have you tried the version iLya posted above?  This would help to narrow down whether it's perhaps just an issue with the final merged code or whether there's something we haven't properly considered yet.

Apr 21, 2011 at 3:45 PM

(Great minds think alike) :)

Apr 21, 2011 at 3:53 PM

Hi ilyalozovyy and BrianHartung,

I've downloaded both versions, the dotnetjunky one and the iLya one.

Both behaves the same: no packages in the listview ... totally blank.

When I try to reach the feed url,I'm always been asked for authentication (by the browser) and I see 
the Service reply with "Default Package" and "Screenshot" collections.

Here to serve you.
Igor. 

Apr 21, 2011 at 4:02 PM

Hmm, the only thing I can think of at this point is that we are seeing a similar behavior that Brian was experiencing and that is the proxy environment is returning a response that is not a 407 proxy authentication failure and because of that the proxy detection is failing. The solution can be is to try and see if during the detection of the proxy if the response Url has changed to something other than the one that we are trying to get to for example: Some times when you use a corporate proxy or a hotel proxy they automatically redirect you to their internal site that requires you to authenticate through the page. If that is the case then this might be your issue. @igoran I'll make an additional code change and post a new build the same way for you to try again and hopefully this will work. Thanks for testing.

Apr 21, 2011 at 4:06 PM

Hi ilya,

Unfortunately it's not my case: my corporate proxy (squid) accept authentication just with the Basic Authentication Method; no login pages at all.

I hope this can help.

At the moment I can't have a VS2010 instance to help you debugging ... I hope to have one soon...

Thank you
Igor. 

Apr 21, 2011 at 4:35 PM

@igoran: New build with tracing can be found here: PackageExplorer_WithProxyAuth_4_21_2011_1.zip

Please email me the debugview log once you are able to execute the app so that I can see what the app is doing.

Apr 21, 2011 at 5:29 PM
Edited Apr 21, 2011 at 5:30 PM

I myself experienced that issue once when I did the integration yesterday. The listbox was blank, no network call was made. I then closed the app and restarted it, and it worked again. I can't repro it anymore. Weird.

Another small issue is that if my network doesn't have proxy at all, shouldn't we bypass any proxy detection logic? It's not the case right now, but I can live with that for this release if it's not trivial to fix. I'm just trying to see if we can avoid loadding the Kerr.dll library altogether in the no proxy scenario.

Apr 21, 2011 at 6:44 PM
Edited Apr 21, 2011 at 7:26 PM

@dotnetjunky: Interesting so both of you are having the same issue then except that @igoran can consistently reproduce it.  I'll work with @igoran to try and figure out the issue that he is facing.
This is the piece of code that you are talking about that checks to see if we have a proxy set or not:

IWebProxy proxy = WebRequest.DefaultWebProxy;
if (null != proxy)
{
     Uri proxyAddress = new Uri(proxy.GetProxy(uri).AbsoluteUri);
     bool bypassUri = proxy.IsBypassed(uri);
     if (bypassUri){
         return false;
     }
     proxy = new WebProxy(proxyAddress);
}

The interesting part is that WebRequest.DefaultWebProxy returns a WebProxyWrapper class even if the proxy settings are turned off in Internet Options.
This is forcing the code to go into the if condition and the proxy.GetProxy(uri).AbsoluteUri is returning the same Uri that we are trying to get a proxy for which is invalid.
However the next line proxy.IsBypassed(uri) is returning false in my case and the application ends up not using any proxy which is the correct behavior.
So for me :) and @Brian things are working OK.
If you remember back a few posts when I mentioned that I was using an interop call to check and see if we have a proxy, it would return a valid result when I would
check to see if the proxy setting was applied or not and then we could bypass the proxy detection logic but it sounded like you did not really want to rely on the interop method
to do that. I can re-add that code in the method again and you can try it to see if that works better and if it fixes this issue for @igoran also.

Apr 21, 2011 at 7:05 PM

Is that the only way to detect proxy's presence? I'd like to avoid that interop call if possible.

Apr 21, 2011 at 7:22 PM

@dotnetjunky: Well as always @Brian had another good suggestion which I have implemented. I also had a question for you about logging. I have added some tracing code to the ProxyService and I was wondering if you would want me to take it out or do you want to keep it?
I don't know if there is a special pattern that you wanted to follow for this kind of functionality and I did not have a chance to implement the logging framework for us to use yet. So we can wait and I can add that tracing code later but I wanted to get your input first.

Apr 21, 2011 at 7:40 PM

For this release, let's hold off on doing logging/tracing. For the next version, we'll use the built-in .NET tracing feature, so there is no need to implement a new logging framework.

Also, if you implement any new fix for the proxy issue, can you create a new fork of the nuget tree and make the changes directly there? That way when you send a pull request, I can easily pull in your change without merging. Sorry for not mentioning this earlier.

Last but not least, we'd appreciate you can follow our coding guidlines here (http://nuget.codeplex.com/documentation?title=Coding%20Guidelines). That will also save me some work. :)

Thanks for your contribution to NuGet.

Apr 21, 2011 at 8:34 PM

@dotnetjunky: I have created and updated the new fork with the patch that I was talking about and it also addresses another issue that I discovered a bit earlier where if the user cancels the password prompt then an invalid proxy would be cached and the user will be forced to restart the app so that they get a chance to specify correct credentials again. I have also updated my VS settings to conform to your coding K&R style brace formatting and I will attempt to follow your coding guidelines more closely but please let me know if I miss something so that I can pay more attention to that in the future.
The new fork can be found here: https://hg01.codeplex.com/forks/ilyalozovyy/proxyserviceupdates

Apr 22, 2011 at 5:36 PM

@dotnetjunky: I was just wondering if you were waiting for me to send you the pull request from the new form before you do anything because the changes that I wanted to make are all done and ready for integration.

Apr 22, 2011 at 8:15 PM

Yah, next time, feel free to send a pull request whenever you think your changes are ready for integration. No need to do so this time. I'll pull in  your changes by the end of today.

I'm not clear from your post above, but does this change bypass proxy detection altogether if i'm not behind a proxy? In other words, will it avoid loading the Kerr.dll assembly in that case? I'm just asking for information, not requiring you to do it. :)

Apr 22, 2011 at 8:37 PM
dotnetjunky wrote:

Yah, next time, feel free to send a pull request whenever you think your changes are ready for integration. No need to do so this time. I'll pull in  your changes by the end of today.

I'm not clear from your post above, but does this change bypass proxy detection altogether if i'm not behind a proxy? In other words, will it avoid loading the Kerr.dll assembly in that case? I'm just asking for information, not requiring you to do it. :)

If by proxy detection you mean asking for credentials then the only time that the Kerr.dll should be used is if the user is going to be required to provide credentials. The idea as always before was to not prompt the user unless really required. I have added an additional scenario to how I as detecting if a proxy was setup based on the proxy url that would be returned by the proxy.GetProxy(uri) method. If the returned url was the same as the one that we are trying to get the proxy for then it most likely means that you can directly go to the url without any proxy required. Hope that clears it up :)

Apr 22, 2011 at 9:09 PM
Edited Apr 22, 2011 at 9:13 PM

From what I observe on my machine (which has no proxy), the following codepath still gets hit:

        public override ICredentials[] GetCredentials(Uri uri) {
            if (null == uri) {
                throw new ArgumentNullException("uri");
            }
            using (CredentialSet set = new CredentialSet(uri.Host)) {
                if (null == set || set.Count < 1) {
                    return new ICredentials[0] { };
                }
                return set
                    .Select(cred => new NetworkCredential(cred.UserName, cred.Password))
                    .ToArray();
            }
        }

The CredentialSet class is in Kerr.dll, and hence it forces the runtime to load Kerr.dll. Is there a way to avoid that?

Apr 23, 2011 at 2:39 AM

@dotnetjunky: That is very strange behavior and most likely means that for some reason the checks for the proxy is saying that you do have a valid proxy and it is then trying to look up specific credentials for the url that you are accessing.
Can you please debug and see why the ProxyService.IsSystemProxySet(uri) method returning true in your case?

Apr 23, 2011 at 3:04 AM

Sure. Will do when I get home.

Apr 23, 2011 at 8:18 AM

So I  have tried it again with your latest fix. This time the GetCredentials() do NOT get called anymore. This is great. I love it.

Apr 23, 2011 at 3:11 PM

That great!!
I am now looking into using MEF for injecting the instances of proxy service into correct places instead of using the static dictionary that i've had in the proxy before.

Apr 28, 2011 at 12:19 AM
Edited Apr 28, 2011 at 11:25 PM

I was finally able to get the command line version to work by creating a file "Nuget.exe.config" with the following:

<?xml version="1.0"?>
<configuration>
    <system.net>
	<defaultProxy useDefaultCredentials="true" enabled="true" />
        <settings>
		<servicePointManager expect100Continue="false"/>
        </settings>
    </system.net>
</configuration>

Seems to be working for me now and I'm able to implement the no commit package updates http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

Edit: This was to get around the 407 response that I have experienced with both NuGet command line, similar to the fix required for Visual Studio Extension manager.

Apr 28, 2011 at 10:03 PM

Just want to update everybody on this thread. I've just released package explorer 1.1, which include the proxy fix that ilyalozovyy and Brian Hartung helped implement. Feel free to install it (or update it if you have previous version) and test against your proxy. Once again, thanks all for the great effort in helping fix one of the toughest problems on .NET platform :)

Coordinator
Apr 28, 2011 at 11:08 PM

Yes, thank a lot. Next step is to look at getting these changes into core so NuGet.exe and our VS Extension can use it. J

Apr 28, 2011 at 11:20 PM

I'll work on it.

Apr 28, 2011 at 11:24 PM
Edited Apr 28, 2011 at 11:25 PM

@dotnetjunky & @Haacked: again thanks for the kind words. It was a fun experience for both Brian and I not only in trying to figure out a best way to implement this feature but I've also got a chance to meet new people during this process and this is what I really enjoy about working on project(s) like this.
I am going to start a new discussion thread for this topic so that I can have a clean discussion while we are integrating these changes into the core code base. Another thing that I wanted to mention is that I really want to make both the Credentials functionality and the Proxy detection functionality into their own respective NuGet packages. I have already release a newly written CredentialManagement NuGet package that is based on the Kerr library but it is written in C# and the code is fully available on the CodePlex site. This new library supports both the new and old Look & Feel for the Credential Management API which I am hoping that we can use for the integration process. The only thing that is left is to move the ProxyService implementation into it's own NuGet package and make it depend on the CredentialManagement package so that we can easily update the NuGet functionality when updates come out for those packages. Please let me know your thoughts on that. I will start the extraction process for the ProxyService in the very near future so that I can begin work on the Proxy feature integration.

The new discussion thread can be found here: NuGet Core proxy support

May 12, 2011 at 8:32 PM
Edited May 12, 2011 at 8:34 PM

i am from brasilia and i am having a problem, i am trying to create a NuGet Package with the Nuget.exe command line, i refer the .nuspec file corretly, but i receive an error (exception): 


Unhandled Exception: System.Data.Services.Client.DataServiceQueryException: An e
rror occurred while processing this request. ---> System.Data.Services.Client.Da
taServiceClientException: Proxy authentication required
   at System.Data.Services.Client.QueryResult.Execute()
   at System.Data.Services.Client.DataServiceRequest.Execute[TElement](DataServi
ceContext context, QueryComponents queryComponents)
   --- End of inner exception stack trace ---
   at System.Data.Services.Client.DataServiceRequest.Execute[TElement](DataServi
ceContext context, QueryComponents queryComponents)
   at System.Data.Services.Client.DataServiceQuery`1.Execute()
   at System.Data.Services.Client.DataServiceQuery`1.GetEnumerator()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.OrderedEnumerable`1.<GetEnumerator>d__0.MoveNext()
   at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
   at Bootstrapper.Program.Main(String[] args)

 

what is happening? anyone can help me?

May 12, 2011 at 8:39 PM

@raymilam: Proxy support functionality has not made it into the NuGet Core or the Command Line tools yet. It is currently only supported by the Package Explorer.
I am working on integrating these changes into the rest of the application.

Jul 29, 2011 at 9:28 PM

Any update on this yet?

Jul 29, 2011 at 10:09 PM

The initial code changes are in and you should be able to authenticate. We are currently working on optimizing the code.

Jul 29, 2011 at 10:38 PM

What's the usage scenario?  Does it respect some environment variable or have some command line option?

Jul 29, 2011 at 11:10 PM

It uses the "Internet Options" settings to check and see if you have a proxy configured and then it goes through a series of steps to figure out the credentials automatically. If it fails then it prompts the user to provide credentials.

Sep 19, 2011 at 8:22 PM

Still having an issue, i get the prompt for me credentials put them in and nothing is in the list. Run fiddler and it looks like everything is being returned (see sample below).

HTTP/1.1 200 OK

Cache-Control: no-cache

Content-Type: text/xml;charset=utf-8

DataServiceVersion: 1.0;

Date: Mon, 19 Sep 2011 19:19:35 GMT

Proxy-Connection: keep-alive

Server: Microsoft-IIS/7.0

Vary: Accept-Encoding

Via: 1.1 webwasher (Webwasher 6.8.7.9979)

X-AspNet-Version: 4.0.30319

X-Powered-By: ASP.NET

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<feed xml:base="http://packages.nuget.org/v1/FeedService.svc/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom">

<title type="text">Search</title>

<id>http://packages.nuget.org/v1/FeedService.svc/Search</id>

<updated>2011-09-19T19:19:36Z</updated>

<link rel="self" title="Search" href="Search" />

<entry>

<id>http://packages.nuget.org/v1/FeedService.svc/Packages(Id='EntityFramework',Version='4.1.10715.0')</id>

<title type="text">EntityFramework</title>

<summary type="text">DbContext API and Code First workflow for ADO.NET Entity Framework.</summary>

<updated>2011-07-25T17:53:55-07:00</updated>

<author>

<name>Microsoft</name>

</author>

<link rel="edit-media" title="PublishedPackage" href="Packages(Id='EntityFramework',Version='4.1.10715.0')/$value" />

<link rel="edit" title="PublishedPackage" href="Packages(Id='EntityFramework',Version='4.1.10715.0')" />

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Screenshots" type="application/atom+xml;type=feed" title="Screenshots" href="Packages(Id='EntityFramework',Version='4.1.10715.0')/Screenshots" />

<category term="Gallery.Infrastructure.FeedModels.PublishedPackage" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme" />

<content type="application/zip" src="http://packages.nuget.org/v1/Package/Download/EntityFramework/4.1.10715.0" />

<m:properties xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">

<d:Id>EntityFramework</d:Id>

<d:Version>4.1.10715.0</d:Version>

<d:Title>EntityFramework</d:Title>

<d:Authors>Microsoft</d:Authors>

<d:PackageType>Packages</d:PackageType>

<d:Summary>DbContext API and Code First workflow for ADO.NET Entity Framework.</d:Summary>

<d:Description>DbContext API and Code First workflow for ADO.NET Entity Framework.</d:Description>

<d:Copyright m:null="true"></d:Copyright>

<d:PackageHashAlgorithm>SHA512</d:PackageHashAlgorithm>

<d:PackageHash>tnkDfKdgQUb5gPDR19XTiybeg+ZSvA9TpFnH/dTTzZoBRrNB2SXdu4eTTLz4Qom04srjvdUlipZ+uBI7QlDfvQ==</d:PackageHash>

<d:PackageSize m:type="Edm.Int64">464972</d:PackageSize>

<d:Price m:type="Edm.Decimal">0</d:Price>

<d:RequireLicenseAcceptance m:type="Edm.Boolean">true</d:RequireLicenseAcceptance>

<d:IsLatestVersion m:type="Edm.Boolean">true</d:IsLatestVersion>

<d:ReleaseNotes m:null="true"></d:ReleaseNotes>

<d:Prerelease m:type="Edm.Boolean">false</d:Prerelease>

<d:VersionRating m:type="Edm.Double">3.9</d:VersionRating>

<d:VersionRatingsCount m:type="Edm.Int32">10</d:VersionRatingsCount>

<d:VersionDownloadCount m:type="Edm.Int32">27542</d:VersionDownloadCount>

<d:Created m:type="Edm.DateTime">2011-07-25T17:51:49.943</d:Created>

<d:LastUpdated m:type="Edm.DateTime">2011-07-25T17:53:55.467</d:LastUpdated>

<d:Published m:type="Edm.DateTime">2011-07-25T17:54:05.547</d:Published>

<d:ExternalPackageUrl m:null="true"></d:ExternalPackageUrl>

<d:ProjectUrl>http://msdn.com/data/ef</d:ProjectUrl>

<d:LicenseUrl>http://go.microsoft.com/fwlink/?LinkId=224682</d:LicenseUrl>

<d:IconUrl m:null="true"></d:IconUrl>

<d:Rating m:type="Edm.Double">4.4150943396226419</d:Rating>

<d:RatingsCount m:type="Edm.Int32">53</d:RatingsCount>

<d:DownloadCount m:type="Edm.Int32">80779</d:DownloadCount>

<d:Categories m:null="true"></d:Categories>

<d:Tags m:null="true"></d:Tags>

<d:Dependencies></d:Dependencies>

<d:ReportAbuseUrl>http://nuget.org/Package/ReportAbuse/EntityFramework/4.1.10715.0</d:ReportAbuseUrl>

<d:GalleryDetailsUrl>http://nuget.org/List/Packages/EntityFramework/4.1.10715.0</d:GalleryDetailsUrl>

</m:properties>

</entry>

Thanks Joe