What to replace FastCGI with in `rack` ≥3?

[doriantaylor]

Hi there, been working on a thing that uses rack and just went to deploy it and discovered that there is no longer any FastCGI support (anywhere, even in third-party modules, apparently). I went back and dug Rack::Handler::FastCGI out of Rack 2 and renamed itRackup and beat on it until it worked (although it appears to time out or something if I leave alone too long).

I guess the question I'm really asking is what do I replace FastCGI with? The reason why I planned to use it for the moment over vanilla HTTP is because it exposes the internal state of the request (particularly REMOTE_USER), and I'm trying to put this thing online behind an auth wall managed by another server (Apache, for Reasons™). I would luh-ooove to just run it on Puma and reverse-proxy it and call it a day, but can't for the time being.

Insights?

[ioquatix]

I'd be fine to merge fastcgi support back into Rackup, or an optional gem rackup-fastcgi etc. Happy to explore ideas here. The main issue was having fcgi as a direct dependency of rack.

[doriantaylor]

Hmm, I think if anything I'd do a standalone handler like rackup-fastcgi or rackup-handler-fastcgi (because of it being a dependency there too).

Now that I'm thinking about it more, though, there are only two reasons why I would elect to use FastCGI over a vanilla reverse proxy:

1. The fact that being CGI it has a view of the inside of the request (e.g. fields like REMOTE_USER),
2. To actually take advantage of FastCGI's weird filter and/or authorizer modes*.

* I actually do, elsewhere, with forget-passwords (demo), which, come to think of it, is stuck on Rack 2 because of this.

My other project, Intertwingler, has a "transform" infrastructure that "reverse proxies" subrequests (with the eventual intent of affording stand-alone microservices written in other languages) to manipulate response (and request!) bodies, à la o-g Apache 2 filters, but took the inspiration from FastCGI's filters, just over ordinary HTTP.

So now I'm thinking if I wanted a "thick" reverse proxy doing authentication that would forward the fact that a particular user was authenticated over vanilla HTTP to an application server/microservice/whatever, how would I go about doing that?

I'm thinking JWT? I don't really know how else you would do it. So the origin server has code in it to interpret an assertion via JWT from the reverse proxy that the request came from a particular user, but in a way that can't be faked.

I don't know; is that how the kids do it these days?

[ioquatix]

IIUC, I think I'd encourage you to ensure that Rack applications are self-contained. Applications that have fractured boundaries are liable to security issues as you allude to.