exception Handling In Express JS - node.js

I am developing a rest api using express JS . I want to show several error such as route not found, data not found, validation error. I am using async await structure . I need to know how to manage several exception handling in Express JS . I search seveal website but not found exact way . Everywhere write to use nodeJS default exception . But i need it customize in REST API.
I need expert nodejs developer help . If anyone know best resource of express error handling please provide me link to learn this

1.Let for handling route not found error you can use the default route
app.all('/*', (req, res)=> res.status(404).send('Route Not Found'))
2.For handling response, you can set some predefined response in separate module and send all response from that module. Like
//response.js file
module.exports= {
ok : (res, data)=> res.status(200).send({data}),
error: (res, err)=> res.status(err.status).send({error})
}
3.For handling error you can make seperate error file where all error a set and create your error by those listed error. And you can do by try, catch
4.For validation, you can use middleware and or helper for handling validation.
5.Following are some node.js configuration link created by me, you can take reference from there
https://github.com/bapinmalakar/election-exitpoll-back (very simple, Github)
https://github.com/bapinmalakar/pt-backend (little complex, github)

You can log the error using middleware As below given example middleware we can catch the errors which are thrown across the application. Also, we can catch the promise rejections
const express = require("express");
const app = express();
app.use((err, req, res, next) => {
if (err) {
res.status(err.statusCode || 500).send(err);
console.error(err.stack);
next();
}
console.error(`Message :: ${err.message}
Url :: ${req.originalUrl}
Method :: ${req.method}
Ip :: ${req.ip}
Time :: ${(new Date()).toLocaleTimeString()}`);
});
For reference use this link. Click here

Related

How do I prevent node from logging an exception to the console in my NextJS/Express app?

I have an Express application that runs a blog in a NextJS app, very similar to the example in their repo
I have set it up so that my app runs a query to fetch a blog article, and if the result is empty it throws a NotFoundException.
I catch this exception in my NextJS _error.js file, which is similar to a React error boundary, where I route the user to my 404 page. This part works fine.
The problem I'm having is that this exception is logged to the node console even though I'm not logging it when catching the exception. This pollutes our company's logging software with all our 404's
Is there some node/express setting I'm missing here that prevents the logging of exceptions? Here's my Express process error handler:
process.on('unhandledRejection', (reason, promise) =>
console.error(`Unhandled Rejection at: ${promise}.\nreason: ${reason.stack || reason}`));
I know there is a log there, but the format of the one I want to eliminate is different to this, so I'm confident this is not the source.
I won't pretend to know what's going on, but my best guess is that next.js is logging the error somewhere. I did some digging and it appears there's an error logger in the server code that will log on errors unless a quiet property is set on the server:
https://github.com/zeit/next.js/blob/canary/packages/next-server/server/next-server.ts#L105:
return this.run(req, res, parsedUrl)
.catch((err) => {
this.logError(err)
res.statusCode = 500
res.end('Internal Server Error')
})
Here's the sig and body for the logError function:
private logError(...args: any): void {
if (this.quiet) return
// tslint:disable-next-line
console.error(...args)
}
If you look at the documentation for using the next API with a custom server, it notes the following options object properties that can be passed to the constructor:
The next API is as follows:
next(opts: object)
Supported options:
dev (bool) whether to launch Next.js in dev mode - default false
dir (string) where the Next project is located - default '.'
quiet (bool) Hide error messages containing server information - default false
conf (object) the same object you would use in next.config.js - default {}
When constructing the next object, try passing quiet as true to see if it resolves your issue:
const express = require('express')
const next = require('next')
const port = parseInt(process.env.PORT, 10) || 3000
const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev, quiet: true })
const handle = app.getRequestHandler()
The docs also mentions errors are logged in non-production environments (identified when process.env.NODE_ENV !== 'production'), so I would also check to ensure you're setting NODE_ENV to 'production' when starting your application:
NODE_ENV=production node server.js
I hope this helps!
In express you can setup an ErrorMiddleware.
After all your routes declaration, put
server.use(function(req, res, next) {
handler(req, res).catch(e => {
// use rejected promise to forward error to next express middleware
next(e)
})
});
Like this, when you reject a Promise, next(e) will send your error to next middleware. I usually setup a middleware where i send error, and then i manage all errors in one single function (based on statusCode error,...).

Node.js REST API - URI Sanitizing?

