diff options
25 files changed, 39 insertions, 39 deletions
diff --git a/CHANGELOG.rst b/CHANGELOG.rst index d7882e9..a295568 100644 --- a/CHANGELOG.rst +++ b/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. @@ -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 diff --git a/docs/contributing.rst b/docs/contributing.rst index 5f05331..19ff9c9 100644 --- a/docs/contributing.rst +++ b/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 """ diff --git a/docs/faq.rst b/docs/faq.rst index 4814dcd..e47e3e0 100644 --- a/docs/faq.rst +++ b/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. diff --git a/docs/oauth1/security.rst b/docs/oauth1/security.rst index df1e2a0..d8b7d6b 100644 --- a/docs/oauth1/security.rst +++ b/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 @@ -20,7 +20,7 @@ A few important facts regarding OAuth security for Python 3.6 and later. The ``secrets`` module is designed for generating cryptographically strong random numbers. For earlier versions of Python, use ``random.SystemRandom`` which is based on ``os.urandom`` - rather than the default ``random`` based on the effecient but not truly + rather than the default ``random`` based on the efficient but not truly random Mersenne Twister. Predictable tokens allow attackers to bypass virtually all defences OAuth provides. diff --git a/docs/oauth1/server.rst b/docs/oauth1/server.rst index 2f30c65..2c01ab7 100644 --- a/docs/oauth1/server.rst +++ b/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. diff --git a/docs/oauth2/endpoints/endpoints.rst b/docs/oauth2/endpoints/endpoints.rst index 0dd2da0..f05c44b 100644 --- a/docs/oauth2/endpoints/endpoints.rst +++ b/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 diff --git a/docs/oauth2/endpoints/resource.rst b/docs/oauth2/endpoints/resource.rst index a5ff885..6bd4d6b 100644 --- a/docs/oauth2/endpoints/resource.rst +++ b/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 diff --git a/docs/oauth2/grants/custom_grant.rst b/docs/oauth2/grants/custom_grant.rst index 8c4571c..c639420 100644 --- a/docs/oauth2/grants/custom_grant.rst +++ b/docs/oauth2/grants/custom_grant.rst @@ -37,7 +37,7 @@ existing ones. 3. Associate it with Endpoints ------------------------------ -Then, once implemented, you have to instanciate the grant object and +Then, once implemented, you have to instantiate the grant object and bind it to your endpoint. Either :py:class:`AuthorizationEndpoint`, :py:class:`TokenEndpoint` or both. @@ -48,7 +48,7 @@ This example shows how to add a simple extension to the `Token endpoint`: * creation of a new class ``MyCustomGrant``, and implement ``create_token_response``. * do basics and custom request validations, then call a custom method of `Request Validator` to extend the interface for the implementor. -* instanciate the new grant, and bind it with an existing ``Server``. +* instantiate the new grant, and bind it with an existing ``Server``. .. code-block:: python diff --git a/docs/oauth2/grants/custom_validators.rst b/docs/oauth2/grants/custom_validators.rst index 9917dd7..f295e53 100644 --- a/docs/oauth2/grants/custom_validators.rst +++ b/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 diff --git a/docs/oauth2/tokens/bearer.rst b/docs/oauth2/tokens/bearer.rst index 0776db8..c23efab 100644 --- a/docs/oauth2/tokens/bearer.rst +++ b/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: diff --git a/oauthlib/oauth1/rfc5849/endpoints/request_token.py b/oauthlib/oauth1/rfc5849/endpoints/request_token.py index bb67e71..0323cfb 100644 --- a/oauthlib/oauth1/rfc5849/endpoints/request_token.py +++ b/oauthlib/oauth1/rfc5849/endpoints/request_token.py @@ -152,7 +152,7 @@ class RequestTokenEndpoint(BaseEndpoint): 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 @@ class RequestTokenEndpoint(BaseEndpoint): # 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 diff --git a/oauthlib/oauth1/rfc5849/endpoints/resource.py b/oauthlib/oauth1/rfc5849/endpoints/resource.py index 45bdaaa..8641152 100644 --- a/oauthlib/oauth1/rfc5849/endpoints/resource.py +++ b/oauthlib/oauth1/rfc5849/endpoints/resource.py @@ -113,7 +113,7 @@ class ResourceEndpoint(BaseEndpoint): 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 @@ class ResourceEndpoint(BaseEndpoint): # 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 diff --git a/oauthlib/oauth1/rfc5849/request_validator.py b/oauthlib/oauth1/rfc5849/request_validator.py index d8e4ee4..e937aab 100644 --- a/oauthlib/oauth1/rfc5849/request_validator.py +++ b/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 diff --git a/oauthlib/oauth2/rfc6749/clients/backend_application.py b/oauthlib/oauth2/rfc6749/clients/backend_application.py index 0e2a829..e11e8fa 100644 --- a/oauthlib/oauth2/rfc6749/clients/backend_application.py +++ b/oauthlib/oauth2/rfc6749/clients/backend_application.py @@ -39,7 +39,7 @@ class BackendApplicationClient(Client): format per `Appendix B`_ in the HTTP request entity-body: :param body: Existing request body (URL encoded string) to embed parameters - into. This may contain extra paramters. Default ''. + into. This may contain extra parameters. Default ''. :param scope: The scope of the access request as described by `Section 3.3`_. diff --git a/oauthlib/oauth2/rfc6749/clients/base.py b/oauthlib/oauth2/rfc6749/clients/base.py index 0dbf1c0..d5eb0cc 100644 --- a/oauthlib/oauth2/rfc6749/clients/base.py +++ b/oauthlib/oauth2/rfc6749/clients/base.py @@ -267,14 +267,14 @@ class Client: :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 request (if there was one). :param state: :param body: Existing request body (URL encoded string) to embed parameters - into. This may contain extra paramters. Default ''. + into. This may contain extra parameters. Default ''. :param kwargs: Additional parameters to included in the request. :returns: The prepared request tuple with (url, headers, body). """ @@ -303,7 +303,7 @@ class Client: :param token_url: Provider token refresh endpoint URL. :param refresh_token: Refresh token string. :param body: Existing request body (URL encoded string) to embed parameters - into. This may contain extra paramters. Default ''. + into. This may contain extra parameters. Default ''. :param scope: List of scopes to request. Must be equal to or a subset of the scopes granted when obtaining the refresh token. If none is provided, the ones provided in the constructor are diff --git a/oauthlib/oauth2/rfc6749/clients/legacy_application.py b/oauthlib/oauth2/rfc6749/clients/legacy_application.py index 7af68f3..9920981 100644 --- a/oauthlib/oauth2/rfc6749/clients/legacy_application.py +++ b/oauthlib/oauth2/rfc6749/clients/legacy_application.py @@ -49,7 +49,7 @@ class LegacyApplicationClient(Client): :param username: The resource owner username. :param password: The resource owner password. :param body: Existing request body (URL encoded string) to embed parameters - into. This may contain extra paramters. Default ''. + into. This may contain extra parameters. Default ''. :param scope: The scope of the access request as described by `Section 3.3`_. :param include_client_id: `True` to send the `client_id` in the diff --git a/oauthlib/oauth2/rfc6749/clients/mobile_application.py b/oauthlib/oauth2/rfc6749/clients/mobile_application.py index cd325f4..b10b41c 100644 --- a/oauthlib/oauth2/rfc6749/clients/mobile_application.py +++ b/oauthlib/oauth2/rfc6749/clients/mobile_application.py @@ -55,7 +55,7 @@ class MobileApplicationClient(Client): 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 diff --git a/oauthlib/oauth2/rfc6749/clients/service_application.py b/oauthlib/oauth2/rfc6749/clients/service_application.py index c751c8b..8fb1737 100644 --- a/oauthlib/oauth2/rfc6749/clients/service_application.py +++ b/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. @@ -99,7 +99,7 @@ class ServiceApplicationClient(Client): :param extra_claims: A dict of additional claims to include in the JWT. :param body: Existing request body (URL encoded string) to embed parameters - into. This may contain extra paramters. Default ''. + into. This may contain extra parameters. Default ''. :param scope: The scope of the access request. diff --git a/oauthlib/oauth2/rfc6749/clients/web_application.py b/oauthlib/oauth2/rfc6749/clients/web_application.py index 1d3b2b5..50890fb 100644 --- a/oauthlib/oauth2/rfc6749/clients/web_application.py +++ b/oauthlib/oauth2/rfc6749/clients/web_application.py @@ -49,7 +49,7 @@ class WebApplicationClient(Client): 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 @@ -117,7 +117,7 @@ class WebApplicationClient(Client): values MUST be identical. :param body: Existing request body (URL encoded string) to embed parameters - into. This may contain extra paramters. Default ''. + into. This may contain extra parameters. Default ''. :param include_client_id: `True` (default) to send the `client_id` in the body of the upstream request. This is required diff --git a/oauthlib/oauth2/rfc6749/endpoints/revocation.py b/oauthlib/oauth2/rfc6749/endpoints/revocation.py index 4aa5ec6..596d086 100644 --- a/oauthlib/oauth2/rfc6749/endpoints/revocation.py +++ b/oauthlib/oauth2/rfc6749/endpoints/revocation.py @@ -42,7 +42,7 @@ class RevocationEndpoint(BaseEndpoint): The authorization server responds with HTTP status code 200 if the - token has been revoked sucessfully or if the client submitted an + token has been revoked successfully or if the client submitted an invalid token. Note: invalid tokens do not cause an error response since the client @@ -95,7 +95,7 @@ class RevocationEndpoint(BaseEndpoint): 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: diff --git a/oauthlib/oauth2/rfc6749/parameters.py b/oauthlib/oauth2/rfc6749/parameters.py index 44738bb..8f6ce2c 100644 --- a/oauthlib/oauth2/rfc6749/parameters.py +++ b/oauthlib/oauth2/rfc6749/parameters.py @@ -45,7 +45,7 @@ def prepare_grant_uri(uri, client_id, response_type, redirect_uri=None, back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in `Section 10.12`_. - :param code_challenge: PKCE paramater. A challenge derived from the + :param code_challenge: PKCE parameter. A challenge derived from the code_verifier that is sent in the authorization request, to be verified against later. :param code_challenge_method: PKCE parameter. A method that was used to derive the diff --git a/oauthlib/oauth2/rfc6749/request_validator.py b/oauthlib/oauth2/rfc6749/request_validator.py index c047445..3910c0b 100644 --- a/oauthlib/oauth2/rfc6749/request_validator.py +++ b/oauthlib/oauth2/rfc6749/request_validator.py @@ -208,7 +208,7 @@ class RequestValidator: 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 @@ class RequestValidator: 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. diff --git a/oauthlib/openid/connect/core/grant_types/dispatchers.py b/oauthlib/openid/connect/core/grant_types/dispatchers.py index 2734c38..5aa7d46 100644 --- a/oauthlib/openid/connect/core/grant_types/dispatchers.py +++ b/oauthlib/openid/connect/core/grant_types/dispatchers.py @@ -84,7 +84,7 @@ class AuthorizationTokenGrantDispatcher(Dispatcher): code = parameters.get('code', None) redirect_uri = parameters.get('redirect_uri', None) - # If code is not pressent fallback to `default_grant` which will + # If code is not present fallback to `default_grant` which will # raise an error for the missing `code` in `create_token_response` step. if code: scopes = self.request_validator.get_authorization_code_scopes(client_id, code, redirect_uri, request) @@ -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 |