Can I just say that I hate configuring passthrough authentication to outsourced sites on remote web servers?

Rule 1: The company’s step-by-step setup instructions will not apply to your particular system configuration.
Rule 2: It never works the first time.
Rule 3: See rule 2.
Rule 4: Debugging is impossible, because the error logs are on the remote site.

It’s kind of like playing pin-the-tail-on-the-donkey: Put on blindfold, spin around a few times, try some stuff, and maybe you can get it to work. If not, call the rep. The rep is invariably non-technical and will have to pass the request on to a developer. The developer may or may not get back to you with useful info. Or maybe an error log. Or something. Then, you try again.

Oh, and I forgot….
Rule 5: Once you eventually do get it working, it will work for awhile, then break at the most inconvenient time possible, when the vendor decides to make some change to the remote site without telling anyone. Thus, it becomes a perpetual maintenance-hassle-waiting-to-happen that hangs over your head for, well, forever.

I just, finally, got the passthrough authentication to work with the National Student Clearinghouse. Basically, their stuff works like this: Post several magic variables to their web server. Server sends back a form that includes an encrypted token. Form uses javascript to auto-post itself back to NSC web server, which brings up the student’s clearinghouse view.

To make a long story short: It’s very picky about the HTTP_REFERER. We gave them the URL of our development server ahead of time. In the initial request, the referrer string that the script sends must begin with the URL we provided to them. Fine, I can use LWP::UserAgent to post the initial request, and set the referrer to whatever I want. I was still missing one piece though: In the second request (the auto-post form which is sent to the browser), the referrer must exactly match the referrer that I sent in the first request. Of course, NSC’s documentation conveniently doesn’t mention this.

Example: If I give them ‘http://devel.umbc.edu’ as the development URL, then my initial referrer must begin with that. I can send ‘http://devel.umbc.edu/cgi-bin/blah.pl’ and it will accept that. On the second request, I have to send it exact the same referrer string as I did in the first request, or it won’t accept it, even if it matches the development URL. Got that?

I probably made this harder on myself than it needed to be, by trying to get cute and fudge the referrer header from a URL other than the development URL I gave them. But it’s a bit annoying to have to jump through these hoops to make the thing happy about the referrer, given that it’s a really bad idea to rely on the referrer for any kind of security purposes in the first place.

Oh well, let’s hope I don’t have to do this again for awhile.