Hacker News Reader

Hacker News

Comment by tetrep | Hacker News Reader

Parent Full thread

tetrep

>Perhaps nginx might instead check all requests for a particular signed cookie...

That's called session handling, which is something you want to implement in your web application, not your web server.

http://en.wikipedia.org/wiki/HTTP#HTTP_session_state

http://en.wikipedia.org/wiki/Stateless_protocol

View on HN

Unless you want to use Nginx as an SSL-offloading proxy for a bunch of internal apps that you want to protect from the public but your apps themselves don't use the session in any way? Yes, we can use Lua and effectively write our own, but one of the reasons I've considered Apache again is that there's now a plugin for OAuth 2 + OpenID Connect ;-) https://github.com/pingidentity/mod_auth_openidc

That said, even before this, Apache supported a million different mod_auth_* at http://httpd.apache.org/docs/2.4/mod/ including authentication caching http://httpd.apache.org/docs/2.4/mod/mod_authn_socache.html for modules that don't supply their own cache.

Put Nginx in front of Apache then? Or set up an authentication service and use it from your internal apps?

You'll lose some of the benefits of Nginx at that point, since part of why people like Nginx is how it handles connections, proxying and caching. And the internal apps aren't always mine to maintain, e.g. Apple's Xcode server.

But yeah, there are options in Apache-land, my post was more that nginx could eventually gain those options too :)

In some cases it would be useful to perform session handling like this in nginx. I like the idea of building a reverse proxy which handles authentication and sessions, in front of a backend web page which wasn't designed to handle it. Something like giving access to an old internal intranet without having to change the app.

this reminds me of a government agency that permits access by IP addresses whitelisted in IIS. Can't put fancy caching or load balancing in front because it can't understand X-Forwarded-For, etc.

tl;dr build your authentication into your app, not the web server layer.

There are plenty of upsides to decoupling authentication from your app codebases. For instance, in an enterprise where you have a single sign-on solution implemented as a web server module and a mix of third party and bespoke web apps.

I think no one argues that decoupling isn't the way, in fact that's exactly what others are saying too, but in the proper way. Make an authentication (micro)service and call it from your webapp. Proxy should proxy, auth service should manage (and cache, keep up to date) credentials, role associations and group memberships, web app should serve web pages (based on the business logic coded into it).

Reply on news.ycombinator.com