I would like to require pages in my Node.js server based on the requested URI.
However I concern that this could be a severe security issue since user can inject some malicous chars into the url, something like ../../ and reach to my root server point and reveal all of the code.
So just like throwing a bottle of water to a big fire, I have eliminated the option to send . to the request.
This is not a silverbullet, probably :)
Maybe is there some standard/best practice/guide or keypoints about URI sanitizing in REST API based on Node.js?
Edit - here the code uses the require
// app.js
app.use(require('./services/router')(app));
// router.js middleware
function router(app) {
return function(req, res, next) {
try {
// checking for . in the url
if (req.url.indexOf(".")!=-1) cast.badRequest();
// req.url.split('/')[2] should be customers, users or anything else
require('../../resources/' + req.url.split('/')[2] + '/' + req.url.split('/')[2] + '-router')(app);
next();
} catch(err) { cast.notFound(); }
}
}
module.exports = router;
// rides-router.js (this could be users-router.js or customers-router.js)
module.exports = function(app) {
// GET ride - select a ride
app.get("/v1/rides/:id", dep.verifyToken(), require('./api/v1-get-ride'));
// POST ride - insert a new ride
app.post("/v1/rides", dep.verifyToken(), require('./api/v1-set-ride'));
app.use((req, res, next) => {
cast.notFound();
});
}
You asked how to do it safer. My recommendation is that you put all the resources in an array and run all the app.use() statements with one loop that pulls the resource names from the array at server startup.
I don't like running synchronous require() during a request and I don't like loading code based on user specified characters. Both are avoided with my recommendation.
// add routes for all resources
const resourceList = ['rides', 'products', ...];
for (let r of resourceList) {
app.use(`/${r}`, require(`./resources/${r}/${r}-router`));
}
This seems like less code and 100% safe and no running of synchronous require() during a request.
Advantages:
Fully whitelisted.
No user input involved in selecting code to run.
No synchronous require() during request processing.
All routes installed at server initialization time.
Any errors in route loading (like a missing route file) occur at server startup, not during a user request.

Node.js REST API versioning the right way?

I would like to manage my REST API based on URL version specifying.
For example:
api.mydomain.com/v1/rides/
// will return all rides based on v1.
api.mydomain.com/v2/rides/
// will return all rides based on v2 (probably with some braking changes).
api.mydomain.com/rides/
// will return all rides based on v2, since v2 is the newest.
Thats awesome.
Before we get started dealing with the practical way of handling this,
we should talk about the logical "default newest versioning" - I mean, if user does not going to specify any kind of version, should I serve him with the newest version or throw a 404 not found error?
Should I oblige the user for specifying an API version?
If I do, is there any standard of "parsing" the specific / newest version?
I tell you why im concern about this: Lets say that "Dan" have app installed which relays on the newest API endpoint (V1 for example), then I release V2 which has braking changes.
Since Dans "listens" to the newest version by default, Dans app is going to be crashed.
That is not a good behaviour at all.
Maybe should I prevent using the "default newest versioning"?
Maybe should I use Dans app to listen for a specific version, while remote developers accessing my API as a web service can have the privilege to choose between specific version or the newest by default?
Is there any standard?
**
Now lets talk practically. Lets say that I have a router handling those requests, maybe something like this:
// app.js file
app.use((req, res, next) => {
try {
require('../resources/' + req.url.split('/')[1] + '/' + req.url.split('/')[1] + '-router')(app);
next();
} catch(err) {
dep.cast(res, 404, new Error("Not Found"));
}
});
And some handler, like this:
// resources/rides/rides-router.js file
module.exports = function(app) {
// GET ride - select a ride
app.get("/v1/rides/:id", dep.verifyToken(), require('./api/v1/get-ride'));
app.get("/v2/rides/:id", dep.verifyToken(), require('./api/v2/get-ride'));
// POST ride - insert a new ride
app.post("/v1/rides", dep.verifyToken(), require('./api/v1/set-ride'));
}
As you can see, I have handler which sends the requests to the specific divisions in the API, split by V1, V2, etc..
It makes me wonder if its right to have the same page containing the same function over and over in different folders, one for V1 and one for V2.
Ofcourse, with some braking changes, but they are probably going to be similar. Is not it bordering with repetitive code?
Look at the project structure:
What do you think about this?
Instead of adding version in every route you can add it in app level. So It won't be tightly coupled with API route.
import * as express from 'express';
// v1/get-ride.js
const router = express.Router();
router.post('/rides/:id', dep.verifyToken(), (req, res) => {
// Your code
});
app.use('/v1', router);
// v2/get-ride.js
const router = express.Router();
router.post('/rides/:id', dep.verifyToken(), (req, res) => {
// Your code
});
app.use('/v2', router);
I would recommend using node-express-versioning module instead.
It would help you to support multiple versions without changing the url of API, just send the version of API and direct the call to that version route-controller.
*
*//version taken out from header
app.use(function(req, res, next)
{
req.version = req.headers['accept-version'];
console.log(req.version);
next();
});
//version path defined
app.use('/api', versionRoutes({
"1.0.0": respondV1,
"2.0.0": respondV2
}));
function respondV1(req, res, next)
{
app.use('/api',routeV1);
next();
}
function respondV2(req, res, next)
{
app.use('/api',routeV2);
next();
}*
*
There's no "right way" to do API versioning.
However, URI based global versioning is not at all RESTful.
Phil Sturgeon of "APIs you won't hate" recommends an API Evolution approach instead.
See: https://apisyouwonthate.com/blog/api-evolution-for-rest-http-apis
Have you considered this as an option?

