Why Publ won’t support magic auth links

Since adding user authentication to Publ, I’ve been thinking of ways of allowing people to subscribe to sites from feed readers while getting their own native authorization, so that people can see entries directly in their readers rather than needing the clumsy mechanisms of unauthorized placeholder entries.

Out of the box, Publ authentication does support a shared cookie jar; if you can provide your cookies to your feed reader in some way, then things will Just Work. Unfortunately, I don’t know of any feed readers that actually support this, at least not easily. (Back when most browsers had a feed reader built-in this was a lot simpler. But time marches on.)

The two mechanisms which seemed most promising are AutoAuth and “magic links,” where users get signed URLs that come pre-authenticated and show the full authorized content for that user. AutoAuth is still in a draft phase that’s stuck in a chicken-and-egg situation (and also requires a lot of buy-in to IndieWeb protocols, which is still a pill too large to swallow for most of the folks who follow my blog), so magic feed links seemed like the best path forward.

I even got so far as to draft out an implementation, but there’s a few bad issues with it which just made me opt not to.

An early-alpha Movable Type importer

For those folks who want to import their content from Movable Type over to Publ, I’ve finally gotten around to writing an importer. Currently it only attempts to convert entry content and category metadata, and only using SQLite-formatted database dumps.

See its README.md for the (incredibly rough) usage instructions.

Eventually I want to try to automatically convert templates from MT’s scripting language to Jinja-Publ templates, although there’s a bunch of stuff that’s going to be difficult to port across and a lot of stuff is just plain not feasible to even try, so don’t expect that to become a major thing any time soon.

Pushl v0.1.3, and a FeedOnFeeds update!

I just released Pushl v0.1.3, which adds some minor performance optimizations and a bug fix.

Originally I was hoping to have a major performance optimization, in the form of having rewritten Pushl from thread-per-connection to async operation, but unfortunately I ran into a bunch of problems with it. Mostly that I was running into a “too many open files” error and I couldn’t figure out what was causing a descriptor leak. I have the work-in-progress branch online if anyone wants to take a look at it.

Anyway, the reason I went down this route is because I added WebSub subscriber support to my fork of Feed-On-Feeds, which makes it so that WebSub-enabled RSS and Atom feeds will push their updates to your reader instead of having to wait for a polling interval.

You can read more about some of my other thoughts on a blog entry that quickly devolves into a rant, if you’re so inclined.

So much for Dreamhost

One of the overarching reasons I decided to build Publ the way I did was in order to take advantage of Dreamhost’s support for Passenger WSGI. I was expecting that to be the primary means of hosting my main site (which is way too big for a Heroku instance) and given how smoothly things were working with this site on Dreamhost I figured it wouldn’t be a big deal.

However, there was a huge monkey wrench thrown into things when I switched my site’s configuration over to Passenger; despite all of my configuration being exactly the same between publ.beesbuzz.biz and beesbuzz.biz, the rendition cache on beesbuzz.biz was getting its permissions set wrong, and there was some rather weird behavior with how it was making the temporary files to begin with.

In investigating this I attempted to upgrade my packages on publ.beesbuzz.biz, and all h*ck broke loose.

Dates are hard

There’s an old joke in programming, that the two hardest things to do are naming things, cache invalidation, and off-by-one errors. But this doesn’t pay sufficient respect to one of the other hardest things, namely handling date and time.

The Trouble with PHP

I’ve had people ask me why I’m not building Publ using PHP. While much has been written on this subject from a standpoint of what’s wrong with the language (and with which I agree quite a lot!), that isn’t, to me, the core of the problem with PHP on the web.

So, I want to talk a bit about some of the more fundamental issues with PHP, which actually goes back well before PHP even existed and is intractibly linked with the way PHP applications themselves are installed and run.

(I will be glossing over a lot of details here.)