There are a number of tools one can use to capture HTTP requests for debugging purposes:
Request.bin
Hookbin
Puts.box
However, all of them provide a simple url such as request.bin/axyz. As I am testing a Rest API, I can set my base url to be request.bin/axyz but my request will look like
PUT request.bin/axyz/clients/3
and will not be matched by any of the mentioned tools. Are there useful tools?
If you are doing testing on desktop machines, you can simply try an HTTP Proxy.
Charles Proxy and Fiddler (and many more) must do the trick.
Related
I know, that some web-clients can't use PUT/PATCH/DELETE http methods.
I heard about clients, which uses Flash, and about simple http forms.
Have you had such problems? With which web-frameworks on client side?
Should I expect some problems with custom http headers, which some clients will not be able to send? (e.g. X-HTTP-METHOD-Override)
All these three methods are not commonly used and by default
GET
POST
QUERY
are three methods that are allowed so if you want to use
PUT
PATCH
DELETE
You will have to configure them in your webserver to allow these methods which depends on framework and server configuration in which your application is running
What would be the best way to handle redirect URIs for OAuth authentication?
In a few projects, I used to boot up a web server that would wait for the authentication to be sent back. Is there any way to trigger any type of code without a local web server, or is it the recommended way?
I'm not asking for help about any specific languages, this is more like a language agnostic question.
Side note: nice avatar... :)
Deciding on the best approach will depend on the exact scenario and any additional requirements your application might have, however, we can look at a few options and possible implication of choosing them.
The OAuth 2.0 specification suggests a few options to solve this issue, either using an embedded user-agent or relying on an external one.
The embedded user-agent may allow you better control on the UI aspects, however, by leveraging an external user-agent your users might benefit from an already established session and avoid having to input credentials one more time.
For an external user-agent we have a few options:
External user-agent - the native application can capture the response from the authorization server using a (1) redirection URI with a scheme registered with the operating system to invoke the client as the handler, (2) manual copy-and-paste of the credentials, (3) running a local web server, (4) installing a user-agent extension, or by (5) providing a redirection URI identifying a server-hosted resource under the client's control, which in turn makes the response available to the native application.
Option 1:
You configure a redirect using a custom scheme that your application registered in the operationg system, this way your application gets called when an external user-agent receives a response indicating a redirect to your scheme.
Option 2:
You redirect somewhere that just shows a pretty page with the code and ask the user to input it manually in your application.
Option 3:
You already used this one, basically the application starts a local web server and you configure the redirect to be something along the lines of http://localhost:[port]/.
Option 4:
By installing a user-agent extension you would have code running with the browser that could communicate the code automatically to your applications.
Option 5:
You configure a redirection URI that points to some server-side code you host and that your client Android application is aware of so that it can grab the code from that URL.
For much more information on this topic, check: OAuth 2.0 for Native Apps
As an additional not, if you don't want to go full server-side on the options that require some logic on the server, you can accomplish the same using much less lines of code by writing your server-side logic as a Webtask (be sure to use a custom domain).
Disclosure: I'm an Auth0 engineer.
I'm using WCAT to load test my app, and I want to see the traffic in fiddler.
When I run the WCAT script, it runs OK,but I don't see any of the traffic in fiddler... Do I need to configure fiddler to proxy WCAT traffic?
The web app I am testing is on my local machine, but I'm not addressing it with "localhost", I'm using the name of my machine in my settings config. I don't have any filters set up in fiddler either.
EDIT:
Here's my transaction I'm testing with (the ipv4.fiddler is a recent addition as per a suggestion below):
transaction
{
id = "add a new user";
weight = 1;
request
{
verb = POST;
postdata = "Name=Bob+Smith&Gender=M&DateOfBirth=01%2F01%2F1970&Email=testuserdude" + rand("1","1000") + rand("1","1000") + "#example.com&Password=123456&ConfirmPassword=123456";
url = "http://ipv4.fiddler/TokenBasedLoginTests/Account/Register";
statuscode = 302;
}
close
{
method = ka;
}
}
Thanks
Matt
Per http://blogs.iis.net/thomad/archive/2010/05/11/using-the-wcat-fiddler-extension-for-web-server-performance-tests.aspx,
WCAT requests won't show up in Fiddler
nor can a proxy server be used with
WCAT.
The former part of that statement is implied by the latter part. It suggests that the WCAT team specifically removed the ability to use a proxy server, which seems like an odd choice, but might make sense if they thought the load would take down a proxy.
If you wanted, you could configure Fiddler to run as a reverse proxy, and then point WCAT at that reverse proxy; you'd see the traffic then, and Fiddler would redirect inbound requests to their actual destination. See http://www.fiddler2.com/redir/?id=reverseproxy
You might consider using the Visual Studio Web Test tools instead, as they do properly use the proxy (and hence Fiddler).
You could use an extension like this one http://blogs.iis.net/thomad/archive/2010/05/11/using-the-wcat-fiddler-extension-for-web-server-performance-tests.aspx
What happens when you use the server of http://ipv4.fiddler? Local traffic doesn't go through Fiddler, but it adds the ipv4.fiddler as a proxy on top of wininet (I may be getting that wrong and Eric Lawrence will correct me, I'm sure), and as a result, can capture local traffic?
I use Fiddler quite a bit to test web apps and services and always use ipv4.fiddler to capture my local traffic.
Hope this helps!
You can easily track WCAT traffic (very useful for debugging) using a transport level tool (such as Wireshark or Ethereal) rather than an HTTP proxy. These tools are able to capture traffic at the network card/packet level. All you need to do is...
a) Run a capture with a filter enabled to limit to traffic between client(s) and server and using a particular protocol (i.e. HTTP) - There's always a lot of unrelated traffic flowing through your network card and adding the filtering will make things easier. If you have multiple clients it might be best to run the capture on the server.
b) Tracing a stream (normally just click on one of the packets related to the request / response and rebuild it to a request / response.
Note that this will impact on throughput/performance. Best to turn it off for a real run! Hope this is helpful!
This is quite a straight forward question that I can't seem to find a comprehensive answer for. When using Selenium and Selenium proxy, how I can make the proxy catch outgoing xhr requests to specific uri's and modify the destination to a pre-mocked alternative.
I found this example form googling, http://www.sonatype.com/people/2009/10/selenium-part-4/ but it doesn't seem to explain how to write the mockHelper methods...
Thanks
Simon
This would require modification to the proxy server. There are no means otherwise to muck around with the response bodies. Your two options are to modify the proxy in the Selenium RC distribution, or alternatively, provide your own proxy server elsewhere. You can have the Selenium proxy connect to your proxy or you can configure the browsers to connect directly to your proxy. This would allow you to configure squid or whatever your comfortable with to deal with the request.
Is there a tool that can test WSE-Enabled SOAP Web service?
I think you want to check the outgoing and incoming soap packets.
Use fiddler.
http://www.fiddler2.com/fiddler2/
As soon as you hit the webservice, fiddler will display the outgoing request's xml.
You can also try out firefox's console (disable by default). The console shows all the request/response details.
Fiddler will get the job done for sure.
I'm not entirely sure about the WSE element, but my first port of call for testing SOAP Web Services is SoapUI
A brilliant tool for calling services and inspecting the results with minimal effort - even before you start to look at its in depth capabilities (which are considerable) and far easier than playing with proxies in the first instance.