encode/django-rest-framework
1
1
Fork 0
mirror of https://github.com/encode/django-rest-framework.git synced 2025-07-29 17:39:48 +03:00
Code Issues Packages Projects Releases Wiki Activity

Fix grammer to be more appropriate

Browse Source
This commit is contained in:
sangwoo-98 2021-03-27 18:06:19 +09:00
parent 0323d6f895
commit 68fe6d1779
1 changed files with 40 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
docs/api-guide/authentication.md
View File

@ -13,7 +13,7 @@ Authentication is the mechanism of associating an incoming request with a set of
REST framework provides a number of authentication schemes out of the box, and also allows you to implement custom schemes. REST framework provides a number of authentication schemes out of the box, and also allows you to implement custom schemes.
Authentication is always run at the very start of the view, before the permission and throttling checks occur, and before any other code is allowed to proceed. Authentication always runs at the very start of the view, before the permission and throttling checks occur, and before any other code is allowed to proceed.
The `request.user` property will typically be set to an instance of the `contrib.auth` package's `User` class. The `request.user` property will typically be set to an instance of the `contrib.auth` package's `User` class.
@ -81,8 +81,8 @@ Or, if you're using the `@api_view` decorator with function based views.
When an unauthenticated request is denied permission there are two different error codes that may be appropriate. When an unauthenticated request is denied permission there are two different error codes that may be appropriate.
* [HTTP 401 Unauthorized][http401] - [HTTP 401 Unauthorized][http401]
* [HTTP 403 Permission Denied][http403] - [HTTP 403 Permission Denied][http403]
HTTP 401 responses must always include a `WWW-Authenticate` header, that instructs the client how to authenticate. HTTP 403 responses do not include the `WWW-Authenticate` header. HTTP 401 responses must always include a `WWW-Authenticate` header, that instructs the client how to authenticate. HTTP 403 responses do not include the `WWW-Authenticate` header.
@ -109,8 +109,8 @@ This authentication scheme uses [HTTP Basic Authentication][basicauth], signed a
If successfully authenticated, `BasicAuthentication` provides the following credentials. If successfully authenticated, `BasicAuthentication` provides the following credentials.
* `request.user` will be a Django `User` instance. - `request.user` will be a Django `User` instance.
* `request.auth` will be `None`. - `request.auth` will be `None`.
Unauthenticated responses that are denied permission will result in an `HTTP 401 Unauthorized` response with an appropriate WWW-Authenticate header. For example: Unauthenticated responses that are denied permission will result in an `HTTP 401 Unauthorized` response with an appropriate WWW-Authenticate header. For example:
@ -150,8 +150,8 @@ For clients to authenticate, the token key should be included in the `Authorizat
If successfully authenticated, `TokenAuthentication` provides the following credentials. If successfully authenticated, `TokenAuthentication` provides the following credentials.
* `request.user` will be a Django `User` instance. - `request.user` will be a Django `User` instance.
* `request.auth` will be a `rest_framework.authtoken.models.Token` instance. - `request.auth` will be a `rest_framework.authtoken.models.Token` instance.
Unauthenticated responses that are denied permission will result in an `HTTP 401 Unauthorized` response with an appropriate WWW-Authenticate header. For example: Unauthenticated responses that are denied permission will result in an `HTTP 401 Unauthorized` response with an appropriate WWW-Authenticate header. For example:
@ -241,7 +241,6 @@ And in your `urls.py`:
path('api-token-auth/', CustomAuthToken.as_view()) path('api-token-auth/', CustomAuthToken.as_view())
] ]
##### With Django admin ##### With Django admin
It is also possible to create Tokens manually through admin interface. In case you are using a large user base, we recommend that you monkey patch the `TokenAdmin` class to customize it to your needs, more specifically by declaring the `user` field as `raw_field`. It is also possible to create Tokens manually through admin interface. In case you are using a large user base, we recommend that you monkey patch the `TokenAdmin` class to customize it to your needs, more specifically by declaring the `user` field as `raw_field`.
@ -252,7 +251,6 @@ It is also possible to create Tokens manually through admin interface. In case y
TokenAdmin.raw_id_fields = ['user'] TokenAdmin.raw_id_fields = ['user']
#### Using Django manage.py command #### Using Django manage.py command
Since version 3.6.4 it's possible to generate a user token using the following command: Since version 3.6.4 it's possible to generate a user token using the following command:
@ -267,15 +265,14 @@ In case you want to regenerate the token (for example if it has been compromised
./manage.py drf_create_token -r <username> ./manage.py drf_create_token -r <username>
## SessionAuthentication ## SessionAuthentication
This authentication scheme uses Django's default session backend for authentication. Session authentication is appropriate for AJAX clients that are running in the same session context as your website. This authentication scheme uses Django's default session backend for authentication. Session authentication is appropriate for AJAX clients that are running in the same session context as your website.
If successfully authenticated, `SessionAuthentication` provides the following credentials. If successfully authenticated, `SessionAuthentication` provides the following credentials.
* `request.user` will be a Django `User` instance. - `request.user` will be a Django `User` instance.
* `request.auth` will be `None`. - `request.auth` will be `None`.
Unauthenticated responses that are denied permission will result in an `HTTP 403 Forbidden` response. Unauthenticated responses that are denied permission will result in an `HTTP 403 Forbidden` response.
@ -285,7 +282,6 @@ If you're using an AJAX style API with SessionAuthentication, you'll need to mak
CSRF validation in REST framework works slightly differently to standard Django due to the need to support both session and non-session based authentication to the same views. This means that only authenticated requests require CSRF tokens, and anonymous requests may be sent without CSRF tokens. This behaviour is not suitable for login views, which should always have CSRF validation applied. CSRF validation in REST framework works slightly differently to standard Django due to the need to support both session and non-session based authentication to the same views. This means that only authenticated requests require CSRF tokens, and anonymous requests may be sent without CSRF tokens. This behaviour is not suitable for login views, which should always have CSRF validation applied.
## RemoteUserAuthentication ## RemoteUserAuthentication
This authentication scheme allows you to delegate authentication to your web server, which sets the `REMOTE_USER` This authentication scheme allows you to delegate authentication to your web server, which sets the `REMOTE_USER`
@ -298,14 +294,13 @@ already exist. To change this and other behaviour, consult the
If successfully authenticated, `RemoteUserAuthentication` provides the following credentials: If successfully authenticated, `RemoteUserAuthentication` provides the following credentials:
* `request.user` will be a Django `User` instance. - `request.user` will be a Django `User` instance.
* `request.auth` will be `None`. - `request.auth` will be `None`.
Consult your web server's documentation for information about configuring an authentication method, e.g.: Consult your web server's documentation for information about configuring an authentication method, e.g.:
* [Apache Authentication How-To](https://httpd.apache.org/docs/2.4/howto/auth.html) - [Apache Authentication How-To](https://httpd.apache.org/docs/2.4/howto/auth.html)
* [NGINX (Restricting Access)](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/) - [NGINX (Restricting Access)](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/)
# Custom authentication # Custom authentication
@ -315,10 +310,10 @@ In some circumstances instead of returning `None`, you may want to raise an `Aut
Typically the approach you should take is: Typically the approach you should take is:
* If authentication is not attempted, return `None`. Any other authentication schemes also in use will still be checked. - If authentication is not attempted, return `None`. Any other authentication schemes also in use will still be checked.
* If authentication is attempted but fails, raise a `AuthenticationFailed` exception. An error response will be returned immediately, regardless of any permissions checks, and without checking any other authentication schemes. - If authentication is attempted but fails, raise a `AuthenticationFailed` exception. An error response will be returned immediately, regardless of any permissions checks, and without checking any other authentication schemes.
You *may* also override the `.authenticate_header(self, request)` method. If implemented, it should return a string that will be used as the value of the `WWW-Authenticate` header in a `HTTP 401 Unauthorized` response. You _may_ also override the `.authenticate_header(self, request)` method. If implemented, it should return a string that will be used as the value of the `WWW-Authenticate` header in a `HTTP 401 Unauthorized` response.
If the `.authenticate_header()` method is not overridden, the authentication scheme will return `HTTP 403 Forbidden` responses when an unauthenticated request is denied access. If the `.authenticate_header()` method is not overridden, the authentication scheme will return `HTTP 403 Forbidden` responses when an unauthenticated request is denied access.
@ -414,11 +409,10 @@ HTTP Signature (currently a [IETF draft][http-signature-ietf-draft]) provides a
This library provides a set of REST API endpoints for registration, authentication (including social media authentication), password reset, retrieve and update user details, etc. By having these API endpoints, your client apps such as AngularJS, iOS, Android, and others can communicate to your Django backend site independently via REST APIs for user management. This library provides a set of REST API endpoints for registration, authentication (including social media authentication), password reset, retrieve and update user details, etc. By having these API endpoints, your client apps such as AngularJS, iOS, Android, and others can communicate to your Django backend site independently via REST APIs for user management.
There are currently two forks of this project. There are currently two forks of this project.
* [Django-rest-auth][django-rest-auth] is the original project, [but is not currently receiving updates](https://github.com/Tivix/django-rest-auth/issues/568). - [Django-rest-auth][django-rest-auth] is the original project, [but is not currently receiving updates](https://github.com/Tivix/django-rest-auth/issues/568).
* [Dj-rest-auth][dj-rest-auth] is a newer fork of the project. - [Dj-rest-auth][dj-rest-auth] is a newer fork of the project.
## django-rest-framework-social-oauth2 ## django-rest-framework-social-oauth2