Getting ERR_HTTP_HEADERS_SENT when trying to use requiresAuth with express.static

I believe I’ve narrowed it down it down to just this in my testing:

app.use('/app', [requiresAuth(), express.static(path.join(__dirname, 'app'))]);

This is my attempt at serving a single-page-app from a protected route. This will work AFTER the user is logged in (resulting in GET /app/ 304 , but on initial login, and on refreshing the page with cookies cleared (CMD-SHIFT-R on a Mac in Chrome, for instance) you’ll get GET /app/ 500 4.563 ms - 1254 Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client.

Is there another way to serve static files on a protected route?

2 Likes

It’s not express.static… I get the same results with this, actually: router.get('/app/*', requiresAuth(), (req, res, next) => { if (req && req.oidc && req.oidc.isAuthenticated()) { res.sendFile(path.join(__dirname, '../app/index.html')); } else { res.redirect('/login'); } });

It seems that requiresAuth itself is triggering the error.

1 Like

I have confirmed that res.sendFile in any route (protected or not) in the present of express-openid-connect will cause the ERR_HTTP_HEADERS_SENT error. Downloading the sample project from the documentation and attempting to add either a static middleware along with requiresAuth() or using res.sendFile in ANY route (with or without requiresAuth) will result in the error.

:man_facepalming:

I lost two days to this. I have been spelunking into node_modules, running in debug mode, etc…

If you’re serving it locally, the hop from HTTP to HTTPS seems to be the cause of this error (the auth header is getting messed up somehow, though it appears to be in place…). Running it in an totally HTTPS environment, it works just fine. The documentation does have an off-hand remark about “you MIGHT run into errors if you’re working locally on an HTTP connection,” but that sounded so non-threatening that I didn’t even notice it.

I have same problem . It’s happend when “express-openid-connect” come to version 2.3.0 . Come back to the old version (2.2.0) for this issue

I could have sworn that the issue had gone away when I deployed to my HTTPS server, but I’m seeing it in logs again. It looks like it has to do with the route being responded to by EJS as well as a route that I wrote, based on the error stack. Will try disabling EJS.