Loopback-datasource-juggler: How to disable stack trace errors (for security)

Created on 28 Aug 2014  Â·  17Comments  Â·  Source: loopbackio/loopback-datasource-juggler

Errors (even simple 404 errors) are outputting stack traces that gives away information like script and folder names that really shouldn't be accessible to a web accessible api.

"stack": "Error: Unknown Model id \"53fe610a98fb14c238bb6f91\".\n    at /vagrant/projects/...

Most helpful comment

Hey guys, I struggled with this as well, but made it work with ENV vars by setting the config as @raymondfeng mentioned!

(Note, I could not make this work by setting the middleware as @franher mentioned - I'm note sure why, since it is obviously stated in the Loopback documentation. Setting loopback.rest({disableStackTrace: true}) did not work either)

This is my working solution:

  • Leave config.json as default made when application was made (or see example here)
  • Create config.{env}.json (ex. config.prod.json) with the content of @raymondfeng's post.

Now run NODE_ENV={env} node . (like NODE_ENV=prod node .

All 17 comments

The stack is removed if:

  • process.env.NODE_ENV === 'production'

or

  • loopback.rest({disableStackTrace: true})

I modified ./server/boot/rest-api.js to have:
server.use(restApiRoot, server.loopback.rest({disableStackTrace: true}));

Yet im still seeing stack traces in my errors. Is there something I'm missing? Thanks

My bad, the option should be configured in server/config.json:

{
  "remoting": {
    "errorHandler": {
      "disableStackTrace": true
    }
}

Thanks

On Fri, Oct 17, 2014 at 1:50 PM, Raymond Feng [email protected]
wrote:

My bad, the option should be configured in server/config.json:

{
"remoting": {
"errorHandler": {
"disableStackTrace": true
}}

—
Reply to this email directly or view it on GitHub
https://github.com/strongloop/loopback-datasource-juggler/issues/263#issuecomment-59549962
.

Hi @raymondfeng I have the "disableStackTrace": true option set in my config.json file but I still get stack traces on my 404 errors. I have also tried setting NODE_ENV=production and it did not work either. I also tried the loopback.rest({disableStackTrace: true}) and it did not work either.
Am I missing something?

same problem for me as above comment

I know that this was asked a long time ago but I found this thread today, then spent an hour or so figuring out the problem so maybe someone else will benefit from a writeup:

If your loopback app was generated similarly to mine, then the disableStackTrace setting only applies to things that have made it as far as the strong-remoting rest handler and the handler unknown URLs is wired up in middleware.json via a config block that looks like this:

"final": {
    "loopback#urlNotFound": {}
}

A bit of delving shows that middleware to be pointed at the errorhandler module which is really meant to be wired up only for development environments- it ALWAYS gives stack traces and is NOT what's being used for any of the REST routes.

You _could_ configure the urlNotFound middleware so it is suppressed in production environments but gives the stack track for dev, but IMO that's kind of worthless because all the juicy stack traces aren't going to that middleware... I just took it out altogether and got a nice, vanilla, 404 from express on routes that my app doesn't handle (which is what I wanted). If you want more than that, I'd still rip it out and find another middleware or hand-wire a default handler for unknown routes.

In the server/config.json file, under the remoting property I changed the property for disableStackTrace from false to true and it removed the stackTrace for me on errors.

"errorHandler": {
      "disableStackTrace": true
    }

This is still an issue for me. I am running on latest loopback version and it still shows the stack traces. Any ideas?

I'm also getting stack traces. I have set disableStackTrace:"true" in config for every environment I have and it still shows.

Is interesting to see that stackTraces are being shown for my custom Error object but not for example for 404 (url not found) responses.

@raymondfeng none of the solutions posted here work for me on 404

I had same problem but taking a look on loopback documentation you can find the solution:

On server/middleware.json:

 "final:after": {
    "loopback#errorHandler": {
      "params": {
        "includeStack": false
      }
    }
  }

@franher That does work, thanks. However, it also suppresses the trace both when I'm developing and from my logs, which I'd prefer to have.

@uooq sparked an idea for me. Rather than rely upon Loopback's error handler middleware, I copied it to a new file and modified it to check the node environment variable. Must also update server/middleware.json to point to this modified version instead.

middleware/customUrlNotFound.js

module.exports = function() {
    return function customRaiseUrlNotFoundError(req, res, next) {
        var error = new Error('Cannot ' + req.method + ' ' + req.url);
        error.status = 404;
        if (process.env.NODE_ENV === 'production') {
            delete error.stack;
        }
        next(error);
    };
};

server/middleware.json

"final": {
    "./middleware/customUrlNotFound.js": {}
  }

None of the solutions above worked.

Any ideas of how I can disable the error stack on production?

Hey guys, I struggled with this as well, but made it work with ENV vars by setting the config as @raymondfeng mentioned!

(Note, I could not make this work by setting the middleware as @franher mentioned - I'm note sure why, since it is obviously stated in the Loopback documentation. Setting loopback.rest({disableStackTrace: true}) did not work either)

This is my working solution:

  • Leave config.json as default made when application was made (or see example here)
  • Create config.{env}.json (ex. config.prod.json) with the content of @raymondfeng's post.

Now run NODE_ENV={env} node . (like NODE_ENV=prod node .

Is it possible to specify a file to use instead of strong-error-handler/views/default-error.ejs in config.json or somewhere ?

The documentation to solve this issue with lb3 is here: https://loopback.io/doc/en/lb3/Using-strong-error-handler.html#migration-from-old-loopback-error-handler

Was this page helpful?
0 / 5 - 0 ratings