I’ve been thinking about how best to create two sections of the PGXN Manager site, one that requires authentication and is on SSL and one that’s public. So far, I’ve just had all the authenticated stuff go to /auth (because I’m using basic auth), but what I want to do now is require authentication if the connection is via SSL. However, using a reverse proxy with mod_proxy to map to the PGXN Manger Plack app running on an internal port, I’ve found no environment variables passed through that would allow me, in code, to determine whether a request is via a proxied SSL or non-SSL connection. Most irritating.

So tell me what you think about the alternative plan I’ve come up with.

I’ll have two plack apps, one mapped to /auth and one mapped to /no-auth. The former will require authentication and the latter will not. They’ll have separate dispatch tables, of course. Then I’ll have the SSL site proxied to /auth and the non-SSL site proxied to /no-auth. Makes sense, right?

The only hangup I can see (though maybe you can see others?) is that my current method of generating URIs knows nothing about proxies. So If I link to /auth/account, when requests come through the proxy, it should actually create a link to /account. Does it make sense to use relative links instead of absolute links for all links to avoid this issue? I think it might be kind of annoying, because not all the code is aware of the current URI, though there are ways to deal with that.

Thoughts?

I guess I could stick with absolute URLs, and then have the uri_for use $req−>uri−>path for a proxied request and $req−>path_info for a non-proxied request.

Sure would be nice if there was some way to tell from the environment that a request was forwarded from an SSL connection, though. Alas, there are only three extra environment variable set by the proxy server:

• HTTP_X_FORWARDED_FOR
• HTTP_X_FORWARDED_HOST
• HTTP_X_FORWARDED_SERVER

No HTTP_X_FORWARDED_PORT or HTTP_X_FORWARDED_SSL or SSL_ENABLED or anything like that. Maybe I’m missing something in my reading of the mod_proxy documentation?

Last week I created the PGXN Manager interface for requesting a PGXN user account. It looks like this:

I really like the placeholder support in HTML 5, here nicely rendered by Safari. I’ve also used the jQuery Validation plugin to validate the form fields. So if you try to submit an incomplete form, it will complain before submitting, like so:

The back end does similar validation if you have JavaScript disabled, so it should degrade nicely. I think I might add a Twitter field so @pgxn can credit users for their uploads, but otherwise this is done.

As with PAUSE, an administrator must accept it or reject an account request. Once your account is approved (likely unless you’re a spammer), you’ll be able to upload distributions (I’m going to do that part today). I finished the user admin interface yesterday. Here’s a screen snap:

Some details. PGXN Manager will be hosted at http://manager.pgxn.org/. It uses basic auth for authentication; logged-in users will access https://manager.pgxn.org/auth. Administrators will have an extra menu item to this screen, which will allow them to accept or reject account requests. Its URI is /auth/admin/moderate. The admin can click the “Play” button to see the requestor’s note explaining why he should get an account. It’s a popover enabled by some jQuery code and looks like this:

Once an admin has read the request, she can accept it by clicking the blue checkmark icon, or reject it by clicking the red minus icon. The former links to /auth/admin/accept/{nickname} and the latter to /auth/admin/reject/{nickname}. The submits are done by jQuery async requests by default, but if you have JavaScript disabled they will submit as usual and the back end will process the request and simply redirect to the moderation screen.

This works very well, I think. It’s an attractive interface and degrades reasonably well. (Well, you can’t read the request details if you have JavaScript disabled, but the requests work nicely). The jQuery code fades out a row after it has been accepted or rejected, so it’s easy for an admin to do a bunch of moderation all at once. And finally, the interface is driven by the URLs, so I think it’s pretty restful. The only ones I’m not sure about are the accept/reject URLs, because they have action names in them (“accept” and “reject”). Is that RESTful? Or should they use GET query strings or something?

Okay, on to the upload interface. Wish me luck!