OK so we've got two Halloween parties to go to tonight, and I'm only wearing one costume. The roller girls will understand my costume without explanation, but I'm afraid it will likely leave many or all of you scratching your heads. I can hear it now: 'I understand you're a roller girl, but what's with the potato masher?' I will not answer your question. I will refer you to this blog.

The QCRG All-Stars* played against the Steel Town [Hamilton, ON] Tank Girls this past summer in a game where the officiating was bad and the sportsmanship was worse. Derby is a rough sport, but this rapidly became unsettling on an almost visceral level. Anyway, the costume is a Tank Girls' uniform.

That does not explain the potato masher. There is a Tank Girl whose name is Cheese Grater. She carries around a cheese grater. I'm not sure whether the name or the kitchen implement came first, but I'm pretty sure I don't want to ask. It's pretty random, but it's not any less random than, say, a potato masher. And I guess cheese is relatively badass as far as dairy products go, but consider this: if someone chucked a piece of cheese at you, you'd be angry but mostly confused. But if someone chucked a potato at you, you'd be IN PAIN!!!!!

- Z

_______________

• ie, anyone who wasn't busy that weekend

"Winter in Blogville" by Jennifer ("14221") Wutz-Lopes (Buffalo Spree, Nov 2007, p26)

Someone ( everyone!) over at Estrip.org has their panties in a bunch about something to do with the fact that they are not taken seriously as bloggers. Take a number and get in line, I say.

But estrip is by far the most colorful screenshot in the bunch.

- Z

Because I know everyone's been holding their breath for this, here's the HTTP auth Javascript server-side script and database layout

Notes:
- does not require any hooks in your HTML code; just make sure your form has fields named 'username' and 'password' and import the Javascript
- can be attached to any form with an access-restricted target; script will pre-authenticate and, if successful, send the rest of the form as usual.
- You're not going to be able to use the server script as-is because it's kind of dependent on other parts of the project. You're not going to be able to read the server script as-is because it's Python. [Also in the full version you can change your authentication realm, and users in the special '_administrator' realm can log in to anyone's site.]
- no backwards Internet Explorer compatibility code in the Javascript
- on successful authentication, 'validate' returns 204 No Content. on unsuccessful authentication, server returns 400 Bad Request.

- Z

You know, I just can't fucking leave well enough alone. This morning (e:paul) mailed me a short Surebert script to do logins, which works, yet I'm still hacking this HTTP auth problem. Stay The Course, right?

But I got it solved. 1: Never send 401 Unauthorized without a WWW-Authenticate header. It's not allowed, and you'll get what you deserve. RFC 2617 briefly mentions using 400 Bad Request to report miscellaneous failures to the browser, and sure enough, that resets Safari. 2: If the script detects a failure, send another request to the same URL using a bogus username. This will of course fail, resetting Firefox in the process [thanks (e:kookcity2000)]. I think that's a gruesome hack, but if it works it works.

Why do I care about HTTP authentication? Most importantly, I want to support authenticated, noninteractive web services [specifically an authenticated RSS feed]. Since this code will have to live in my server somewhere, I might as well get some mileage out of it. HTTP Digest is often overlooked but it's a nice middle ground between static hashes [which are plaintext-equivalent] and full-blown encryption [CPU load].

Source code available upon request.

- Z

Don't bother reading unless you give at least a quarter of a shit about XMLHttpRequest and HTTP authentication.

Here's a stupid geek trick. The correct login information for this is user="user", password="password". Give it the wrong password [it will say something like 401 Unauthorized, user="user", password="bogus"]. Then give it the right password and try again - it will keep sending the wrong password. This happens in both Firefox and IE; Safari has a slightly different bug.

Here's the sitch: I have an XMLHttpRequest going out to a password-protected resource. The credentials are supplied by the user and thus they are likely to be wrong some of the time. The script is designed to gracefully handle authentication failure - specifically, I want to avoid the crappy infinite HTTP authentication dialog box loop. I'd think that this issue would come up from time to time, but I guess it doesn't because this is really hairy:

XMLHttpRequest states "If authentication fails, user agents SHOULD prompt the users for credentials."

To work around this, Paul James suggests returning 401 Unauthorized without the mandatory WWW-Authenticate header. In theory, this tells the browser to stop trying and forget the password. The browser does, in fact, stop trying, but it also goes into a weird undefined state where it continues to issue the old [incorrect] password despite instruction to the contrary. [Safari instead puts up the dialog on the next request, even if credentials are provided.]

HTTP/1.1 states "If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information." - ie, reissue the same challenge to indicate to the browser that it should give up. As near as I can tell, not a single browser has ever done that.

HTTP/1.1 also gives us 403 Forbidden: "Authorization will not help and the request SHOULD NOT be repeated." This response has the same bizarre effects as 401 without WWW-Authenticate.

I'm actually kind of an AJAX newb, so ... does anyone have any recommendations?

- Z