【问题标题】:Sails.js middleware vs. policiesSails.js 中间件与策略
【发布时间】:2017-07-13 05:29:12
【问题描述】:

我正在将sails 0.10.5(交给我)迁移到sails 0.12.x。

应用程序或多或少是移动(cordova/混合)客户端使用的 API。

作为迁移的一部分,我想以正确的方式重建一些部分。

我问了一个关于与here 部分相关的中间件的问题。

我正在使用护照进行身份验证(替换旧的 AuthController 代码),现在我实现了 JWT(暂时选择不使用sails-auth)。

据我所知,在大多数情况下,人们使用 passport-JWT 通过 policy 来验证/检查是否存在有效令牌。

在之前的实现中,(expressJwt) middleware 用于将用户“注入”到请求中,req.user 几乎用于我所有的控制器方法中,并且在一些现有政策。

采用基于策略的方法将要求(几乎)我的所有路由都具有isAuthenticated 策略。这意味着如果有人忘记放置策略,控制器可能会失败,或者更糟的是,未经身份验证的用户可能会访问路由。

可以使用*: 'isAuthenticated',但由于策略会覆盖并且不会“级联”,因此某人(不“了解绳索”)可以在不调用isAuthenticated 的情况下执行somemethod: ['isThis','isThat'],从而导致相同的漏洞。

问题是 - 我应该使用基于策略的方法还是添加自定义中间件来进行身份验证并将用户添加到请求(我猜想像 passport.session 所做的那样,或多或少)在这里有意义吗?

我也在使用 socket.io,所以这是否会改变一些有利于基于策略或基于中间件的方法? (我记得读过“假”套接字路由只通过一些中间件堆栈)

【问题讨论】:

    标签: javascript node.js sails.js


    【解决方案1】:

    政策

    策略应该用于身份验证。您不应仅使用策略来修改请求。如果是 Auth 相关的,可以使用它们来修改请求。

    中间件

    每当您需要以某种方式(或响应)修改请求但与身份验证无关时,您都应该使用中间件。

    【讨论】:

    • 策略的其他用途:- 为一个/多个路由应用无缓存标头或检查特定 api 端点的白名单或黑名单或检查用户是否已解决验证码以访问 api。如果我做错了,请告诉我?
    猜你喜欢
    • 2014-02-16
    • 2014-04-20
    • 1970-01-01
    • 1970-01-01
    • 2015-01-24
    • 2016-04-19
    • 1970-01-01
    • 2015-02-14
    • 2014-04-11
    相关资源
    最近更新 更多