docs: fix typos

CHANGELOG.rst

@@ -146,7 +146,7 @@ OAuth1.0 Client:
 General fixes:
 
 * $ and ' are allowed to be unencoded in query strings #564
-* Request attributes are no longer overriden by HTTP Headers #409
+* Request attributes are no longer overridden by HTTP Headers #409
 * Removed unnecessary code for handling python2.6
 * Add support of python3.7 #621
 * Several minors updates to setup.py and tox
@@ -204,7 +204,7 @@ General fixes:
 * Added log statements to except clauses.
 * According to RC7009 Section 2.1, a client should include authentication credentials when revoking its tokens.
   As discussed in #339, this is not make sense for public clients.
-  However, in that case, the public client should still be checked that is infact a public client (authenticate_client_id).
+  However, in that case, the public client should still be checked that is in fact a public client (authenticate_client_id).
 * Improved prompt parameter validation.
 * Added two error codes from RFC 6750.
 * Hybrid response types are now be fragment-encoded.
@@ -354,7 +354,7 @@ Quick fix. OAuth 1 client repr in 0.6.2 overwrote secrets when scrubbing for pri
 Draft revocation endpoint features and numerous fixes including:
 
 * (OAuth 2 Provider) is_within_original_scope to check whether a refresh token
-  is trying to aquire a new set of scopes that are a subset of the original scope.
+  is trying to acquire a new set of scopes that are a subset of the original scope.
 
 * (OAuth 2 Provider) expires_in token lifetime can be set per request.
 

README.rst

@@ -103,7 +103,7 @@ busy and therefore slow to reply but we love feedback!
 
 Chances are you have run into something annoying that you wish there was
 documentation for, if you wish to gain eternal fame and glory, and a drink if we
-have the pleasure to run into eachother, please send a docs pull request =)
+have the pleasure to run into each other, please send a docs pull request =)
 
 .. _`Gitter community`: https://gitter.im/oauthlib/Lobby
 

docs/contributing.rst

@@ -292,7 +292,7 @@ Consolidated example
 		:param client: User's defined Client object, see ``.authenticate_client``.
 		:param bar: Another example.
 		:param key: Another param.
