[Tallahassee-pm] An interesting problem.

[Phillip Tyre]

I ran into an intersting problem today, and I thought I might share my solution, as well as ask how some of you might have solved it differently.

The problem relates to two servers, let's call them Php_server and Asp_server. 

Php_server is a linux system that external internet users log into, and authenticate against a MySQL database. Php_server is protected behind SSL/firewall/etc, and generally has some nifty things that authenticated users can do on it.

Asp_server is a server at a seperate physical location/ seperate domain name,  that runs IIS, and provides a resource out to various users. We only want a new set of resource(pages) on the Asp_server to be viewable in this case to users that have authenticated against the Php_server. 

At the same time, we don't want users linking from the Php_server to the Asp_server to have to authenticate a 2nd time. One of the initial thoughts was to use http_referer on the Asp_server to check and see if the refering page was on Php_server, but IE doesn't send http_referer to a site if moving from https to http.

The solution we came up with is a token based solution, and it goes something like this:

On the Php_server when the user has authenticated, and visits the section of the webpage where the link to the Asp_server is, the page that displays the link performs the following actions:
	get the current date and time in YYYYMMDDHH format.
	Append a secret string to the YYYYMMDDHH string.
	So now we might have 2003070715secretstring for the string.
	MD5 this string to create a hash.
	When the url for the link to Asp_server is displayed, make it be http://www.asp_server.com?token={md5hash}

With all of this done, we now have a link, who's value changes in a VERY unpredictable way, every hour.

But that is only half the battle.

On Asp_server we need to first off check and see if Request.QueryString("token") is set, if it is, then we can decide that we might want to try and authenticate the user.

So the goal initally was to have Asp_server do the following:
	Get the current date in YYYYMMDDHH format, appending the secret string to this value (2003070715secretstring)
	Create a 2nd string equal to the date/hour ONE hour ago, (2003070714secretstring)
	Create a 3rd string equal to date/hour one HOUR from now, (2003070716secretstring)

	Calculate a MD5 hash of each of the 3 values, then compare them to the value of Request.QueryString("token") and see if any matches.
	If any of the values match, then go ahead and authenticate the user.

We could never be sure the times were exactly right between the two servers, so a 3 hour window on Asp_server would allow for flexibility.

The one big snare that I ran into, and I found this hard to believe, was that ASP doesn't seem to have a native MD5 function.

http://users.bigpond.net.au/mrjolly/software_page.html and the ASPMD5 1.0.1 is the class that I ended up using. And it seems to be working corretly, (all the values I've tried compute to the same hash as the internal PHP MD5 function, so unless they coded in a typo on one of the transforms, it should be good to go.


I'm sure I must have seen a solution like this before, because I came up with the actual code very quickly, and had it up and running on both servers in about 2 hours from start to finish (and yes I even documented), but for the life of me, I can't recall where I've seen this done before.