How Express recorgonizes middlewares?

I'm novice in Express and a little bit confused about how it handles middlewares? So basically I have two middlewares which looks like:
app.use(require('_/app/middlewares/errors/404'))
app.use(require('_/app/middlewares/errors/500'))
404
var log = require('_/log')
module.exports = function (req, res, next) {
log.warn('page not found', req.url)
res.status(404).render('errors/404')
}
500
var log = require('_/log')
module.exports = function (er, req, res, next) {
log.error(er.message)
res.locals.error = er
res.status(500).render('errors/500')
}
So now I want to add my custom middleware app.use(require('_/app/middleware/shareLocals')) which looks like:
module.exports = function (req, res, next) {
res.locals.base_url = req.protocol + '://' + req.get('host');
next();
}
The main problem is that now when I try to use base_url I get 404 error...
So how Express understands what middleware do? That is between my middleware and 404 are no visual differences:
it receives same params
it doesn’t have any if's in it, just throws 404 error
Appears the feeling the middlewares in Express are made for errors (when excepts err as first param) and for 404 (when there is no first err)...
P.S.
Is there any difference defining middlewares before or after routes?
P.S. Is there any difference defining middlewares before or after routes?
Yes.
The order in which you register your middlewares (and routes) have a lot to say.
Image express as a giant list. Starting at the first element in the list, you have the first middleware OR route you have defined, next is the second, etc.
When express gets a request, it appears to be matching your route/name of route/middleware, and if it's a hit, it executes the middleware/route and potentially waits for a "next()" call.
So if you have a route "/test" it will only be executed if you have a request matching "/test". routes with different names obviously wont get triggered. middlewares can also have names: app.use("/test", middlewareA). This will also only trigger if "/test" is requested. The way you do it, all requests (within the routes namespace) will be triggered app.use(middlewareA). It's like a wildcard.
Now, to the implications of things being ordered:
Your 404 middleware should only be used AFTER all routes have been defined. that way, when the list reached the 404 middleware, no routes have actually been found.
returning/sending result/not calling next() at the end of a middleware will all potentially create problems in your flow. I wont go into details about this, but be aware of it.
I am guessing your own middleware is added after the 404 middleware. That is probably the problem. If not, you should surrender more of your code so we can take a better look. But remember, order is everything :)

Something is wrong with domains in NodeJS

I have this simple code. This must show me my error object ({error:'error'}) upon each request. But it shows only "[Object object]".
And moreover - debugger never stops in the error handler function.
What is going on?
var domain = require('domain');
var express = require('express');
var server = express();
server.get('/', function(req, res)
{
var d = domain.create();
d.on('error', function(e)
{
debugger;
console.log(JSON.stringify(e));
});
d.run(function()
{
throw {error:'error'};
res.send('ok');
});
});
server.listen(8080);
The problem is that domains catch the error all the way at the bottom of the call stack, and since express has its own error handling code, the error gets caught by express before reaching the domain. Similar issue here: Node.js - Domain per Express request, inside another domain
I don't see any particularly good reason it should be this way, but that's how the code seems to work [1] (source here: https://github.com/joyent/node/blob/master/lib/domain.js). Possible workarounds are to surround the d.run() call with your own try/catch, or to do something like
d.run(process.nextTick(function() {
// do stuff
}));
[1] The way domains work is that they basically hook into all of the "asynchronous" callbacks and add some information that records who initiated the asynchronous operation. I don't know why they don't also try/catch on the initial synchronous block.

Resources