Authentication and Authorization认证和授权(flask-eve)
博客专区 > timluo 的博客 > 博客详情
Authentication and Authorization认证和授权(flask-eve)
timluo 发表于3年前
Authentication and Authorization认证和授权(flask-eve)
  • 发表于 3年前
  • 阅读 77
  • 收藏 0
  • 点赞 0
  • 评论 0

原文地址 http://python-eve.org/authentication.html


Introduction to Security  安全入门

Authentication is the mechanism whereby systems may securely identify their users. Eve supports several authentication schemes: Basic Authentication, Token Authentication, HMAC Authentication.

认证是让系统可以安全识别他们用户的机制,eve支持几种认证模式:Basic Authentication, Token Authentication, HMAC Authentication.

Authorization is the mechanism by which a system determines what level of access a particular (authenticated) user should have access to resources controlled by the system. In Eve, you can restrict access to all API endpoints, or only some of them. You can protect some HTTP verbs while leaving others open. For example, you can allow public read-only access while leaving item creation and edition restricted to authorized users only. You can also allow GET access for certain requests and POST access for others by checking the method parameter. There is also support for role-based access control.

授权是系统可以让其决定什么级别的特定用户可以访问系统控制的资源机制,在eve中,你可以限制所有的api资源,也可以部分限制,你可以限制一些http操作而开发另外一下操作,例如,你可以开放只读权限,仅让授权的用户新建和修改。你也可以

Security is one of those areas where customization is very important. This is why you are provided with a handful of base authentication classes. They implement the basic authentication mechanism and must be subclassed in order to implement authorization logic. No matter which authentication scheme you pick the only thing that you need to do in your subclass is override the check_auth() method.

安全是一个可定制化很重要的领域之一,这也是为什么给你提供了几个基础认证类,他们实现基础认证机制,必须是子类以实现认证逻辑,无论你选择哪种认证模式,你都必须要在子类中复写check_auth方法

Global Authentication  全局认证

To enable authentication for your API just pass the custom auth class on app instantiation. In our example we’re going to use the BasicAuth base class, which implements the Basic Authentication scheme:

要让api使用认证只需要给app的实例传递一个自定义的auth类,在本例中,我们会使用BasicAuth基本类,它实现了基本认证模式:

<code>

All your API endpoints are now secured, which means that a client will need to provide the correct credentials in order to consume the API:

所有的api资源都受保护了,这意味着客户端需要提供准确的凭证才能使用api.

By default access is restricted to all endpoints for all HTTP verbs (methods), effectively locking down the whole API.

默认所有的资源http操作都受到限制了,有效的封锁了整个api.

But what if your authorization logic is more complex, and you only want to secure some endpoints or apply different logics depending on the endpoint being consumed? You could get away with just adding logic to your authentication class, maybe with something like this:

但是如果你的认证逻辑更复杂,你只想要保护某些资源或者依赖于资源的具体使用来应用不同逻辑呢?你可以用添加逻辑到你的新认证类来解决这个问题,也许像下面这样:

<code>

If needed, this approach also allows to take the request method into consideration, for example to allow GET requests for everyone while forcing validation on edits (POST, PUT, PATCH, DELETE).

如果需要,这种方法也可以让请求方法纳入考虑,例如让允许所有的get请求而在编辑操作上强制认证。

Endpoint-level Authentication 端点级别认证

The one class to bind them all approach seen above is probably good for most use cases but as soon as authorization logic gets more complicated it could easily lead to complex and unmanageable code, something you don’t really want to have when dealing with security.

上面这个类绑定到所有的方法可能对大部分用例是行得通的,但是一旦认证逻辑越来越复杂,它很容易导致复杂难维护的代码。一些你并不是真正想要用来处理安全的。

Wouldn’t it be nice if we could have specialized auth classes that we could freely apply to selected endpoints? This way the global level auth class, the one passed to the Eve constructor as seen above, would still be active on all endpoints except those where different authorization logic is needed. Alternatively, we could even choose to not provide a global auth class, effectively making all endpoints public, except the ones we want protected. With a system like this we could even choose to have some endpoints protected with, say, Basic Authentication while others are secured with Token, or HMAC Authentication!

如果我们可以有专门的认证类来自由处理选择的端点资源岂不是很酷?刚才上面所见的传给eve构造方法的全局级别认证类,可以作用于所有的端点资源除非需要不同的认证逻辑,我们不必要使用一个全局认证类,也能很好的开放端点资源,同时保护我们想要保护的,用这样一个系统我们可以选择部分端点来保护,也就是说,使用基本认证,而其他用token或者HMAC认证来处理。

Well, turns out this is actually possible by simply enabling the resource-level authentication setting when we are defining the API domain.

原来通过定义api domain,简单的资源级别的认证设置就可以实现。

And that’s it. The people endpoint will now be using the MySuperCoolAuth class for authentication, while the invoices endpoint will be using the general-purpose auth class if provided or else it will just be open to the public.

就是这样,people端点将会用MySuperCoolAuth来认证,而invoices资源可以使用通用认证或者直接公共开放。

There are other features and options that you can use to reduce complexity in your auth classes, especially (but not only) when using the global level authentication system. Lets review them.

这儿也有其他特性和选择你可以来降低复杂度,尤其是使用全局认证系统。

