Developing virtualhost-aware PSGI applications: Plack::Middleware::MockProxyFrontend

Let’s say you work on a team that runs a web content management system for various different customers. It is hosted at, but each customer’s public content is published on a different domain, which is determined by a setting in the interface, which they can change at will. When a customer is logged into they see links to their public content in various places, and some of the public content has “edit this”-type links back into All of this runs as a single PSGI application. A not unfamiliar scenario, presumably.

How do you spin up a development server where you can test this?

MakeMaker among the stars

It is part of our solar system now.

Now that’s legacy.

Maybe the fault is, indeed, not in our stars.

Running plenv 𝘢𝘯𝘥 perlbrew

So I just went to investigate switching from perlbrew to plenv.

This has failed before, because I run an old and grungy installation of Perl where I didn’t set up a local lib and just installed whatever without keeping records of which installed modules I need and which are just junk I tried for a few minutes. Unless I carry forward all that junk, I can’t switch perls without breaking all my local scripts – and I have better things to do.

Eventually I want to fix this situation, but no today on which it comes up has been the day for it so far.

Still, I do want to upgrade to 5.22 now that it’s out, and I’ve been wanting to switch to plenv for a while. What to do?

Uhm… *looks around*
ln -s ~/perl5/perlbrew/perls/perl-5.16.1 .plenv/versions/5.16.1
La la la… *walks away*

Yup, plenv global 5.16.1 is fine with that and a plenv rehash later, it works.

I threw out the rest of perlbrew, just kept the directory tree for the linked perl installation, and now I happily run this bastard/cuckoo setup. Teehee.

Now for installing 5.22 and making all my stuff work with it…


I released Plack::Middleware::SignedCookies some time ago because I went looking for it and came up empty. This is a middleware that signs outgoing cookies on the server with a HMAC digest and verifies the digest on incoming cookies. If a cookie doesn’t pass the signature test, it is dropped on the floor and your application never gets to see it.

There are several framework-specific plugins that do the same job, but I wanted to get rid of as much framework-specific code as possible.

One explicit design choice was to not handle expiration. Several of the plugins I saw do handle that themselves, and it certainly is useful for centralising all cookie policy in one place. However, expiration is almost certainly something you’ll want to handle at the application level, if only to vary the “not authorised” message you show the user. So there has to be a protocol to signal that a cookie was present but rejected because it was expired, and the application needs code implementing that protocol in order to react to expirations. This couples the application to the cookie policy code. Now that is fine when that is part of the framework, or a framework-specific component; it is not fine in a framework-agnostic Plack middleware. Leaving the expiration policy to the application means the application only needs to deal with the cookie interface provided by its framework: it is not coupled to the middleware.

Another choice I made in the spirit of “maybe YAGNI” – but which is likely a limitation – is that as of 1.103, SignedCookies doesn’t provide a way to pick which cookies to sign/verify. In a pinch, you can always use a middleware wrapped around it (such as an inline Rewrite rule, for convenience) to intercept and/or inject non-signed cookies outside of its purview. There is a likelihood that this will change in the future.

Anyway, have at it. Share and enjoy.

QA Hackathon 2015 (Berlin)

I was at the QA Hackathon in Berlin this year.

Everyone else writing about it has an introductory section about what it is, so I needn’t concern myself with one… as well we’re on here after all.

In a stupid move, I forced myself to constantly look for some other hacker to mooch power from – I left my own power supply at home. Fortunately as a semi-reluctant initiate to the Apple cult, I found plenty who were of the same hardware persuasion, whom I could bum some laptop juice of life from. I hope to not repeat this part.

But the main reason that I chose to be present at all was for the consensus discussions scheduled this year.