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

标题:腾讯云 新注册用户域名抢购1元起>>>   


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.


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.


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:



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:


By default access is restricted to all endpoints for all HTTP verbs (methods), effectively locking down the whole 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:



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).


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!


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.


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

你可能想要一个开放的只读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:


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:



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.


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做基础认证


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.


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).


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.

共有 人打赏支持
粉丝 1
博文 6
码字总数 3543
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
* 支付类型