Global Endpoint Security  全局端点安全

You might want a public read-only API where only authorized users can write, edit and delete. You can achieve that by using the PUBLIC_METHODS and PUBLIC_ITEM_METHODS global settings. Add the following to your settings.py:

你可能想要一个开放的只读api,仅仅认证用户可以修改,编辑,删除。你可以用 PUBLIC_METHODS,PUBLIC_ITEM_METHODS全局设置来达到目的,添加下面的设置:

And run your API. POST, PATCH and DELETE are still restricted, while GET is publicly available at all API endpoints. PUBLIC_METHODS refers to resource endpoints, like /people, while PUBLIC_ITEM_METHODS refers to individual items like /people/id.

运行你的api,POST, PATCH and DELETE仍然受限制,而get是对所有资源开放的,PUBLIC_METHODS对应资源端点像/people,而PUBLIC_ITEM_METHODS对应独立的子类别,像/people/id


Custom Endpoint Security 自定义端点安全

Suppose that you want to allow public read access to only certain resources. You do that by declaring public methods at resource level, while declaring the API domain:

假如你想要对某部分资源开放只读权限,你可以在资源级别定义开放方法,像这样设置api domain:

<code>

Be aware that, when present, resource settings override global settings. You can use this to your advantage. Suppose that you want to grant read access to all endpoints with the only exception of /invoices. You first open read access for all endpoints:

这种情况下要注意的是,资源级别的设置会覆盖全局设置,你可以选择性使用,假如你只想要授予所有资源端点只读权限,而/invoices除外,你首先对所有资源端点打开只读权限:

<code>

Then you protect the private endpoint:然后你保护要保护的资源。

Effectively making invoices a restricted resource.很好的让invoices收到访问限制

Basic Authentication 基础认证


The eve.auth.BasicAuth class allows the implementation of Basic Authentication (RFC2617). It should be subclassed in order to implement custom authentication.

eve.auth.BasicAuth类允许实现 Basic Authentication ,为了实现自定义认证,应该成为其子类

Basic Authentication with bcrypt  用bcrypt做基础认证

Encoding passwords with bcrypt is a great idea. It comes at the cost of performance, but that’s precisely the point, as slow encoding means very good resistance to brute-force attacks. For a faster (and less safe) alternative, see the SHA1/MAC snippet further below.

用bcrypt编码密码是一个好主意,它会消耗性能,但这也正是问题所在,加密慢意味着可以阻抗暴力破解,一个更快(更少安全)的替代,可以下面进一步看看SHA1/MAC。

This script assumes that user accounts are stored in an accounts MongoDB collection, and that passwords are stored as bcrypt hashes. All API resources/methods will be secured unless they are made explicitly public.

下面的代码假设用户账户已经保持到一个accounts的mongodb集合中,密码是用bcrypt hash保持,所有api资源将会安全除了他们特别的被开放。

Basic Authentication with SHA1/HMAC 用sha1/hmac做基础认证

<code>


Token-Based Authentication 基于令牌的认证

Token-based authentication can be considered a specialized version of Basic Authentication. The Authorization header tag will contain the auth token as the username, and no password.

可以将令牌认证当做基础认证的一个特例。认证header包将会包含验证令牌作为用户名,没有密码。

HMAC Authentication HMAC认证

The eve.auth.HMACAuth class allows for custom, Amazon S3-like, HMAC (Hash Message Authentication Code) authentication, which is basically a very secure custom authentication scheme built around the Authorization header.

eve.auth.HMACAuth类用于自定义, Amazon S3-like。HMAC认证基于一个安全的自定义认证模式,

How HMAC Authentication Works  HMAC认证如何运行

The server provides the client with a user id and a secret key through some out-of-band technique (e.g., the service sends the client an e-mail containing the user id and secret key). The client will use the supplied secret key to sign all requests.

When the client wants to send a request, he builds the complete request and then, using the secret key, computes a hash over the complete message body (and optionally some of the message headers if required)

Role Based Access Control 角色控制

The code snippets above deliberately ignore the allowed_roles parameter. You can use this parameter to restrict access to authenticated users who also have been assigned specific roles.

上面的代码片段故意忽略了 allowed_roles参数,你可以它来限制赋予特别角色的认证用户访问权限。

First, you would use the new ALLOWED_ROLES and ALLOWED_ITEM_ROLES global settings (or the corresponding allowed_roles and allowed_item_roles resource settings).

首先,你需要用新的 ALLOWED_ROLES和ALLOWED_ITEM_ROLES 全局设置。

User-Restricted Resource Access 用户受限资源访问

When this feature is enabled, each stored document is associated with the account that created it. This allows the API to transparently serve only account-created documents on all kinds of requests: read, edit, delete and of course create. User authentication needs to be enabled for this to work properly.

当这个特性打开,每个存储的文档与创建它的账户相关联。

At the global level this feature is enabled by setting AUTH_FIELD and locally (at the endpoint level) by setting auth_field. These properties define the name of the field used to store the id of the user who created the document. So for example by setting AUTH_FIELD to user_id, you are effectively (and transparently to the user) adding a user_id field to every stored document. This will then be used to retrieve/edit/delete documents stored by the user.


共有 人打赏支持
粉丝 2
博文 6
码字总数 3543
×
timluo
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: