One tool that I use for debugging is Fiddler.
What is Fiddler? It’s a tool that can be used to debug web applications by capturing HTTP traffic. Not only does it log HTTP traffic for viewing and analysis, it can also be used to modify or “Fiddle” with the HTTP traffic for debugging and troubleshooting purposes. It could also be used for testing out code security and verify if business rules are correctly enforced in code. Fiddler acts like a proxy with HTTP requests flowing through Fiddler before reaching the target web server and HTTP responses flowing through Fiddler before returned to the client app or browser. This is a great way to test your own code or testing out a team member’s code on code review, especially when automated tests have not yet been completed. Similar tools are available such as Postman for Google Chrome, however for this blog post let’s explore Fiddler.
It can be downloaded for free here:https://www.telerik.com/download/fiddler
Use in the Development Cycle?
Let’s say that the client part of the web app is working as required. Depending on the user (security), the data, and the business rules, the Client hides certain features, disables controls until the required fields are entered, filters data and prevents certain actions. As well, validation code is used to check that the data being passed to the server is good and correct. This ensures only valid requests and good data are sent to the server. However, what if a malicious user bypasses the Client and sends request directly to the server? Server code is needed to enforce security, business rules and validate good data is received. These checks are usually done with Unit Tests (testing a single function) and Integration Tests (testing many integrated features). With Test Driven Development, each new function or feature begins with writing tests and adding code to make the tests pass. Here is a good image to explain this concept:
However, what if the usual coding process of the team is to write the tests after the client and server code has been landed. For example, it’s a brand new app being coded, using fake test data and the pipeline only pushes the code to live only after all test are written. Also, many developers are working on one PBI (product backlog item). Some work on the Client, while the others split up the Server code to work on in parallel and at the end, they merge the code and then work on the Data Test Providers (providing good sample data for the tests to consume) and then create the unit and integration tests. While developing the Server code, a developer would like to test their server code they just wrote to see if it correctly enforces the business rules. Instead of landing untested code and then refactor to fix after, they could use fiddler to create an HTTP request to debug and step through their new code. Let’s say the client code for the new feature has enough completed to send a request to the server.
Fiddler used for Debugging:
As mentioned in the overview, Fiddler also allows you to “fiddle” with HTTP requests and responses. Fiddler can capture a good PUT request from the Client, and make a copy for later modification of its JSON payload data. It’s then interesting to change the JSON payload data to incorrect values, then execute/send the modified REST request to the sever and then step through the server side code to see if it correctly handles/validates/enforces the business rules correctly for request with both good and bad data (and throws any proper errors back to the client for bad data). Of course writing tests to cover all scenarios and business rules would be much more thorough and complete, but Fiddler could be used to run through a quick/basic test of the logic as a start pre-tests.
Step by Step Example:
It will automatically start capturing HTTP traffic … File -> Capture Traffic:
Make a request with your client app. Open your client app and click on the item to be tested to generate/send a request.
Then Turn off Capture traffic by unchecking … File -> Uncheck Capture Traffic:
Find the Request in the list: (Request was blurred):
Then on the right side … Click composer tab:
To compose/clone a request, drag and drop a request from the Web Session List on the left into the composer on the right: (Request was blurred):
Then modify the Request Body with different values to test: (Request was blurred):
Then click Execute in the top right hand corner.
Place a break point in your server project and test. Run in Debug Mode.
You may need to turn on Auto Authenticate. Note: This option automatically responds to HTTP 401 and 407 challenges that use NTLM or Negotiate protocols using the current user’s Windows credentials
On the right side (pane) of Fiddler if composing requests: Click Composer tab, checkmark Automatically Authenticate
To capture traffic through a proxy that requires Windows Authentication or network credentials you may need to turn on in the toolbar:
Rules > Automatically Authenticate
If traffic sent to http://127.0.0.1 is not captured, use the machine name or localhost:
http://localhost.fiddler/atestpage.aspx (also works)
Configure your machine to allow requests through the fiddler endpoint:
The post above indicates to add the registry key BackConnectionHostNames (a Multi-Value string) to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 section in the registry with the value localhost.fiddler.