If you haven't been following my trials and tribulations with this particular project, now might be a good time to go back and take a look at the first two installments of this series, just to get caught up on where things are at.

For those of you who have been following along and just don't remember exactly where we left things, I was just starting think things were looking pretty good when I ran into yet another little snag, this time with the authentication process.

The Weblog itself was actually looking pretty good, all things considered. But when I entered my authentication credentials, I found myself staring at the screen depicted in Figure A.

FIGURE A


The dreaded blank screen. Roll over picture for a larger image.

The authentication mechanism in Roller, as it was designed, posts to a Roller component which does a little pre-authentication processing, then forwards the request to the standard j_security_check servlet provided by the application server. This looked like a decent approach to me, so I figured that the URL (Uniform Resource Locator) must not be exactly right for the WebSphere environment.

I went out to the Roller CVS (Concurrent Versions System) repository, grabbed a copy of the source code and just started trying various things to see if I could find the magic pattern for the URL. Unfortunately, like so many other misguided excursions through the various trails down which I wandered during this process, this turned out to be a rather pointless exercise in futility.

The Real Problem
Once again, through pure dumb luck, I eventually stumbled across the real source of the failure. When the Roller authentication module executes the redirect to the server-provided j_security_check servlet, it not only builds the new URL to the servlet, it also ends up converting the request from a POST to a GET.

An unfortunate side effect of this procedure (aside from the fact that I couldn't get it to work) is that the password ends up getting exposed in the query string attached to the new URL, which is visibly displayed in the address field of the browser window. This seems to violate generally accepted security principles, which require that the password never be visible to anyone looking at the screen.

That's not the problem, however -- that was just an observation. The problem is, no matter how you structure the URL, the WebSphere j_security_check servlet simply will not respond to a GET request. Maybe that's by design or maybe it's a flaw in the container -- I don't know. What I do know is that this is the way it works.