So far I've been successfully using fiddler to sniff web service traffic from both test fixtures, console apps and web projects.
Today I noticed I am not able anymore to sniff that kind of traffic if I am running my web application (it's a ASP.NET website, hosted locally on IIS). I see all the local traffic but the web service traffic is just gone (the service is being hit as I do see the response debugging into the code).
I am still able to successfully sniff soap requests and responses from test fixtures or console apps in the same solution (exact same environment).
If it was a windows (I am on Win7) security update or the likes it would never work I guess (unless it affects only traffic routed through IIS).
What should I be looking for that could cause the emergence this behavior?
Any pointers appreciated!
NOTE: I can see local traffic, but not the SOAP request/responses to the web service which is not hosted locally anyway (it's a sandbox another team is providing)
EDIT: This bit of configuration did the trick (found on Rick Strahl's blog)
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:8888"/>
</defaultProxy>
</system.net>
What's the client of the web service? ASP.NET?
ASP.NET traffic isn't proxied unless you configure ASP.NET to use a proxy. It's possible/likely that the app.config or machine.config changed such that traffic is no longer getting proxied?
You should have a look at this section: http://www.fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET
If you want to view the http traffic between your web site and your web service on your development machine, and don't want to change your machine.config.
One easy solution is to change the Application Pool Identity of your web site to use your own credentials of the current logged on user. This means that your web site will adopt your proxy settings and will now redirect to Fiddler.
Make sure the web service you are calling (from IE) is not http://localhost/yourwebservice
Fiddler will not intercept localhost traffic from IE, use http://machinename/yourwebservice instead.
I ran into this issue a week or so ago. Try this page: http://docs.telerik.com/fiddler/Observe-Traffic/Troubleshooting/NoTrafficToLocalhosthttp://www.fiddler2.com/fiddler/help/hookup.asp#Q-LocalTraffic
The ipv4.fiddler was the part that worked for me. Hope this helps.
You're probably using a port other than 80 for these http requests. I remember setting up a reverse proxy to look at WCF requests I was making on my local machine during dev. Here's the documentation:
http://www.fiddlertool.com/fiddler/help/reverseproxy.asp
Can you try the following -
Try stopping the windows firewall and see what happens
try using firefox and redirecting traffic to fiddler and see what happens
Related
I have on-prem TFS within a small domain that we RDP into. Development machines are in this domain/enclave as well. Prior to the most recent TFS upgrade, we were able to connect Visual Studio to TFS and browse the TFS web UI using HTTP only within the enclave. We could also use HTTPS from outside the enclave (no http) to access the web UI. With the latest upgrade, I have mirrored the IIS authentication, SSL and binding configurations but now pointing a browser or Visual Studio at the HTTP only address always redirects to the HTTPS address and forces the SSL login. This is a problem for us because we use a large enterprise PKI infrastructure (access cards, non-local services, etc) that is very flaky: constantly dropping the Visual Studio connection to TFS and asking for PIN re-entry every 2 - 3 minutes. How can I stop the http address from re-directing to https all the time in our enclave? Is TFS doing this now? or IIS?
Since TFS2017 server changed the Authentication from NTLM to KERBEROS by default. You could use the following command to use NTLM back:
TFSConfig Authentication /provider:NTLM
And please try to create a new DNS, then check the result again.
If you want to remove Https, you should change the "Public URL" to http in TFS administration console, removed the HTTPS bindings from IIS.
If above is not work, try to uninstall and re-install the Application Tire and choose the http only option.
For more details take a look at this similar question: TFS 2018 - remove HTTPS
Got it. Found this article describing the redirect behavior from the URL. Long story short-> In IIS, select the TFS under Sites, then Application Settings, setting name sslOnly was set to true. Changed to false. Now I can access the TFS portal from inside the enclave using http OR https and from outside using https only. This means that VS can also connect to TFS via http only.
I have an ASP.NET application that uses the DocumentDB .NET SDK (latest version v 1.10).
I am using the new local emulator.
When the app is started locally, I am not able to see the requests made by my .NET SDK to local emulator in Fiddler. However, I can see in Fiddler the requests to local emulator made by the web application "Data explorer" (shipped with Local emulator) in my browser. I can also browse in Fiddler DocumentDB requests from my locally deployed web app on a remote DocumentDB endpoint (in Azure).
I suspect there is some configs to be set in .NET SDK so that requests are intercepted by Fiddler proxy.
We finally managed to find a solution with two things to change:
In documentdb client instanciation set connectionPolicy.EnableEndpointDiscovery = false; (do not push this to production)
And replace the documentdb endpoint url from https://localhost:8081 to https://localhost.fiddler:8081
You can use fiddler to see the request and response if you choose Gateway or DirectHttps mode.
When you use .NET SDK, it will not automatically direct to the fiddler proxy so that you won't see your request/response automatically.
You can either set the proxy in your app config
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:8888"/>
</defaultProxy>
</system.net>
Or you can use https://localhost.fiddler, which will go through fiddler proxy so that request/reponse is captured. Note this option will make request to fail if fiddler is NOT running.
Are you using Direct mode while connecting to the local emulator?
Fiddler will not be able to intercept requests when using direct connectivity since it can only intercept http traffic. Changing the connection policy to gateway should allow fiddler to intercept the requests.
I installed an ASP.net application on a windows Azure VM (IIS 7). SSL certificate is installed, configured and the application works correctly. I have removed Http binding and http endpoints.
The issue I am having is that if I use the cloudapp.net link (using https), the application still opens with a mismatched certificate.
What can I do to deny any user from opening my application using https://xx.cloudapp.net/x?
It seems really silly that people are saying this isn't the right place for this question, since some of the solutions could be code related. ie: In your application, check the host and if it's cloudapp.net, do a URL redirect.
There's a few different options here but it sounds like what you're looking for is just the ability to prevent someone from viewing the application using that URL.
What I would do is set up a site in IIS that uses Host Header resolution to look for xx.cloudapp.net. If that URL is recognized, do a redirect using the HTTP redirect settings to the https version of your app. Don't bind the SSL port to this site or you'll run into SSL errors like you showed above.
The other option is to leave it out entirely and simply use the Host Header resolution to filter out requests for your site. I suspect what you've done is assign all incoming requests to the only IP address on the system, which is why the xx.cloudapp.net is showing your app and the cert is failing.
This would cause xx.cloudapp.net to fail to show any site at all but I think that might be what you want to do anyway.
I have an ASP.NET MVC 4 application that needs to query another application to process requests. The MVC application makes it's request via REST. I can see the incoming HTTP request from the browser to the MVC application, but I can't see the outbound REST call from the MVC application to the REST application.
Both applications are running in IIS Express. I access the MVC application localhost:42001 and the REST application is using ASP.NET MVC WebAPI, listening at localhost:42002
How do I get the REST requests that are going to localhost:42002?
The request are making it to the REST application, I can also set and hit breakpoints in that code. I just can't see the traffic in Fiddler.
This is because Fiddler is a proxy. Your browser filters all the requests through Fiddler. Your web server is not proxy'ed through Fidder so web server to web server traffic won't go through Fiddler.
To get that to work, you'd need to tell your web application to use Fiddler's proxy. It seems like you can follow http://fiddler2.com/documentation/Configure-Fiddler/Tasks/ConfigureDotNETApp which has some information on how to configrue your web application to send all requests through the proxy.
Another idea, if you're willing to do some packet sniffing, you could use something like Wireshark and that would capture all traffic coming and going on your computer and then you could filter down to the information you need. This is overkill for what you're looking for, but could help at some point.
By default, Fiddler proxies requests sent from the current user-account. ASP.NET runs in a different user's account. See http://fiddler2.com/blog/blog/2013/01/08/capturing-traffic-from-.net-services-with-fiddler for details on how to capture web traffic from service accounts like the one that IIS/ASP.NET are using.
we have a site (https://oursite.net) in which we display a videostream hosted on http (http://someserver.com). The site needs to be hosted on https, and we don't control the video, so I'm assuming it needs to be on http. we recently added the option to play the stream through the silverlight asp:MediaElement, which works perfectly fine in our test environment (on http) but doesn't work in production (https).
The info on the web is somewhat confusing as I'm having a hard time differentiating between how this stuff worked at different stages in the silverlight development (seems to have been a bit to and fro)
Is this setup possible at all (hosting the player on https but playing a stream on http) with some sort of policy file?
in that case: does this policy file need to be hosted with the silverlight app (on https) or where the streams are located (http)
Thanks for your time
Andreas
You are running into a cross-scheme violation unfortunately. The stream would need to match the same scheme (https) as the hosting application. Unfortunately most streaming isn't available in HTTPS.
Can you check the enableHtmlAccess property on the object tag to make sure it is true? Most media players end up using the HTML DOM bridge to communicate with the web page.
It's also likely that there is a cross-scheme issue: you should try and optimize for all assets being on the same scheme (HTTP or HTTPS).