-
Notifications
You must be signed in to change notification settings - Fork 92
[SEMVER-MAJOR] Implement strong error handler for rest-adapter #302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,3 +27,89 @@ To disable a static remote method | |
|
|
||
| To disable a prototype remote method: | ||
| `disableMethodByName('prototype.updateAttributes')` | ||
|
|
||
| ## New error-handler for rest-adapter | ||
|
|
||
| The REST adapter (typically created via `loopback.rest()`) uses a new error | ||
| handler implementation that provides more secure configuration out of the box. | ||
|
|
||
| The `error.status` has been removed and will be replaced by `error.statusCode`, | ||
| `statusCode` is more descriptive and avoids ambiguity, users relying on `status` | ||
| will need to change implementation accordingly. | ||
|
|
||
| To replicate old behavior user can specify `config.local.js` as follow: | ||
| ```js | ||
| module.exports = { | ||
| remoting : { | ||
| errorHandler: { | ||
| handler : function(err, req, res, defaultHandler) { | ||
| err.status = err.statusCode; | ||
| defaultHandler(); | ||
| } | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| The environment setting `NODE_ENV='production'` is no longer supported, | ||
| production vs. debug mode is controlled exclusively by configuration. | ||
| Production environment is assumed by default, the insecure debug mode | ||
| must be explicitely turned on. | ||
|
|
||
| You can learn more about the rationale behind the new handler in | ||
| [this comment](https://github.com/strongloop/loopback/issues/1650#issuecomment-161920555) | ||
|
|
||
| User can specific options in their applications in `config.json` as follow: | ||
| ```json | ||
| { | ||
| "restApiRoot": "/api", | ||
| "host": "0.0.0.0", | ||
| "port": 3000, | ||
| "remoting": { | ||
| "errorHandler": { | ||
| "debug": false, | ||
| "log": false | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please add a link to strong-error-handler GH repository, so that people can easily find description of the config options available.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I see the link is already included below, ignore this comment. |
||
|
|
||
| #### Production mode | ||
|
|
||
| Stack trace is never returned in HTTP responses. | ||
|
|
||
| Bad Request errors (4xx) provide the following properties copied from the | ||
| error object: `name`, `message`, `statusCode` and `details`. | ||
|
|
||
| All other errors (including non-Error values like strings or arrays) provide | ||
| only basic information: `statusCode` and `message` set to status name from HTTP | ||
| specification. | ||
|
|
||
| #### Debug mode | ||
|
|
||
| When in debug mode, HTTP responses include all properties provided by the error. | ||
|
|
||
| For errors that are not an object, their string value is returned in | ||
| `message` field. | ||
|
|
||
| When a method fails with an array of errors (e.g. bulk create), HTTP the response | ||
| contains still a single wrapper error with `details` set to the original array | ||
| of errors. | ||
|
|
||
| An example of an error response when an array of errors was raised: | ||
|
|
||
| ```js | ||
| { | ||
| error: { | ||
| statusCode: 500, | ||
| name: 'ArrayOfErrors', | ||
| message: 'Failed with multiple errors, see `details` for more information.', | ||
| details: [ | ||
| { name: 'Error1', message: 'expected error', statusCode: 500, stack: '<stacktrace>' }, | ||
| { name: 'Error2', message: 'expected error2', statusCode: 500, stack: '<stacktrace>'} | ||
| ] | ||
| } | ||
| } | ||
| ``` | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please add a link to this pull request so that people can find the discussion that led to this change (see other release note entries) and also a pointer to strong-error-handler so that people can find more information about the settings available in this new error handler. |
||
|
|
||
| Please see [Related code change](https://github.com/strongloop/strong-remoting/pull/302) here, and new [`strong-error-handler` here](https://github.com/strongloop/strong-error-handler/). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure about this? I think a better option is to configure strong-remoting's error handler via
server/middleware.json, but we may not be there yet.{ "routes": { "loopback#rest": { "params": { "debug": true, "log": true } } }There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm it works in my sand-box
i think the behavior comes from
strong-remoting/lib/rest-adapter.js
Line 315 in aa391d2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we can update this when we change it to use middleware.json?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are already using middleware.json. But never mind, let's leave this out of scope of this pull request and stay consistent with the current state of affairs (i.e. configure it via
server/config.json).