SSRS Report Viewer only works when Fiddler2 is running - wpf

I have a WPF application using a WinForms Report Viewer control.
The report control loads reports from SSRS 2008.
All was working fine until we moved to a new server.
All users can connect and authenticate to http://SERVERNAME/reports and run reports with no issues.
Certain users can run the reports from the WPF app but other users get the message:
“The request failed with HTTP status 401: Unauthorized”.
I figured I would install Fiddler2 and see what traffic was being passed around.
Unfortunately (or fortunately), the reports load correctly in the Report Viewer control when Fiddler2 is running.
Why?
Though this is a "temporary workaround"; it is definitely not ideal.
And according to Fiddler... it works. The traffic appears to be valid I have nothing to fix.
Any ideas?

The problem ended up being a bad configuration of a Barracuda Networks web filter proxy running on the network. The proxy was getting in the way of the Report Viewer control authenticating. Why it still worked in IE or why it worked when Fiddler was running is still very strange to me but at least I now know what solves the problem.

Related

How can I avoid getting a 'Permission needed / Bad Request' dialog when opening an Office 365 Addin?

My team is in the process of developing an Office 365 add-in, specifically to enable interaction with a hosted web application, and we're encountering a "Permission needed / Bad Request" error that we can't seem to pin down.
Context:
Developing and testing the add-in involves configuring an Azure Active Directory v2 application via the management portal as well as (for development purposes) creating an xml manifest file (which is for v1 apps as opposed to the json format for v2) that can be side-loaded via the O365 interface to provide access to our hosted app (currently only xml manifests can be side-loaded). We're still very much in the process of figuring things out in Office 365, as well as Azure/Active Directory and Microsoft Graph, and the documentation is fairly broad and doesn't always seem to be up to date.
Problem Description:
One of the problems that we're run into occasionally is encountering a "Bad Request" dialog message (in a browser dialog titled 'Permission needed') that is displayed when clicking the toolbar icon for our add-in. The actual URL being requested is similar to https://store.office.com/client/consentnotification.aspx with a number of parameters representing our application and it's required permissions. This results in an HTTP 400 with "Bad Request" being the only response content.
This is happening when the user clicks on our add-in in the O365 application toolbar and is occurring at the point where the user would have to authorize permission for the add-in.
This error seems to be related to the application configuration, but we can't seem to sort out how specifically (ie, some developers are encountering it, and others are not. Sometimes it'll show up if we recreate the Azure Active Directory application using one version of portal or another (there are currently two, with the v2 version being in preview).
Can anyone offer suggestions as to what might be causing this or provide information on why this might be occurring? We're not blocked, but it is rather annoying to deal with in development. I've done a fair bit of research trying to sort out why this is happening and I've gone through a number of tutorials/introductions on configuring Azure apps without success.
This turned out to be related to the Azure Active Directory Application configuration.
For the applications where this was occuring, the AADv2 application manifest was using a "signInAudience" value of "AzureADMyOrg". For cases where it was working as expected (ie, properly populating the permission request dialog) the "signInAudience" was set to "AzureADandPersonalMicrosoftAccount".
After some testing, the solution for our particular problem seemed to be either manually editting the AADv2 application manifest (json) to have "signInAudience": "AzureADandPersonalMicrosoftAccount", or via the Portal by setting the Application's Authentication Supported Account Types setting to be "Accounts in any organizational directory" (this results in a manifest setting of "signInAudience": "AzureADMultipleOrgs" which also seems to work).

SharePoint 2010 and Silverlight

We currently have a Silverlight application which is hosted in a SharePoint 2010 page. The Silverlight app makes web service calls to a another server on our domain, which has a clientaccesspolicy file in place. We are experiencing cross-domain issues in our production environment.
Users in the farm admin group can use the Silverlight application without any issues. However, all other users recieve the generic cross domain exception when they try to use this app. We have attached Fiddler to the process and noticed that the farm admins are served the clientaccesspolicy file, but that non-admin users are not. In fact, Fiddler does not ever show an attempt to load this file for non-admins.
This only happens in our production environment, which leads me to believe there is a web config or permission setting causing the issue. Unfortunately, I cannot find anything that backs this up.
Has anyone else run into this issue or know if such a setting exists?
See comments above. I had to change the URL to use the full machine name i.e. from webserver/service.svc to webserver.domain.com/service.svc. It solved the problem but doesn't answer the question about why the farm admins could access it. vorrtex's response is the best possible explanation I have seen so far.

Testing a silverlight application with statlight on Windows Server 2008 r2

I followed the instructions on pyxis-tech.com to test our Silverlight application on TFS2010 on a Windows 2008 r2 Server. If I run the test as part of a build they all fail. Running them on the server as the same user reveals the following:
------------------ Test Failed ------------------
Test Namespace: [StatLight]
Test Class: [CannotFigureItOut]
Test Method: [NotEnoughContext]
Other Info: A Silverlight MessageBox dialog was automatically closed.
Caption: One or more ActiveX controls could not be displayed because either:
1) Your current security settings prohibit running ActiveX controls on this page
, or
2) You have blocked a publisher of one of the controls.
As a result, the page might not display correctly.
Dialog Message:
Web Browser
-------------------------------------------------
Statlight opens it's browser which displays a dialog with the same error message before closing it after a minute or so. The the browser displays the silverlight installation ad even though the silverlight runtime is already installed on the computer.
I've granted the executing user a ridiculous amount of privileges but still had no success. If anyone has had this problem before, I'd appreciate a little help with this.
You have to make sure the service executing StatLight has desktop interactivity enabled.
On the services Log On tab you have to check the "Allow service to interact with desktop"

WP7 Emulator and Fiddler

I know there are a LOT of blog posts on this. But I can't seem to find an answer. I'm trying to debug an application that communicates with some services I have running locally. Right now, I have two services. One of them works. One of them does not. Both are running in http://localhost:90. To help me resolve this, I turned to Fiddler.
Oddly, Fiddler shows traffic in Internet Explorer in the emulator, but it does not show traffic from my application. With my application running, I launch Fiddler and nothing appears. I do not see any traffic. I have been able to confirm that I am successfully accessing the one service. However, no traffic appears in Fiddler. To see if Http traffic is running, I exited my Silverlight application and started Internet Explorer on the emulator. When I visit websites in IE on the emulator, I see traffic being written to Fiddler.
I'm totally confused. What am I doing wrong?
You need to actually configure Fiddler to be able to access localhost. Here is a workaround that needs to be done in the application.
Basically, what you need is the extra dot when accessing the location. So in your case it will be:
http://localhost.:90
Also, you might want to try some additional config settings.

Permission issue running Wpf application in Vista

I created a WPF Desktop application and have tried deploying it to vista without success. The application performs a scan and uploads the data to a web service on the internet. It should also log any exceptions using NLog to the hard drive. When I run the application it errors out when trying to send the data to the web service. If I run it as administrator it works fine. I have tried a number of things but nothing seems to work. Nlog doesn't log the exception so it's difficult to tell what is happening. Any direction would be greatly appreciated.
Adding a strong name to my application allowed it to be given full trust on the machine. This solved any issues getting to the external web service. Go here to learn how to sign your application.

Resources