-1

I'm having a strange problem in a Silverlight Business Application that calls an external API. I'm sure it's just one line wrong or something. The API has one call that uses digest authentication and I handle that all myself. My code was working before, but then I began a transition to hosting the backend API and this front-end website on Azure and something must have changed. Now, before the request comes back to my code to handle, the browser is popping up a login dialog of its own. If I cancel out of that dialog, it moves on to my code and authenticates successfully.

It seems as if the browser is handling the request, noticing the 401 status code, and attempting to resolve it itself. But I do register the ClientHttp factory for the http:// prefix as suggested, and the request type that is created is a ClientHttpWebRequest. Like I said, this was all working about a week ago using the same authentication code and everything, so I'm sure it's just going to be some setting. But I'm not sure where that could be and I haven't found anyone else with this problem.

Curiously, when I publish the ASP project to an Azure website, it all looks and acts as expected, but the login doesn't even pop up the dialog. It simply doesn't do anything when I click "login." So that part looks like maybe an unhandled exception is being thrown then it's not telling me about it, but I'm not sure why that would be the case on Azure but not IIS Express.

Basically, I just don't want that dialog coming up. I am inclined to assume that the same problem that's causing that is whatever is making the Azure-hosted version not do anything.

I've done a fair bit of searching and found this question, "How can I supress the browser's authentication dialog?" which seems to be the same issue, but as I stated a few times, this was working just last week. I do have full control of the API and this site, so I could alter some things to make it suppress HTTP statuses and simply return a 200 with details in the content as a substitute, but I'd rather avoid that extra layer of complexity if it really is something simple, as I imagine it is.

Community
  • 1
  • 1
Matthew Haugen
  • 12,916
  • 5
  • 38
  • 54

1 Answers1

0

After some fiddling, it seems the best way to handle this error is simply to use the WebRequest.Credentials property and populate it, rather than forming my Digest authorization header myself. It isn't exactly what I was going for, but it will do for now. I still don't know why this stopped working in the first place. But what fun is programming if everything goes according to plan?

Matthew Haugen
  • 12,916
  • 5
  • 38
  • 54