Second Life of a Hungarian SharePoint Geek

November 5, 2013

Redirecting a redirection using Fiddler

Filed under: Fiddler — Tags: — Peter Holpar @ 22:51

Recently I’m working on a claims based authentication solution for a SharePoint 2010 application that includes a custom STS that authenticates the users through an external IP by a two-factor authentication (user name and password + TAN sent via SMS). The external IP accepts a redirection URL as a query string parameter, the browser is redirected to this address after the successful authentication. The problem is that the allowed redirection URLs are configured at the IP web application, the list of URLs is maintained by the external company. The URL of our intranet site (no SharePoint / IIS) is on the list of the allowed values, the URL of our SP 2010 development environment is not. We have requested the configuration change of the IP, but in the meantime I wanted to find a way to use the IP as is from the developer server.

My first approach was to use Fiddler to redirect the request sent to the original host (e.g. our intranet) to the developer server. To achieve that, I altered the CustomRules.js of Fiddler like this:

static function OnBeforeRequest(oSession: Session) {
  var siteFrom = ""
  var siteTo = ""
  oSession.url = oSession.url.Replace(siteFrom, siteTo);

It means however, that the original URL is not changed in the browser, only the HTTP request is routed to the other server in the background. So all relative URLs (images, scripts, css files) in the login page of our dev. server are referring to (not existing) resources on the intranet site.

A better approach is to alter the redirection response (HTTP status code 302) sent by the IP to include the URL of the dev. server instead of the URL of the intranet. It can be fulfilled by removing the original Location header and appending a new Location header corresponding to the developer site URL, as illustrated by the code below:

static function OnBeforeResponse(oSession: Session) {
  var siteFrom = ""
  var siteTo = ""
  if (oSession.responseCode == 302) {
    var sLocation = oSession.oResponse["Location"];
    var sNewLocation = sLocation.replace(siteFrom, siteTo);
    if (sLocation != sNewLocation) {
      // optionally append further query string parameters
      sNewLocation += "&ReturnUrl=%2fWingtipSTS%2fdefault.aspx%3fwa%3dwsignin1.0%26wtrealm%3dhttp%253a%252f%252fyoursite%253a2500%252f_trust%252fdefault.aspx%26wctx%3dhttp%253a%252f%252fyoursite%253a2500%252f_layouts%252fAuthenticate.aspx%253fSource%253d%25252F%26wreply%3dhttp%253a%252f%252fyoursite%253a2500%252f_trust%252fdefault.aspx&wa=wsignin1.0&wtrealm=http%3a%2f%2fyoursite%3a2500%2f_trust%2fdefault.aspx&wctx=http%3a%2f%2fyoursite%3a2500%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252F&wreply=http%3a%2f%2fyoursite%3a2500%2f_trust%2fdefault.aspx";
      oSession.oResponse.headers.Add("Location", sNewLocation);
This approach ensures that the browser displays the correct URL and relative URLs on the page are pointing to the existing resources.



  1. “WingtipSTS” gave you away Claims Walkthrough: Creating Trusted Login Providers (SAML Sign-in) for SharePoint 2010 via 🙂

    Comment by m00ntear — November 6, 2013 @ 09:50

    • Yes, this proof of concept STS was created exactly based on that walkthrough. 🙂

      Comment by Peter Holpar — November 7, 2013 @ 23:26

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: