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.
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 settings.py:
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:
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.
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.
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.