Design proposal: External Authentication in Manila

Here is a short proposal for a Manila modification that allows authentication against either the local database or a single remote system.

1. On any page where a user is asked to create a new password (“New Site”, “Sign Up”), we instruct users that have an address ending in to leave the password fields blank. Users with emails in other domains should enter passwords as usual. We modify the input validation accordingly. With the exception of the blank passwords, user records are created in the object database at the same time and in the same way for all users.

2. On any page that validates a user’s password (“Login”), we check for an extension. If we find one, we validate against the school’s authenticator. If we find some other extension, we check the password in the usual way.

3. Upon successful authentication of an external user, we issue a dummy “native” password as David Carter-Tod describes at, so that mainResponder to use cookies in its usual way.


  • Local and externally authenticated users can be distinguished by looking at their email domains. Hence should be authenticated against the school’s authenticator and should be authenticated against the local database.
  • An externally authenticated user’s username is equal to the first part of their email address. So should be authenticated against the external system with username “student”.
  • We will not do anything fancy to synchronize profile information, such as the user’s name and address, against a central system. This information must be entered and managed in Manila for all users.


  • No new pages or changes to screen flow.
  • Small changes to existing pages.
  • (I think) No changes to Manila core.


  • How do we arrange things so that our modifications to member.login() appear in each new site when it is created?
  • What other pages will be affected by our change? E.g. “email my password”.

I see that two popular techie bloggers, Aaron and Mark, are letting us see the edits they’ve made to their posts.

Reading a few edit trails, it’s fascinating to see what they capture. Accountability and archivalness aside, I think edit trails could serve as a great tool for writing instruction. Most of us don’t get it right the first time. The magic is in the editing. Capturing and studying the edits of a great writer could teach us a lot.

An Even Non-Funkier RSS 2 Template

I gave Brad’s Non-Funky MT RSS 2 Template a try but it was still too funky for my aggregator, which choked on the resulting feed.

So here it is folks, an even non-funkier template.

Note that it requires Brad’s very excellent MTIfEmpty plugin.

Update 2003-09-12 We’ve incorporated a timezone fix as described by Diego. This uses an RFC-822 timezone plugin from John Gruber

I’ve overhauled my RSS feed and autodiscovery info. I’ve also, I hope, fixed the feed so that items without titles will load correctly into Radio. Finally, I’ve changed the permalink structure so that the date appears in it. I may yet still tweak the permalinks so that all posts from a given day appear on a single page. One step at a time.

More on deletionless aggregator reading

The deletionless reading adventure continues. I’m using the Radio timestamps to see where I left off. I scan down the page until I hit a familiar timestamp. It’s working well.

This strategy doesn’t work as well when you’re adding subscriptions, since you get a big chunk of new stories from each source, potentially spanning days or months. That tends to break up the flow.

Aggregators, or how I gave up deletion and learned to love the scroll wheel

Wired writes about aggregators today. Dave comments.

Yeah, it’s a little bizarre that they didn’t mention Radio in their list of aggregators. I think Radio is one of the better ones and relatively uncluttered by complex, unnecessary features.

Speaking of which, I wonder if Radio really needs the delete item feature. A few days ago I hacked up Radio to make this feature more usable. When I proudly described my accomplishment to Dave, he said “oh, I don’t even use that feature, I just let the old posts slip off the end of the page.”

Huh. In theory deleting should help one keep track of what they’ve read and haven’t read. But we do that perfectly well with newspapers, which have a much more complicated layout. I think I was using “delete item” simply because it was there. The new experiment: no deleting.

Hail the unscalable aggregator

Something Sam Ruby wrote today gives me an opportunity to attempt a related point I’ve been meaning to make. Sam wrote:

If you are an online user of a single page aggregator, then what generally best suits you is a a short lead in with a link to the rest of the story should you be intrigued enough to follow it.

For me it’s just the opposite, actually. I like everything on one page: the less clicking I have to do, the better. The “everything on one page” style lets me quickly scan a post and decide whether to read it closely before deleting. Excepting mainstream media feeds, lead-ins usually don’t give me enough information to decide, and I wind up having to click anyway.

The likely objection here is that one’s aggregator page can get long. Hence we have the three-pane aggregators. These are supposed to help us manage large amounts of data by providing segregated views and a folder system. But in my hands, at least, this “scalability” encouraged bad habits. I wound up with thousands of undeleted messages in my various SharpReader folders. It was the worst aspects of email, all over again.

Try an aggregator that doesn’t scale. Like this one or this one. It will force you to work through the posts, and help you do it quickly. Don’t worry about stuff that you didn’t have time to read. Just delete it. Remember, it’s not email. The data will (probably) remain out there on the Web where you can get to it later if you really need to.