REST API - 在授权模型中使用端点属性? [英] REST API - use endpoint properties in authorization model?

问题描述

授予访问端点的权限是一种好习惯吗?

Is it a good practice to give permission to access endpoint?

例如

POST /permissions {method: "GET", resource: {href: "/users/*"}}
-> 201 {href: "/permissions/12345", id: 12345}

POST /roles/123/rolePermissions {permission: {id: 12345}}

然后用给定的模式检查权限...

and after this check the permission with the given pattern...

例如，如果我想授权一位朋友编辑我的一篇文章，我可以执行以下操作:

For example if I want to give permission to a friend to edit one of my articles, I can do the following:

GET /users/13/userPermissions
-> 200 {items: [{id: 99, shares: [], permission: {id: 1234, method: "PUT", resource: {href: "/article/1"}}}, ...]}

客户端用我自定义的权限打印了一张漂亮的表格，现在我可以选择权限1234，分享给我的朋友:

The client prints a fancy table with my custom permissions, now I can choose the permission 1234, and share it with my friend:

POST /userPermissions/99/shares {user: {id: 15}}
-> 201 {id: 111111}
-> new permission to "DELETE /userPermissions/99/shares/111111" is created and given to me (13)
-> permission to "PUT /article/1" given to my friend (15)

然后我也可以删除它

DELETE /userPermissions/99/shares/11111
-> permission to "PUT /article/1" revoked from my friend (15)
-> permission to "DELETE /userPermissions/99/shares/111111" revoked from me (13) and deleted

如果这种方法不能存储和检查权限，那么最佳做法是什么?

If this approach is not okay to store and check permissions, then what are the best practices?

推荐答案

不，不是.REST 只是一种交付方式.你可以有其他的交付，比如 SOAP、纯 HTML web 应用程序、flash、java 等等......所以授权逻辑必须独立于它们，它应该是业务逻辑的一部分，或者它应该介于两者之间业务逻辑和交付.

No, it is not. REST is just one type of delivery. You can have other deliveries, like SOAP, plain HTML web application, flash, java, and so on... So the authorization logic must be independent from them, and it should be part of the business logic, or it should be between the business logic and the deliveries.

这篇关于REST API - 在授权模型中使用端点属性?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！