羽毛允许的动词配置
feathers allowed verbs configuration
我是 feathersjs (v2.0) 的新手,刚刚开发了一个小型 REST 应用程序,该应用程序使用 feathers 只能找到少量记录。但是,我不知道,我还没有找到一种方法,阅读文档和示例,只允许 FIND 而不是获取、放置、删除等。有没有办法配置羽毛 REST [中允许使用哪些动词? =49=]?。我试图在只有 return 的前挂钩(在服务挂钩中)中添加一个拒绝函数,但是 500 错误是 returned,响应是:
{"name":"GeneralError","message":"Cannot read property 'bind' of
undefined","code":500,"className":"general-error","data":{},"errors":{}}
其他动词的默认值(钩子文件中没有任何函数)是:
"name":"NotFound","message":"No record found for id
'null'","code":404,"className":"not-found","errors":{}}
这是有道理的,但我个人的感觉是,如果你不需要这些动词,为什么我需要允许它们并且 return 这个 "misleading" 错误?
更新:
我做到了,但我不满意,因为响应 headers 与实际发生的情况不符。
为了获取 headers 信息,我必须在服务文件中添加此代码
// This must be before the service creation
app.use(function(req, res, next) {
req.feathers.headers = req.headers;
next();
});
app.use('/myservice', createService(options));
基于 here 给出的答案。但是,daffl 给出的函数在服务创建参数上的答案不适用于使用 feathers-cli 生成的代码,因此它必须在之前(有更好的方法吗?,如何设置为第二个或第一个参数createService 函数?或在选项 object 内,这可能吗?我只是遇到编译错误)。我必须用钩子函数定义一个新文件并将其包含到 "myservice.hooks.js"
module.exports = function () {
return function (hook) {
if(hook.method !== 'find' && hook.method !== 'error'){
throw new Error('Method not allowed');
}else{
return hook;
}
};
};
这当然会产生 500 错误,但在 'GET' 上允许 header 应该是 405 错误。我也尝试使用此代码而不是抛出错误:
hook.params.headers.allow = 'GET';
hook.params.headers.status = 405;
它工作得更好,但是在删除时它会尝试删除数据库中的记录(幸运的是数据库用户只有 select 权限),但这不应该在 POST 和 PUT 类似的行为。只有响应 header 状态不是 200 OK 而是 400 (?!!) 并且允许 header 没有改变,所以它是 "GET,POST,PUT,PATCH,DELETE"。
我读过 this solution,但我不知道如何使用羽毛 hook.params.headers(或 hook.header(s) 正确设置 headers 的值但它是未定义的)到 return 一个更合适的 header 响应,当然不要再继续了。有什么想法吗?请大发慈悲,我只是一个初学者(不到一周),也许这是一个 stupid/obvious 问题。
提前致谢。
要抛出正确的错误代码,您必须使用 feathers-errors
,如 errors API documentation 中所述。您可以通过使用 MethodNotAllowed
错误并将钩子更改为:
来抛出 405
const errors = require('feathers-errors');
module.exports = function () {
return function (hook) {
if(hook.method !== 'find' && hook.method !== 'error'){
throw new errors.MethodNotAllowed('Method not allowed');
}else{
return hook;
}
};
};
另外不要忘记将 Express 错误句柄设置为 pointed out in the same chapter
我是 feathersjs (v2.0) 的新手,刚刚开发了一个小型 REST 应用程序,该应用程序使用 feathers 只能找到少量记录。但是,我不知道,我还没有找到一种方法,阅读文档和示例,只允许 FIND 而不是获取、放置、删除等。有没有办法配置羽毛 REST [中允许使用哪些动词? =49=]?。我试图在只有 return 的前挂钩(在服务挂钩中)中添加一个拒绝函数,但是 500 错误是 returned,响应是:
{"name":"GeneralError","message":"Cannot read property 'bind' of undefined","code":500,"className":"general-error","data":{},"errors":{}}
其他动词的默认值(钩子文件中没有任何函数)是:
"name":"NotFound","message":"No record found for id 'null'","code":404,"className":"not-found","errors":{}}
这是有道理的,但我个人的感觉是,如果你不需要这些动词,为什么我需要允许它们并且 return 这个 "misleading" 错误?
更新:
我做到了,但我不满意,因为响应 headers 与实际发生的情况不符。
为了获取 headers 信息,我必须在服务文件中添加此代码
// This must be before the service creation
app.use(function(req, res, next) {
req.feathers.headers = req.headers;
next();
});
app.use('/myservice', createService(options));
基于 here 给出的答案。但是,daffl 给出的函数在服务创建参数上的答案不适用于使用 feathers-cli 生成的代码,因此它必须在之前(有更好的方法吗?,如何设置为第二个或第一个参数createService 函数?或在选项 object 内,这可能吗?我只是遇到编译错误)。我必须用钩子函数定义一个新文件并将其包含到 "myservice.hooks.js"
module.exports = function () {
return function (hook) {
if(hook.method !== 'find' && hook.method !== 'error'){
throw new Error('Method not allowed');
}else{
return hook;
}
};
};
这当然会产生 500 错误,但在 'GET' 上允许 header 应该是 405 错误。我也尝试使用此代码而不是抛出错误:
hook.params.headers.allow = 'GET';
hook.params.headers.status = 405;
它工作得更好,但是在删除时它会尝试删除数据库中的记录(幸运的是数据库用户只有 select 权限),但这不应该在 POST 和 PUT 类似的行为。只有响应 header 状态不是 200 OK 而是 400 (?!!) 并且允许 header 没有改变,所以它是 "GET,POST,PUT,PATCH,DELETE"。
我读过 this solution,但我不知道如何使用羽毛 hook.params.headers(或 hook.header(s) 正确设置 headers 的值但它是未定义的)到 return 一个更合适的 header 响应,当然不要再继续了。有什么想法吗?请大发慈悲,我只是一个初学者(不到一周),也许这是一个 stupid/obvious 问题。
提前致谢。
要抛出正确的错误代码,您必须使用 feathers-errors
,如 errors API documentation 中所述。您可以通过使用 MethodNotAllowed
错误并将钩子更改为:
const errors = require('feathers-errors');
module.exports = function () {
return function (hook) {
if(hook.method !== 'find' && hook.method !== 'error'){
throw new errors.MethodNotAllowed('Method not allowed');
}else{
return hook;
}
};
};
另外不要忘记将 Express 错误句柄设置为 pointed out in the same chapter