I need to stress-test a silverlight application which uses Windows authentication mode. To achieve this task I am using the StressStimulus Fiddler addin.
What I am doing is to log in and doing some stuff like search etc. I captured the HTTP messages transferred in Fiddler and replayed them using the above mentioned tool.
However, when I replay the packages I always get a 401.1 Server responses.
I tried to use different Authorization approaches (NTLM and Negotiate) but I always get the same response message.
Fiddler seems to be properly configured. In the Fiddler options menun "Reuse client connection" is checked as well as "Reuse connection to server". I even raised the KeepAliveTimeout in the registry without any success.
Does anybody have an idea whats going wrong?
You can't replay authentications such as NTLM and Negotiate. One the most important features of any challange/response authentication is that it must not be replayable. Without this feature an attacker can monitor a successful authentication and then replay the same sequence to gain access to things they aren't entitled.
Related
I am not able to connect to https://test.salesforce.com/services/oauth2/token form SoapUI (ver 5.2.1). I have tried the PRO version and other older versions (4.6.xx) as well.
I can access the website from the web-browser. The GET to this URL gives me the response where as SOAPUI says HttpHostConnectException connection to https://test.salesforce.com/ refused.
I have checked that there is direct connection available from my PC to this address. I have tried adding https.proxyHost and https.proxyPort settings in soapui.vmoptions and sopaui.bat but of no use.
I have also tried playing around with Preemptive Authentication settings in SOAPUI without success
My organization has firewall which has white listed this address. I have also confirmed that firewall settings does allow to connect thru non standard clients (such as ApacheHttpClient).
If I use a Java Program using URLConnection using the proxy, it works.
At this point it seems to me that SOAPUI is not honoring the proxy settings.
Please share if anyone has similar experience and how did they resolve it.
Regards
Ash
I was modifying a WCF service to increase the timeout for a Silverlight client. Before modifying the timeouts I'm seeing CommunicationObjectAborted exception (The HTTP request to [URL] was aborted). At first I only modified the web.coffig of the WCF and it had no effect. I then followed this post (http://blog.ecofic.com/?p=379) and edited ServiceReferences.ClientConfig as well. Now I'm seeing a No endpoint exception. The exception was not thrown immediately after the client connects to WCF, but after about 1 minute after it connected to WCF. I suspect it has something to do with the timeouts?
I set open, close, send and receive timeouts to 5 minutes in both config files.
Any idea? Thanks!
As Richard pointed out, sendTimeout only be needed to set on the client (your Windows Phone app in this case). Double check the ServiceReferences.clientConfig as manually added value might get overwritten by Visual Studio.
Also you can check this post for using Fiddler on Windows Phone (emulator).
You should use Fiddler to analyse the requests performed by your application. This way, you will be able to know what happen when the request is sent, where exactly it is sent (if it is sent), and the response code from the server.
Obtaining these informations is the first step on the way to troubleshoot your issue.
for days now, I try to get the following scenario running:
I have a Silverlight 4 Application that calls a WCF-Service via HTTPS. The WCF-Service is located on one of our servers, the Silverlight 4 app is also served from this server. After several hours of trial and error (well actually more error than try) I get it running when starting it from my VS2010 development environment on my local machine (see also SecurityError when calling a HTTPS-WCF Service from Silverlight 4).
But ...
The call to the https-WCF ONLY works when I start the SL-App from my VS2010 AND when fiddler is running and after I tell fiddler to ignore the Certificate Error (I use a self-signed certificate). When fiddler is not running, I get a security error. That applies, when my browser is the IE. When I copy the localhost address from the IE and paste it in my opera, it works without fiddler.
When I deploy the Silverlight app to the server and call it from the server, the WCF-call doesn't work, whether fiddler is running or not. I just get the standard Message, that an exception has occurred. This happens in both Opera and IE. Fiddler doesn't ask me to ignore the Certificate Error like it does in the VS2010 scenario, so maybe there is somewhere the key to my problem. Unfortunately, I have not much experiences with this stuff, so I have no idea, where to look or what to do.
I already found something about the fiddler issue here on stackoverflow ( Silverlight Requests, Failures & Fiddler), but it doesn't help me solving my problem.
I hope that some of you can shed some light in this issue, before all my hair is turned to gray.
Thanks in advance,
Frank
Edith has just installed the Certificate as a trusted Certificate in IE - but I still get the error, when calling the WCF when starting the deployed silverlight app from the server. At least I can call the Service when I start the SL app from VS2010 in the IE now (even when that doesn't help me, when some one else has to work with the app.
Several thoughts:
What is the exact error message you're seeing? Any inner exceptions?
Could this be a cross-domain issue? (Are the Silverlight XAP and the WCF service hosted from exactly the same domain, including its HTTP vs HTTPS characteristic, port number, distinction between "localhost" and an actual machine name, etc? What is the exact address as it appears in ServiceReference.ClientConfig or in code, and does its domain name exactly match the XAP's domain name?)
Do you see any call attempting to go through in Fiddler at all when it fails? (If not, I would strongly suspect a cross-domain issue)
If you manually browse to the https://....../YourService.svc from IE/Opera (instead of invoking the service through code in Silverlight), can you successfully see the service information page, with no certificate warnings/errors?
Does your SSL certificate has the same name as your service host? If not, that causes an error which can lead to the described behavior
What is the correct way of handling errors on the client side of Silverlight applications? I tried building a service endpoint that would receive details about the error and then would write that string to the database. The problem is, the error's text exceeds the maximum byte length, so I can't send the exception message and stacktrace. What would be a better way of handling errors that end up at the client side?
Try handling faults...I used this pattern from MSDN
http://msdn.microsoft.com/en-us/library/dd470096%28VS.96%29.aspx
If you find you message is too long to send to your logging web service then try setting your binding properties such as maxBufferSize and maxStringContentLength to appropriately large values. They default to 16KB, personally i have set mine to 2147483647 (which is int.MaxValue).
Obviously you cannot send the raw exception straight to the logging web service (exceptions are not serializable), what i did was write a function that takes an exception and walks it, translating it into a WCF friendly structure that can then be passed to my logging end point. Of course you need to ensure that if this fails you have a backup plan, like maybe logging it to isolated storage if you are running in browser, or logging it to the user's file system if you are running elevated OOB.
You should not be considering logging of error messages via a service. What if the error that you want to log is related to the service itself? Maybe the server that hosts all dependant services (including the error logging service) is not reachable or down. client errors should be logged on the client side and periodically flushed to the server when connectivity to service is available.
Thats what I would do...
Take a look at the new Silverlight Integration Pack for Enterprise Library from Microsoft patterns & practices. It provides plumbing for both logging (client-side and via a remote service) and exception handling with flexible configuration of policies via config or programmatically.
I've got a Silverlight application that makes a cross-domain request. The clientaccesspolicy.xml file exists on the server I am making a request to and is correctly configured.
I know that it is correctly configured because when I use the application to make a request from my machine I receive a response with no problem.
When a second individual on a corporate network about 300 miles away tries to use the same application, launched from the same URL, to make the same request, he instead gets a security exception.
Here's the odd part. I requested that he download Fiddler so that I could see the request and it's response, and thereby gain some insight into the problem, but when he runs the app with Fiddler open, the request succeeds.
This happens in both Chrome and IE. With Fiddler everything is fine. Without it, it doesn't work.
We've tried clearing his history, deleting the Silverlight app from the cache, everything I can think of.
The request is being made to a private network (which he is on), I make the request through a VPN connection to that network (in case for some reason that matters).
Any thoughts as to what's causing this bizarre problem?
Despite the fact the Fiddler "fixes" the issue it would still be worth while getting this second individual to save a .saz file from fiddler for the successfull set of sessions and then for you to compare them with a successfull set you have from your own machine.
An analysis of the differences may reveal a potential cause when fiddler is not in place.
Another approach would be to use a network protocol anaylser such as Wireshark. The elimination of the proxy that Fiddler represents may be enough to expose the problem, of course such tool is much more technical.
This post is simply to catalog the solution for future users. Thanks to everyone who helped.
The actual problem turned out to be (just as EricLaw -MSFT- suggested) that the client's machine was zoning the request URL as Intranet and the Silverlight application as Internet, and I am not permitted to make requests across zones.
EricLaw's direct responses may be viewed in the comments under the original question.
The URL below (provided by Eric) contains information regarding the denial of cross-zone request, as well as solutions.
msdn.microsoft.com/en-us/library/bb250483(VS.85).aspx