Search code examples
javascriptnode.jsnpmchromiumnwjs

How to create a server that is only internal to the app in node / npm or modify any response body from outgoing requests


I am trying to develop a node app and require a server that can only be used by the app internally.

I have tried instantiating a server without listening to the port, but can't do anything with it from that point forwards:

let http = require("http");
http.createServer(function (req, res) {
    // custom code
})

This app is being built with NWJS and I need to intercept any outgoing requests (including file resources; CSS, JS, images, etc.) and modify the response, but I am not having any success with it except if I use a server for this purpose.

Problem is it becomes possible to open that server on any browser and I just want it to be used only inside the app or another way to intercept outgoing requests from the app so that the response body can be modified.


Solution

  • I have tried Keith's suggestion of using a service worker to intercept requests, but in my case I could not load a service worker from local environment into live environment (for example, run a local sw file in stackoverflow page), so that suggestion ended there.

    Stdob's suggestion of using a proxy ended up being redundant and more troublesome than my original attempt.

    In the end I went with my original attempt as follows:

    • Using chrome.webRequest.onBeforeRequest (Chrome API) and a local node server.

    • The server is created with an arbitrary port to reduce the risk of hitting an already used port.

    • The chrome API redirects all connections to the local server (ex. url: http://127.0.0.1:5050) and then the server will handle the requests as needed, returning the requested files modified or intact.

    • Last step, add a unique header with a unique value that only the app knows, so that no server access can be made from outside the app.

    It is not the best solution, ideally I would prefer to have something like Firefox's webRequest.filterResponseData, but until Chrome implements that, this will have to do.