I need to simulate web response for web requests during some tests. I was going to use fiddler core for that. So fiddler just acts like a proxy and Im able to set response for every request I like. But I need to run something like console application or standalone application to make fiddler core able to intercept the requests. And I need it to be somehow initialized inside my asp.net mvc test application, so that tester could access these fake data, by just using the urls, without the need to run fiddler or any other applications.
For now I tried to run my fiddler application in Controller action method, but it doesnt intercept anything.
I also tried to add URLMonInterop.SetProxyInProcess("127.0.0.1:"+ myPort, ""), but it doesnt work either.
Is there any way to self host fiddler core app and make it intercept the requests?
UPDATE:
In the end I managed to host fiddler core inside asp.net mvc app. I made initialization in a static method of a static class and it did the trick. Also, for some reason after calling shutdown and then performing initialization again I cant proxify anything. I even cal GC.Collect, nothing helps, but refreshing the host process, in my case IIS express.
As documented, SetProxyInProcess affects URLMon clients only, and .NET doesn't use URLMon for networking.
.NET clients typically pick up the current proxy setting automatically, but if you're running FiddlerCore in a different user account, that's not going to work (and you probably don't want your mocker to be messing with any traffic except your test application). So, instead you should configure your application explicitly to proxy its traffic through your FiddlerCore instance; see http://fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET and http://fiddlerbook.com/fiddler/help/hookup.asp#Q-IIS and if your services are local http://fiddlerbook.com/fiddler/help/hookup.asp#Q-LocalTraffic
Related
I am working on an API in .NET core 2.
Everything works great when testing on https://localhost:44333, but when trying on http://localhost:44333 it does not work anymore. It just loads, and loads, and loads.... Nothing to see in the logs or anything like that.
The thing is, I need to get it working on HTTP because I want to try it on my phone in the app. So I use iisexpress-proxy to proxy it. This works when I can access the API on HTTP, but it doesn't work with HTTPS.
So therefor I need it to work with HTTP, but I have no idea why it does not work on HTTP. All my previous projects worked fine on HTTP and for some reason this one does not. I have looked in my startup if it might be forced or something like that, but I cannot find any...
You probably need more information than this, but I don't know what you need, so If you ask in the comments I will provide some more information/logs/code you name it.
The http version will be served on a different port. You'll need to look at your project properties to see which port it's being served on.
Just as some background:
There's effectively a client-side and server-side component to SSL. The http or https is the client-side component. That means the browser or other web client will either try to negotiate a secure socket or not, respectively. The server-side component is the port binding, which will either be a secure socket or not.
The forever-loading is because your client is trying to make a non-secure request, but the server's socket is attempting to negotiate SSL. It's like one person speaking Chinese and the other speaking Spanish. They're both communicating, but nothing gets accomplished.
I want to look at the XML created in my HttpRequest but can't see how. I've tried looking at the request during runtime but no luck.
I'm working in a .NET 4.0 project (just for context here, not that it matters much starting with 2.0)
I'm making a call to a third party API via my project's service reference:
SomeResponseType response = _apiClient.AddUser(userToAdd);
So how do I capture what AddUser is creating in terms of the raw XML being sent to the host without having to go through the pain of creating an Intercept filter which is not the easiest thing to put together?
You should be able to use Fiddler on your machine to capture the underlying HTTP request.
Alternatively, if you're using WCF, you can enable tracing via your config file. To go this route, see Configuring Message Logging. Then you can use the Service Trace Viewer Tool (SvcTraceViewer.exe) to pretty print your logs.
You can use a network sniffing tool such as Fiddler (www.fiddler2.com). Simply fire up Fiddler and then run your app. Fiddler will capture all of the traffic that is going across the wire, and you can look at the XML that is being sent and received from the SOAP service.
This question is a consequence of the following question: determining which server (in a web farm) the asp.net ajax request came from?
The problem is that we commonly use automatically generated proxy classes to communicate with the web method (which may be part of asmx/wcf service). When we receive the response from the web services server, how do we know which server it got processed from?
We receive the response from the server side code which is executing (mostly). When its a script service (which can be called via javascript) its another case altogether.
How can we read the response headers once the web service returns?
Am I constrained to build my own proxy classes to solve this problem?
One way. Its not the best way but it will do until something new comes about. If you have a tool like fiddler/burp, you can inspect the response headers. So we must configure the IIS to set the response headers appropriately.
By default they are configured to output something like X-ASP.NET...a good idea would be to add the server name to that...
Is it at all possible to inject a request into IIS for a page, have IIS and ASP.Net handle it as normal, but get the response as html handed back to me programmatically?
Yes, I know that I could connect to port 80 using WebRequest and WebResponse, but that becomes difficult if you are accessing the IIS server from the same physical machine (loopback security controls et al).
Basically, I want to inject the request (eg for http://example.org/MyPage.aspx) between the points at which IIS would normally talk to the browser, and the point at which it would route it to the correct ASP.Net application, and get a response back from IIS between the points at which ASP.Net/IIS applies the httpfilters and hands the html back to the browser.
I'm predominantly working with IIS7 so if there is a solution that works just for IIS7 then thats not an issue.
You could implement a custom HttpModule, which would give you access to the IIS pipeline, including the final response. However, you would still need to initiate a request to IIS to actually kick off processing. Not sure if this would work for you.
From the MSDN documentation:
An HTTP module is an assembly that is
called on every request that is made
to your application. HTTP modules are
called as part of the request pipeline
and have access to life-cycle events
throughout the request. HTTP modules
therefore let you examine incoming
requests and take action based on the
request. They also let you examine the
outgoing response and modify it.
Gave you looked into the WebCkiebt class? You can make the request and get the response HTML.
http://msdn.microsoft.com/en-us/library/system.net.webclient.downloadstring(v=VS.100).aspx
I have an HTTP Module to handle authentication from Facebook, which works fine in classic pipeline mode.
In integrated pipeline mode, however, I'm seeing an additional request pass through for the default document, which is causing the module to fail. We look at the request (from Facebook) to retrieve and validate the user accessing our app. The initial request authenticates fine, but then I see a second request, which lacks the posted form variables, and thus causes authentication to fail.
In integrated pipeline mode, an http request for "/" yields 2 AuthenticateRequests in a row:
A request where AppRelativeCurrentExecutionFilePath = "~/"
A request where AppRelativeCurrentExecutionFilePath = "~/default.aspx"
That second request loses all of the form values, so it fails to authenticate. In classic mode, that second request is the only one that happens, and it preserves the form values.
Any ideas what's going on here?
UPDATE: Here is an image of the trace from module notifications in IIS. Note that my module, FBAuth, is seeing AUTHENTICATE_REQUEST multiple times (I'd expect 2 - one for authenticate and one for postauthenticate, but I get 4).
I'm starting to believe this has something to do with module/filter configuration because I've found a (Vista) box running the same code that doesn't fire these events repeatedly - it behaves as expected. I'm working through trying to figure out what the difference could be...
Thanks!
Tom
My solution was to add the following code at the end of Application_BeginRequest:
if (Request.RawUrl.TrimEnd('/') == HostingEnvironment.ApplicationVirtualPath.TrimEnd('/'))
Server.Transfer(Request.RawUrl+"Default.aspx", true);
DefaultHttpHandler is not supported,
so applications relying on sub-classes
of DefaultHttpHandler will not be able
to serve requests If your application
uses DefaultHttpHandler or handlers
that derive from DefaultHttpHandler,
it will not function correctly. In
Integrated mode, handlers derived from
DefaultHttpHandler will not be able to
pass the request back to IIS for
processing, and instead serve the
requested resource as a static file.
Integrated mode allows ASP.NET modules
to run for all requests without
requiring the use of
DefaultHttpHandler. Workaround
Change your application to use
modules to perform request processing
for all requests, instead of using
wildcard mapping to map ASP.NET to all
requests and then using
DefaultHttpHandler derived handlers to
pass the request back to IIS.
Hmmm, or this could be the issue.
ASP.NET modules in early request
processing stages will see requests
that previously may have been rejected
by IIS prior to entering ASP.NET,
which includes modules running in
BeginRequest seeing anonymous requests
for resources that require
authentication ASP.NET modules can run
in any pipeline stages that are
available to native IIS modules.
Because of this, requests that
previously may have been rejected in
the authentication stage (such as
anonymous requests for resources that
require authentication) or other
stages prior to entering ASP.NET may
run ASP.NET modules. This behavior is
by design in order to enable ASP.NET
modules to extend IIS in all request
processing stages. Workaround
Change application code to avoid
any application-specific problems that
arise from seeing requests that may be
rejected later on during request
processing. This may involve changing
modules to subscribe to pipeline
events that are raised later during
request processing.
http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/