We Keep Coding

Express.js: send results after next() is called

I have an app that enables users to define their own routes on the fly. And I still want to display an custom 404 message, so in the last middleware I do this:
app.use((req, res, next) => {
// ...normal logic
// check for user defined routes
next()
// if res is not written, i.e. request not processed by user defined routes
if (!res.writableEnded) {
res.status(404).send(`not found!`)
}
})
However, I got
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
. How can I implement this?

There is no way for middleware to know if a subsequent route handler is going to pick up the path.
You need to define it last, really last, after any user defined routes.
Then you need to not call next().

pass state around between express middleware in an isomorphic react app

I have an isomorphic react app and I would like to somehow pass state between express middleware.
I have the following express route that handles form submission:
export const createPaymentHandler = async (req: Request, res: Response, next: NextFunction) => {
const { field } = req.body;
if (!paymentType) {
res.locals.syncErrors = { field: 'some error.' };
next();
return;
}
try {
const { redirectUrl } = await makeRequest<CreatePaymentRequest, CreatePaymentResponse>({
body: { paymentType },
method: HttpMethod.POST
});
res.redirect(redirectUrl);
} catch (err) {
error(err);
res.locals.serverError = true;
next();
}
};
The next middleware is handling the rendering.
At the moment I am using res.locals, is there a better way or a recognised pattern?

IMO your question is more about passing some data to the next middleware. Since the rendering logic is handled by the next middleware, the express route shouldn't be concerned by how the data is being used. Your approach looks fine.
res.locals is the recommended way of passing data to the next middleware. From the docs:
This property is useful for exposing request-level information such as the request path name, authenticated user, user settings, and so on.
Also, since the variables added will be scoped to the current request, thus the data will only be available for the current request's lifecycle. Perhaps you can set a convention of adding a state key on the res.locals to store all your state variables, but the current approach would also work fine.

res.locals is a standard way to pass data to the next middleware in the scope of the current request. Since your use case is around the current request, it makes sense to do so.
At the same time, the standard way to handle errors is to pass the error to the next middleware.
next(err);
Then you can handle the error scenario from the error handler. However, for an isomorphic react app, this would make things harder. So if you decide to go down that path, I would suggest you to use a custom error like PaymentError by extending Error. This would make even more sense since you are already using Typescript.
However, when you actually think about this scenario, when the error is not a request error, from the point of view of the react app, it is a special state/property of rendering. Thus I suggest the following hybrid approach.
If the error is of high priority, that is, if the error should stop rendering the expected content and fallback to a special page, use the next(err) approach.
If the error should just be part of the state report, then use the res.locals approach.

Because your handler is async, you need to pass the err into next, like so:
next(err);
In order for your middleware to process the error, instead of it being picked up by the default error handler, you need to have four parameters:
app.use((err, req, res, next) => {
// handle the error
})
It's also worth noting that error handlers need to be specified after other middleware. For your case, it might make sense to use a normal "success" middleware alongside an error handler, rather than combining the two into one middleware.
Finally, keep in mind that passing err as a parameter is specific to error handlers. If you just want to pass some data into your next middleware, you would do that by modifying the req:
req.x = 'some data'
next()
Then, the next middleware's req parameter will have the data you set.
Further reading: https://expressjs.com/en/guide/using-middleware.html#middleware.error-handling

If it's passing lightweight information to the next middleware for rendering purposes then applying res.locals is fine. However, you might want to look into custom error-handling for general errors, such as internal error.
Consider the following error handling
function notFoundHandler(req, res, next) {
res.status(404).render('notFoundPage', {
error: '404 - not found'
});
}
function badRequestHandler(err, req, res, next) {
res.status(400).render('badRequestPage', {
error: 'Bad request'
});
}
function errorHandler(err, req, res, next) {
res.status(err.status || 500).render('errorPage', {
error: 'Internal server error'
});
}
app.use(notFoundHandler);
app.use(badRequestHandler);
app.use(errorHandler);
Now instead of passing error details to the next middleware you would simple let it flow to the error handlers, e.g.
export const createPaymentHandler = async (req: Request, res: Response, next:
NextFunction) => {
const { field } = req.body;
if (!paymentType) {
res.status(400);
return next(); // This will hit the Bad Request handler
}
try {
const { redirectUrl } = await makeRequest < CreatePaymentRequest, CreatePaymentResponse > ({
body: { paymentType },
method: HttpMethod.POST
});
res.redirect(redirectUrl);
} catch (err) {
res.status(500);
return next(err); // This will hit the Error Handler
}
};

The best way to pass a state between express middleware is to use the object res.locals what you already do.
You are on the correct and best way!
May be you have to look to the documentation from res.locals one time again:
Citate from documentation of res.locals
res.locals – an object that contains response local variables scoped to the
request, and therefore available only to the view(s) rendered during
that request / response cycle (if any). Otherwise, this property is
identical to app.locals.
This property is useful for exposing request-level information such as
the request path name, authenticated user, user settings, and so on.
app.use(function(req, res, next)
{
res.locals.user = req.user;
res.locals.authenticated = ! req.user.anonymous;
next();
});
And you can see – they recommend to use this object.
You are on the right way!

Conflicts between endpoints in Node.js with express application

First of all, i have searched the solution to this problem and i didn't found anything. Sorry if it's duplicated.
I have in my express+node.js app two endpoints like this:
// Gets a tweet by unique id
app.get('/tweets:id', function(req, res, next) {
// Response management
});
// Gets mentions of user unique id
app.get('/tweets/mentions', function(req, res, next) {
// Response management
});
The problem is that requesting a GET petition to "/tweets/mentions", is attended first by "/tweets/:id" and later by "/tweets/mentions", making a conflict.
I have tried to change the declaration order of the endpoints, but always the request is attended by both endpoints.
Also I have tried things like "/tweets::mentions", but I need to access the endpoint via "/tweets/mentions", and I suppose there is a possible way.
How can i resolve this conflict?
Thanks.

Are you using next() in one of the handlers?
next() passes control to the next matching route, so in your example, if one of them is called and inside it you call next(), the other one will be called.
I allways recommend to use 'Router' if you have more than one base path because it helps you to keep it organized.

You can resolve the conflict by checking the value of req.params.id in the "tweet by id" handler.

For routes with additional parameters is always recommended to not use the same base path of other routes.
Something like could work for you:
app.get('/tweets/users/:id', function(req, res, next) {
// Response management
});
// Gets mentions of user unique id
app.get('/tweets/mentions', function(req, res, next) {
// Response management
});

Server authentication on page request in nodeJS, angularJS Application

I am using passport.js for authentication. My requirement is that, anyone should not be able to access a particular page (say, '/restricted'), if one is not logged in.
Right now, in my application, anyone can access "localhost:3000/#/restricted" url directly.
I am able to stop this and allow only logged in users to access the page by using Rorschach120's solution in
Redirect on all routes to login if not authenticated.
But this is done client side and is not that secure, because anyone can access this code from browser.
So I need that the request for my page goes to server, I tried moka's solution in How to know if user is logged in with passport.js?:
In app.js:
app.get('/restricted', loggedIn, function(req, res, next) {
// req.user - will exist
// load user orders and render them
});
where the loggedIn() function checks if user is logged in or not.
But this middleware is NEVER called and anyone can still access the "restricted" page.
What can I do, so that this gets called?
I am new to AngularJS and NodeJS. Am I doing something wrong here?
Any help will be appreciated.

You can use middleware for that purpose.
app.get('/secure-route', secureMiddleware, myMethod)
let secureMiddleware = function(req, res, next) {
authCheck(...)
.then(function(result) {
// pass
next()
})
.catch(function(err) {
res.status(401).json({
code: 401,
message: 'restricted route'
})
})
}

PassportJS - Dynamically set state to allow redirect on callback

So I'm working off the information that was given here to add the ability that Google will redirect to the page a user was at before it redirected to google. I'm currently using the latest versions of Express, PassportJS, and Google oauth2.
For example, if a user hits page http://example.com/privatecontent, it'll automaticially redirect to Google asking to sign in, and after it's sucessful it returns to my Node App, except it doesn't know the last page was /privatecontent and instead redirects to the index.
If I understand right, I can use the state parameter to let Google know to send the state param back so I can read it and redirect myself.
I essentially would like my function to look a little something like this, but I don't have access to req.headers, or just don't know how honestly within passport.authenticate.
app.get("/auth/google", passport.authenticate("google", {
scope: ["https://www.googleapis.com/auth/userinfo.profile", "https://www.googleapis.com/auth/userinfo.email"],
state: base64url(JSON.stringify({
lastUrl: req.headers['referer']
}))
}), function(req, res) {});

Make a custom middleware
function myCustomGoogleAuthenticator(req, res, next){
passport.authenticate({
scope: ...
state: // now you have `req`
})(req, res, next);
//^ call the middleware returned by passport.authenticate
}
Add that to your route instead
app.get("/auth/google", myCustomGoogleAuthenticator, function(req, res) {});