比如"/api/v1/orders/{orderID}/action/cancel",这是一个对订单进行取消的API地址,很明显能进行这个操作的必须是订单交易双方用户,即用户只能操作orderID是属于自己的订单
1.spring security还有shiro这些安全框架都是基于角色(role)来做控制,没有精确到对象级别,虽然他们也有对象级别的权限控制,但是十分复杂不优雅,请教大家是怎么做的
2.如果在spring中的service层来做可以吗?在业务逻辑处理之前service自己判断用户是否有权限,这样就要求每个service层的方法参数中都要有当前用户的ID
3.如果在controller层调用service之前再独立一层专门做权限校验的是否可行
综上:请教大家在开发RESTful API时权限这方面是怎么做的,谢谢
迷茫2017-04-18 10:21:31
あなたの権限はデータレベルの権限であり、Spring Security や hiro などの一般的な authc および authz フレームワークでは解決できません。
つまり、コントロールは引き続き手元にあり、コントローラーまたはサービスに書き込むことができます。ただし、これはビジネス ロジックの一部であるため、サービス内に記述することをお勧めします。
大家讲道理2017-04-18 10:21:31
権限は必要ありません。この API を呼び出すと、すぐにユーザーに注文 ID が渡されたかどうかが直接判断されます。また、この操作は注文トランザクションのユーザーとサードパーティの両方が実行する必要があるとも言いました。この注文 ID は使用できません。
高洛峰2017-04-18 10:21:31
インターセプタを自分でラップし、パラメータとロールに基づいて認証します。たとえば、ユーザーセッションに従って、orderId に基づいて userId を取得し、それがユーザーであるかどうかを判断します。
伊谢尔伦2017-04-18 10:21:31
restfull のコントローラーは完全なビジネスであり、多くのサービスを呼び出す可能性があり、サービスは JMS メッセージなどの他の分散リクエストもトリガーする可能性があるため、通常はコントローラーのアノテーションとしてバリデーターを作成する必要があります。古代のバックエンド JSP や FreeMarker のコントローラーとは異なります。古代のコントローラーには、パラメーターの検証、パラメーターのフォーマット、ビジネスの実行、対応するパラメーターの組み立て、次のページへのジャンプなどの機能があります。残りのステップが欠落しているため、コントローラーに追加する必要があります