-		:return: Explaination of return value and type
+		:return: Explanation of return value and type
 
 		.. _`MAC Access Authentication`: https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01
 		"""

docs/faq.rst

@@ -48,7 +48,7 @@ What does ValueError `Error trying to decode a non urlencoded string` mean?
     include non percent encoded characters such as `£`. Which could be because
     it has already been decoded by your web framework. 
 
-    If you believe it contains characters that should be excempt from this
+    If you believe it contains characters that should be exempt from this
     check please open an issue and state why.
 
 

docs/oauth1/security.rst

@@ -5,7 +5,7 @@ A few important facts regarding OAuth security
         SSL for all interactions both with your API as well as for setting up
         tokens. An example of when it's especially bad is when sending POST
         requests with form data, this data is not accounted for in the OAuth
-        signature and a successfull man-in-the-middle attacker could swap your
+        signature and a successful man-in-the-middle attacker could swap your
         form data (or files) to whatever he pleases without invalidating the
         signature. This is an even bigger issue if you fail to check
         nonce/timestamp pairs for each request, allowing an attacker who

docs/oauth1/server.rst

@@ -59,7 +59,7 @@ The client interested in accessing protected resources.
 
 **Client secret**:
     Required for HMAC-SHA1 and PLAINTEXT. The secret the client will use when
-    verifying requests during the OAuth workflow. Has to be accesible as
+    verifying requests during the OAuth workflow. Has to be accessible as
     plaintext (i.e. not hashed) since it is used to recreate and validate
     request signatured::
 
@@ -175,7 +175,7 @@ you should consider expiring them as it increases security dramatically.
 The user and realms will need to be transferred from the request token to the
 access token. It is possible that the list of authorized realms is smaller
 than the list of requested realms. Clients can observe whether this is the case
-by comparing the `oauth_realms` parameter given in the token reponse. This way
+by comparing the `oauth_realms` parameter given in the token response. This way
 of indicating change of realms is backported from OAuth2 scope behaviour and is
 not in the OAuth 1 spec.
 

docs/oauth2/endpoints/endpoints.rst

@@ -3,7 +3,7 @@ Provider Endpoints
 
 Endpoints in OAuth 2 are targets with a specific responsibility and often
 associated with a particular URL. Because of this the word endpoint might be
-used interchangably from the endpoint url.
+used interchangeably from the endpoint url.
 
 The main three responsibilities in an OAuth 2 flow is to authorize access to a
 certain users resources to a client, to supply said client with a token

docs/oauth2/endpoints/resource.rst

@@ -5,7 +5,7 @@ Resource authorization
 Resource endpoints verify that the token presented is valid and granted access
 to the scopes associated with the resource in question.
 
-**Request Verfication**
+**Request Verification**
     Each view may set certain scopes under which it is bound. Only requests
     that present an access token bound to the correct scopes may access the
     view. Access tokens are commonly embedded in the authorization header but

docs/oauth2/grants/custom_validators.rst

@@ -3,7 +3,7 @@ Custom Validators
 
 The Custom validators are useful when you want to change a particular
 behavior of an existing grant. That is often needed because of the
-diversity of the identity softwares and to let the oauthlib framework to be
+diversity of the identity software and to let the oauthlib framework to be
 flexible as possible.
 
 However, if you are looking into writing a custom grant type, please

docs/oauth2/tokens/bearer.rst

@@ -79,7 +79,7 @@ And you will find all claims in its decoded form:
 Sometime you may want to generate custom `access_token` with a reference from a
 database (as text) or use a HASH signature in JWT or use JWE (encrypted content).
 
-Also, note that you can declare the generate function in your instanciated
+Also, note that you can declare the generate function in your instantiated
 validator to benefit of the `self` variables.
 
 See the example below:

oauthlib/oauth1/rfc5849/endpoints/request_token.py

@@ -152,7 +152,7 @@ def validate_request_token_request(self, request):
             request.client_key = self.request_validator.dummy_client
 
         # Note that `realm`_ is only used in authorization headers and how
-        # it should be interepreted is not included in the OAuth spec.
+        # it should be interpreted is not included in the OAuth spec.
         # However they could be seen as a scope or realm to which the
         # client has access and as such every client should be checked
         # to ensure it is authorized access to that scope or realm.
@@ -164,7 +164,7 @@ def validate_request_token_request(self, request):
         # workflow where a client requests access to a specific realm.
         # This first step (obtaining request token) need not require a realm
         # and can then be identified by checking the require_resource_owner
-        # flag and abscence of realm.
+        # flag and absence of realm.
         #
         # Clients obtaining an access token will not supply a realm and it will
         # not be checked. Instead the previously requested realm should be

oauthlib/oauth1/rfc5849/endpoints/resource.py

@@ -113,7 +113,7 @@ def validate_protected_resource_request(self, uri, http_method='GET',
             request.resource_owner_key = self.request_validator.dummy_access_token
 
         # Note that `realm`_ is only used in authorization headers and how
-        # it should be interepreted is not included in the OAuth spec.
+        # it should be interpreted is not included in the OAuth spec.
         # However they could be seen as a scope or realm to which the
         # client has access and as such every client should be checked
         # to ensure it is authorized access to that scope or realm.
@@ -125,7 +125,7 @@ def validate_protected_resource_request(self, uri, http_method='GET',
         # workflow where a client requests access to a specific realm.
         # This first step (obtaining request token) need not require a realm
         # and can then be identified by checking the require_resource_owner
-        # flag and abscence of realm.
+        # flag and absence of realm.
         #
         # Clients obtaining an access token will not supply a realm and it will
         # not be checked. Instead the previously requested realm should be

oauthlib/oauth1/rfc5849/request_validator.py

@@ -19,7 +19,7 @@ class RequestValidator:
     Methods used to check the format of input parameters. Common tests include
     length, character set, membership, range or pattern. These tests are
     referred to as `whitelisting or blacklisting`_. Whitelisting is better
-    but blacklisting can be usefull to spot malicious activity.
+    but blacklisting can be useful to spot malicious activity.
     The following have methods a default implementation:
 
     - check_client_key

oauthlib/oauth2/rfc6749/clients/base.py

@@ -267,7 +267,7 @@ def prepare_token_request(self, token_url, authorization_response=None,
 
         :param token_url: Provider token creation endpoint URL.
         :param authorization_response: The full redirection URL string, i.e.
-            the location to which the user was redirected after successfull
+            the location to which the user was redirected after successful
             authorization. Used to mine credentials needed to obtain a token
             in this step, such as authorization code.
         :param redirect_url: The redirect_url supplied with the authorization

oauthlib/oauth2/rfc6749/clients/mobile_application.py

@@ -55,7 +55,7 @@ def prepare_request_uri(self, uri, redirect_uri=None, scope=None,
         using the "application/x-www-form-urlencoded" format, per `Appendix B`_:
 
         :param redirect_uri:  OPTIONAL. The redirect URI must be an absolute URI
-                              and it should have been registerd with the OAuth
+                              and it should have been registered with the OAuth
                               provider prior to use. As described in `Section 3.1.2`_.
 
         :param scope:  OPTIONAL. The scope of the access request as described by

oauthlib/oauth2/rfc6749/clients/service_application.py

@@ -31,7 +31,7 @@ class ServiceApplicationClient(Client):
 
     def __init__(self, client_id, private_key=None, subject=None, issuer=None,
                  audience=None, **kwargs):
-        """Initalize a JWT client with defaults for implicit use later.
+        """Initialize a JWT client with defaults for implicit use later.
 
         :param client_id: Client identifier given by the OAuth provider upon
                           registration.

oauthlib/oauth2/rfc6749/clients/web_application.py

@@ -49,7 +49,7 @@ def prepare_request_uri(self, uri, redirect_uri=None, scope=None,
         using the "application/x-www-form-urlencoded" format, per `Appendix B`_:
 
         :param redirect_uri:  OPTIONAL. The redirect URI must be an absolute URI
-                              and it should have been registerd with the OAuth
+                              and it should have been registered with the OAuth
                               provider prior to use. As described in `Section 3.1.2`_.
 
         :param scope:  OPTIONAL. The scope of the access request as described by

oauthlib/oauth2/rfc6749/endpoints/revocation.py

@@ -95,7 +95,7 @@ def validate_revocation_request(self, request):
         submitted for revocation.  Clients MAY pass this parameter in order to
         help the authorization server to optimize the token lookup.  If the
         server is unable to locate the token using the given hint, it MUST
-        extend its search accross all of its supported token types.  An
+        extend its search across all of its supported token types.  An
         authorization server MAY ignore this parameter, particularly if it is
         able to detect the token type automatically.  This specification
         defines two such values:

oauthlib/oauth2/rfc6749/request_validator.py

@@ -208,7 +208,7 @@ def introspect_token(self, token, token_type_hint, request, *args, **kwargs):
         can be found in `Introspect Claims`_ or `JWT Claims`_.
 
         The implementation can use *token_type_hint* to improve lookup
-        efficency, but must fallback to other types to be compliant with RFC.
+        efficiency, but must fallback to other types to be compliant with RFC.
 
         The dict of claims is added to request.token after this method.
 
@@ -564,7 +564,7 @@ def validate_user(self, username, password, client, request, *args, **kwargs):
         OBS! The validation should also set the user attribute of the request
         to a valid resource owner, i.e. request.user = username or similar. If
         not set you will be unable to associate a token with a user in the
-        persistance method used (commonly, save_bearer_token).
+        persistence method used (commonly, save_bearer_token).
 
         :param username: Unicode username.
         :param password: Unicode password.

tox.ini

@@ -8,7 +8,7 @@ commands=
     pytest --cov=oauthlib tests/
 
 
-# tox -e docs to mimick readthedocs build.
+# tox -e docs to mimic readthedocs build.
 # as of today, RTD is using python3.7 and doesn't run "setup.py install"
 [testenv:docs]
 basepython=python3.7
@@ -20,7 +20,7 @@ changedir=docs
 whitelist_externals=make
 commands=make clean html
 
-# tox -e readme to mimick PyPI long_description check
+# tox -e readme to mimic PyPI long_description check
 [testenv:readme]
 basepython=python3.8
 deps=twine>=1.12.0