2

I have a report that seems to work fine, but when trying to download it in my asp.net MVC application, I get a 500. I am simply trying to download a pdf version of it using URL access. To do this I do the following:

WebClient client = new WebClient();
NetworkCredential nwc = new NetworkCredential(ConfigurationManager.AppSettings["SSRSUserName"], ConfigurationManager.AppSettings["SSRSPassword"]);
client.Credentials = nwc;
string paramList = "&OrderId=" + orderId;

string reportURL = ConfigurationManager.AppSettings["SSRSBaseUrl"] +
            ConfigurationManager.AppSettings["SSRSReport"] + 
            "&rs:Command=Render&rs:Format=PDF" +
            paramList;
try 
{
     byte[] reportBytes = client.DownloadData(reportURL);
}

To verify that my report works fine, I took the resulting reportURL string, threw it in a browser, and sure enough my report downloaded perfectly.

Does anybody know why I would get a 500 in my application, but the pdf would download perfectly fine outside of my application with the same URL? Is their some configuration that I am missing?

The server version is SQL Server 2016

Jon
  • 278
  • 8
  • 23
  • 1
    Two suggestions, which are somewhat trial and error. Rather than using a string, define the URL as a [Uri](https://msdn.microsoft.com/en-us/library/system.uri(v=vs.110).aspx) and pass that to `DownloadData`. I am wondering if internally `DownloadData` has expectations regarding encoding of URL parameters and the default encoding of the `WebClient` is causing the URL to become malformed. The other is to impersonate a browser by setting the user agent similar to: `client.Headers.Add(HttpRequestHeader.UserAgent, "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)");` – Jonathon Ogden Aug 15 '16 at 20:49
  • @JonathonOgden I tried to switch my url string to a uri and didn't have any luck. When trying to impersonate a browser I'm getting a couple of compilation errors with the line that you provided. VS is saying: Unexpected character ". Any idea why this wouldn't compile? Thanks – Jon Aug 15 '16 at 21:34
  • @JonathonOgden not sure what I did, but I got it to compile and it still doesn't work while impersonating a browser. – Jon Aug 15 '16 at 21:50
  • Okay, one more question I overlooked. Is there any particular reason you want to download the data rather than the file itself? What are you intending to do with it? If you're looking to just programmatically download and save the file, use `DownloadFile` instead. – Jonathon Ogden Aug 15 '16 at 23:10
  • @JonathonOgden I am not just downloading and saving the file. After getting the file, I am immediately sending it to a printer using PrintDocument. Is there a way to do this with a file? To me it makes more sense to just download the data and pass that to PrintDocument. – Jon Aug 16 '16 at 14:13
  • There is, yes. I came across the generic 500 internal error when trying to `DownloadData` and `DownloadFile` using default credentials from a reports server on a system with UAC enabled. Running the application that downloads the report file as administrator got me past that error. Is UAC enabled on the system you are running this on? If so, as a simple test, run the application as administrator and/or with default credentials `client.UseDefaultCredentials = true`. – Jonathon Ogden Aug 16 '16 at 15:31
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/121080/discussion-between-jonathon-ogden-and-jon). – Jonathon Ogden Aug 16 '16 at 16:01

1 Answers1

2

To summarize the discussion and solution, using default credentials by setting the property UseDefaultCredentials = true for the WebClient resolved the generic 500 internal server error.

Since your installation is post SQL Server 2008, authentication requests are handled internally by the Reporting Services instance.

In previous versions of Reporting Services, all authentication support was provided by IIS. Starting with the SQL Server 2008 release, IIS is no longer used. Reporting Services handles all authentication requests internally.

By default, the Reports Server uses authentication methods that rely on Windows Integrated authentication: Negotiate and NTLM as mentioned in Authentication with the Report Server.

Since the Reports Server in this case is using one or all of the following authentication methods: Negotiate, NTLM and Kerberos and this is not an ASP.NET application, default credentials need to be used as explained in DefaultCredentials:

The DefaultCredentials property applies only to NTLM, negotiate, and Kerberos-based authentication.

DefaultCredentials represents the system credentials for the current security context in which the application is running. For a client-side application, these are usually the Windows credentials (user name, password, and domain) of the user running the application. For ASP.NET applications, the default credentials are the user credentials of the logged-in user, or the user being impersonated.

This is why you could access the Report Viewer via the URL in your browser but not in your application.

Community
  • 1
  • 1
Jonathon Ogden
  • 1,562
  • 13
  • 19