How Can I Detect a Proxied SSL Request?

2026-10-07T16:13:48Z

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?

Mail List, SSL

2026-10-07T16:13:48Z

I’m this close to having PGXN Manager ready for a limited beta. I’ve got it running on Kineticode’s server, and have been tweaking things here and there, fixing some bugs and filling in a few missing bits. In the next couple of days I’ll get some more kinks worked out and then start inviting folks in. If you’re interested – especially if you have an extension you’d like to release, leave a comment here to let me know.

Better yet, sign up for our new mail list. I’ve set this up so that PGXN users can have a place to meet and discuss things (naturally). I expect discussion will be about how to create proper distribution archives (hint: it’s all about the META.json file); issues with PGXN Manager or the network itself, and directions for ongoing development.

Oh, one thing I wanted to run by you here: I currently have two sections in PGXN Manager: public and users only. Right now the only difference is that all the users-only stuff is under the /auth/ URI, which is itself limited by a basic auth challenge. I find this setup a bit hinky, though, because the link to /about, for example, appears in the nav menu for both sections, and if you’re logged in and click it, it will look like you’re logged out.

So I was thinking perhaps that I’d change it so that the difference is that user-only is on port 443 (SSL) and public on port 80. That way I could have links to about on both and one wouldn’t appear to be logged out by clicking it from the SSL site. Because, you know, they’re effectively two different sites.

Thoughts? Is using the SSL divide perhaps the most natural way to separate user-only access from public access?

More soon.