I'm developing an Express.js server; since it manages sensible data, I'd like to add a cryptographic signature to every response, using a private key. The signature part is already OK, the problem is catching the JSON string just before is sent to the client to sign it.
Ideally I'd like to add a custom response header, e.g. X-signature, so clients could verify the received payload against the public key exposed by the service.
In Express, how can I intercept the response body after the JSON.stringify() call but before the headers are sent?
I've copied what is done in the compression() middleware, replacing the send() method of Response with my own and calling the original one after I calculate the signature. Here's a simplified solution just to show the concept, in the real word I've taken care of body's possible types. The fact that calculateSignature() is an async function is a little troublesome, but everything seems to work well now.
Any comment is appreciated!
import express, { RequestHandler } from 'express';
declare const calculateSignature = (payload: string) => Promise<string>;
const responseSignature = (): RequestHandler => (_, res, next) => {
const _send = res.send;
res.send = (body) => {
if (isPlaintextType(body)) {
calculateSignature(body)
.then((signature) => res.setHeader('X-Signature', signature))
.catch((e) => console.error(e))
.finally(() => _send.call(res, body));
return res;
} else {
return _send.call(res, body);
}
};
next();
};
const app = express();
app.use(responseSignature());
app.listen(3000);
Related
I'm trying to add some properties to the results of the authentication process. Auth0 sets up Express middleware like this:
export const checkJwt = auth({
audience: process.env.AUTH0_AUDIENCE,
issuerBaseURL: process.env.AUTH0_ISSUERBASEURL,
});
This checks the authorisation header and works fine. It creates an request.auth object and adds payload into that. Works.
However, I want to add details from my own database, such as an ID or an organisation the user belongs to.
I've tried multiple ways to capture the result of auth but just can't get my head around it.
export var newAuth = function (
req: Request,
res: Response,
next: NextFunction
) {
const opts = {
audience: process.env.AUTH0_AUDIENCE,
issuerBaseURL: process.env.AUTH0_ISSUERBASEURL,
};
return (req: Request, res: Response, next: NextFunction) => {
// is the issue here?
var result = auth(opts)(req, res, next);
return result;
}
};
I suppose I'm asking how can I intercept or extend middleware in Express?
Something that I wanted clarification on is when console.logging req.body in my express app. I end up with a buffer/string or hexadecimal of some sort when I'm expecting an JSON object. I'm using postman to send a raw json body.
Here are some visuals of the source code and terminal/postman results.
const express = require('express');
const bodyParser = require('body-parser');
const { randomBytes } = require('crypto');
const app = express();
app.use(express.raw({type: "application/json"}));
app.use(express.json({strict: false}));
app.use(express.urlencoded({extended: false}));
const posts = {};
app.get('/posts', (req, res) => {
res.send(posts);
});
app.post('/posts', (req, res) => {
const id = randomBytes(4).toString('hex');
const { title } = req.body;
console.log(req.body)
posts[id] = {
id,
title: title
};
res.status(201).send(posts[id]);
});
app.listen(4000, () => {
console.log('Listening on 4000');
});
Console.log terminal of buffer/hex/string
Postman body
Postman Raw String
app.use(express.raw({type: "application/json"})); is going to give you a Buffer object and since that's your first middleware that might handle that mime type, that's what you're going to get for any application/json request.
Right from the Express doc for express.raw():
This is a built-in middleware function in Express. It parses incoming
request payloads into a Buffer
It's unclear why you're using express.raw() as that is not typical for JSON payloads, but when doing so, you are going to get a Buffer - that's how it works. One would more typically use express.json() for JSON payloads and let it parse your JSON so that req.body contains an actual Javascript object.
If you remove the app.use(express.raw({type: "application/json"})); line of code and let the app.use(express.json()); line of code right after it handle the application/json payloads, then you will get your parsed data in req.body.
Keep in mind that when using middleware they are processed in the order declared and for this specific type of middleware, the first one that matches and reads the body from the incoming stream takes precedence and none of the others after it will be able to do their job (since the incoming stream has already been read).
I am using an Angular front-end with a Nodejs backend. Im currently proxying all my front-end requests through my express server. However when I make my http request to the Here API I am rejected due to an invalid combination of app_id and app_code.
angular service
import { Injectable } from '#angular/core';
import { HttpClient } from '#angular/common/http'
import { HttpParams } from '#angular/common/http'
#Injectable({
providedIn: 'root'
})
export class GetReqPlaces {
constructor(private http: HttpClient) { }
getPlaces(wLong,sLat,eLong,nLat){
// let obj = {params: {westLong: wLong, southLat: sLat, eastLong:eLong, northLat:nLat }};
let params = new HttpParams().set("westLong" , '-97.783').set("southLat", '30.231').set( "eastLong" , '-97.740').set("northLat", '30.329');
return this.http.get( 'api/find/places', { params : params}).subscribe(res=>console.log(res))
}
}
server.js
const express = require("express")
const bodyParser = require("body-parser")
const cors = require("cors")
const path = require("path")
const app = express();
const request = require("request")
const environment= require('./keys')
app.use(cors());
app.use(bodyParser.urlencoded({extended: true}));
app.use(bodyParser.json());
let reqPath = __dirname.substring(0,__dirname.length-7)
app.use(express.static(path.join(reqPath, '/dist/angular-places-search')));
app.get('/api/find/places', (req, res) => {
let appId = environment.environment.appId;
let appCode = environment.environment.appCode;
let URL= `https://places.cit.api.here.com/places/v1/discover/search?app_id={${appId}}&app_code={${appCode}}&in=${req.query.westLong},${req.query.southLat},${req.query.eastLong},${req.query.northLat}&pretty`;
console.log(URL)
request(URL, function (error, response, body) {
let data={
body:body,
};
console.log(error,response)
res.send(data);
});
});
app.get('/test', (req, res) => res.send('Well this route was a hit! Bada....tsss'));
// CATCH ALL
app.get('*', (req, res) => {
res.sendFile(path.join(reqPath, 'dist/angular-places-search/index.html'));
});
app.listen(4000, () => console.log(`Express server running on port 4000`));
Before this I was running into CORS and request issues but I think I sorted those out. Based on my research on this same error code (In the context of the framework that Im working in), people overwhelmingly suggest to wait for tokens to register with Here API. Waiting two days is enough I think, still doesnt work. Then there is the very popular solution of just scratching the Here freemium and starting a new project, which I did, and which did not solve my issue. Very few things I have 100% certainty on but I did copy my keys correctly and the URL path built is according to the required Here syntax.
If anyone has any insight you will be my Hero, and also the catalyst for my continued learning :D. Happy Sunday!
In addition the incoming message I get through express is :
method: 'GET',
path: '/places/v1/discover/search?app_id=%notmyid%7D&app_code=%normycode%7D&in=-97.783,30.231,-97.740,30.329&pretty'
However i dont know why it is setting the app_id=% instead of using {}, when i console log the URL it is correct, with my app_id and app_code
The %7D is the url encoded value of the symbol } (urlencoding) which is done by most libraries. For using the HERE API you should not enclose the app_id/app_code between {}. They should be provided directly as strings, check the examples
I'm working on a mutation resolver using GraphQL Yoga and using Prisma for my back-end. The mutation is for doing authentication and returning a JWT on successful login. The mutation currently looks like this:
loginEmployer: async (_, args, context, info) => {
const employer = await context.prisma.query.employer({
where: {
name: args.name,
}
})
const match = await bcrypt.compare(args.password, employer.hashedPassword);
if (match) {
return jwt.sign(employer, jwtSecret);
} else {
return "";
}
}
The algorithm is fairly simple as you can see: Find an employer with the matching name, compare the stored hashed password with the incoming using bcrypt, and return a signed jwt if there's a match. Pretty standard stuff.
However in the case there is no match, or if there is no employer matching the name, I'd like to respond with a 403. In express I'd simply do res.status(403).send({error: "No such username/password"}) but with GraphQL Yoga I'm a bit lost and couldn't find any documentation for how to do this.
Thanks for any replies sorting this out or pointing me in the right direction :)
Abhi from prisma here!
In GraphQL Yoga you can pass a context factory which contains the request and the response!
Here's an example!
new GraphQLServer({
typeDefs,
resolvers,
context: ({ req, res, ...rest }) => {
// pass things down in context!
return { req, res, userId: req.headers.userid };
},
})
Then in your resolver, just pull res out of the context object.
Now this does work fine and well, but here's a github issue on a similiar thing that had some other opinions on this: https://github.com/graphql/express-graphql/issues/71
Following #Lars Holdaas - It took me far too long to work out the answer. But the context parameters are request and response.
If you use req/res, it does not work. So a more accurate example:
new GraphQLServer({
typeDefs,
resolvers,
context: ({ request, response, ...rest }) => {
return {
req: request,
res: response,
userId: request.headers.userid
};
},
})
I'm looking for a clean way to have my express app return 405 Method Not Allowed if a client sends a request that matches a mapped url route but does not match the mapped HTTP method.
My current implementation is to have a default "catch-all" handler that tries to match the url against the register routes, ignoring the HTTP method. If there is a match, then we know to return a 405, otherwise we let express do its default 404 behavior.
I'm hoping there is a better way that doesn't involve running all the route matching twice (once by express, once by my handler).
Here is an approach that I have used successfully with multiple Django applications and now with Node and Express. It is also follows RFC 2616 (HTTP/1.1) that says the following about HTTP 405:
The response MUST include an Allow header containing a list of valid
methods for the requested resource.
So, the key point is to route the requests to the same handler without regard to methods.
app.all('/page/:id', page.page);
app.all('/page/:id/comments', page.comments);
app.all('/page/:id/attachments', page.attachments);
...
The next point is to validate the method in the handler function 'comments'. Note that the handler is responsible for handling all the methods. In Django's world this is the only way to go because the framework forces you to separate the routing of the URLs from the actual action about to be performed against the resource the URL represents.
In the handler you could check the method like this...
exports.comments = function (req, res) {
if (req.route.method === 'get') {
res.send(200, 'Hello universe.');
} else {
res.set('Allow', 'GET');
res.send(405, 'Method Not Allowed');
}
}
...but as you can expect the code will quickly become repetitious and not nice to read especially when you have many handler functions and many different sets of allowed methods.
Therefore I prepared a shortcut function named restful for the job. Define the function wherever you want. I personally would place it in helpers.js under the same directory where the handler functions are implemented.
var restful = function (req, res, handlers) {
//
// This shortcut function responses with HTTP 405
// to the requests having a method that does not
// have corresponding request handler. For example
// if a resource allows only GET and POST requests
// then PUT, DELETE, etc requests will be responsed
// with the 405. HTTP 405 is required to have Allow
// header set to a list of allowed methods so in
// this case the response has "Allow: GET, POST" in
// its headers [1].
//
// Example usage
//
// A handler that allows only GET requests and returns
//
// exports.myrestfulhandler = function (req, res) {
// restful(req, res, {
// get: function (req, res) {
// res.send(200, 'Hello restful world.');
// }
// });
// }
//
// References
//
// [1] RFC-2616, 10.4.6 405 Method Not Allowed
// https://www.rfc-editor.org/rfc/rfc2616#page-66
//
// [2] Express.js request method
// http://expressjs.com/api.html#req.route
//
var method = req.route.method; // [2]
if (!(method in handlers)) {
res.set('Allow', Object.keys(handlers).join(', ').toUpperCase());
res.send(405);
} else {
handlers[method](req, res);
}
}
With restful it is now quite painless to handle 405 responses automatically and having proper Allow header being set. Just give a function for each method you allow and restful does the rest.
So lets modify the previous example:
exports.comments = function (req, res) {
restful(req, res, {
get: function (req, res) {
res.send(200, 'Hello restful universe.');
}
});
}
Why the name restful? In RESTful web it is quite essential for the API to obey the conventions like responsing with HTTP 405 to the request having non-supported method. Many of those conventions could be integrated to restful when needed. Therefore the name is restful and not something like auto405 or http405handler.
Hope this helps. Any thoughts?
Method 1: Use .route() and .all()
// Your route handlers
const handlers = require(`./handlers.js`);
// The 405 handler
const methodNotAllowed = (req, res, next) => res.status(405).send();
router
.route(`/products`)
.get(handlers.getProduct)
.put(handlers.addProduct)
.all(methodNotAllowed);
This works because requests are passed to the handlers in the order they are attached to the route (the request "waterfall"). The .get() and .put() handlers will catch GET and PUT requests, and the rest will fall through to the .all() handler.
Method 2: Middleware
Create middleware which checks for allowed methods, and returns a 405 error if the method is not whitelisted. This approach is nice because it allows you to see and set the allowed methods for each route along with the route itself.
Here's the methods.js middleware:
const methods = (methods = ['GET']) => (req, res, next) => {
if (methods.includes(req.method)) return next();
res.error(405, `The ${req.method} method for the "${req.originalUrl}" route is not supported.`);
};
module.exports = methods;
You would then use the methods middleware in your routes like this:
const handlers = require(`./handlers.js`); // route handlers
const methods = require(`./methods.js`); // methods middleware
// allows only GET or PUT requests
router.all(`/products`, methods([`GET`, `PUT`]), handlers.products);
// defaults to allowing GET requests only
router.all(`/products`, methods(), handlers.products);
Due to ambiguity, there really is no other way. Personally, I would do something like this:
var route = '/page/:id/comments'
app.get(route, getComments)
app.all(route, send405)
function send405(req, res, next) {
var err = new Error()
err.status = 405
next(err)
}
Either way, you have to check the routes twice.
Kinda old question but here is what i did. I just put this after all my routes but before my 400 handler
// Handle 405 errors
app.use(function(req, res, next) {
var flag = false;
for (var i = 0; i < req.route.stack.length; i++) {
if (req.method == req.route.stack[i].method) {
flag = true;
}
}
if (!flag) {
err = new Error('Method Not Allowed')
err.status = 405;
return next(err)
}
next();
});
I have been doing it this way:
Say if you have GET and POST method handlers for /. You can wrap the path with app.route or router.route and assign the handlers accordingly.
app.route("/").get((req, res) => {
/* DO SOMETHING*/
}).post((req, res) => {
/* DO SOMETHING*/
}).all((req, res) => {
res.status(405).send();
});
http://expressjs.com/en/4x/api.html#app.route
http://expressjs.com/en/4x/api.html#router.route
A request will get matched to the route and filtered through the handlers. If a handler is present, it will get handled as usual. Else, it will reach the all handler that will set the status code to 405 and ending the request.
I fixed it like this :
/*paths here*/
router.get('/blah/path1', blah.do_something );
router.post('/blah/path2', blah.do_something_else );
/* if we get here we haven't already gone off down another path */
router.all('/*', (req,res) => { res.status(405),
res.json({'status':405,
'message':req.method + ' not allowed on this route'})
});
/* simples */
I thought this was a pretty interesting problem and so I dove deeeeeep down into the depths of the express app function and found a way to dynamically build a 405 error that includes all of the possible routes (without having to manually update anything when you add a new route).
app.use("", (req, _, next) => {
const err = buildError(app, req);
if (!err) return next();
return next(err);
});
For those interested you can find the npm package here https://www.npmjs.com/package/express-ez-405, and below is a quick example of what it looks like to use it.
const express = require("express");
const { buildError } = require("express-ez-405");
const app = express();
app.use(express.json());
const userRouter = require("./routes/user");
const mainRouter = require("./routes/main");
const nestedRouter = require("./routes/nested");
// // Routes
app.use("/main", mainRouter);
app.use("/user", userRouter);
app.use("/nested/route", nestedRouter);
// Routes
// 405 & 404 error catcher
app.use("", (req, _, next) => {
const err = buildError(app, req);
if (!err) return next();
return next(err);
});
// 405 & 404 error catcher
// Error handling
app.use((err, _, res, __) =>
res.status(err.status).json({ message: err.message })
);
// Error handling
const PORT = 3000;
app.listen(PORT, () => {
console.log(`Server listening on port: ${PORT}...`);
});
Once this in in there you never have to worry about updating it regardless of whether you add, remove, or change routing.