Minor documentation formatting improvements

Author: Landon Gilbert-Bland

docs/add_custom_data_claims.rst

@@ -1,7 +1,7 @@
 Storing Data in Access Tokens
 =============================
 You may want to store additional information in the access token which you could
-later access in the protected views. This can be done using the `additional_claims`
+later access in the protected views. This can be done using the ``additional_claims``
 argument with the :func:`~flask_jwt_extended.create_access_token` or
 :func:`~flask_jwt_extended.create_refresh_token` functions. The claims
 can be accessed in a protected route via the :func:`~flask_jwt_extended.get_jwt`
@@ -18,8 +18,8 @@ Alternately you can use the :meth:`~flask_jwt_extended.JWTManager.additional_cla
 decorator to register a callback function that will be called whenever a new JWT
 is created, and return a dictionary of claims to add to that token. In the case
 that both :meth:`~flask_jwt_extended.JWTManager.additional_claims_loader` and the
-`additional_claims` argument are used, both results are merged together, with ties
-going to the data suplied by the `additional_claims` argument.
+``additional_claims`` argument are used, both results are merged together, with ties
+going to the data suplied by the ``additional_claims`` argument.
 
 .. code-block:: python
 

docs/automatic_user_loading.rst

@@ -6,10 +6,10 @@ accessing a protected route. We provide a couple callback functions that make
 this seemless while working with JWTs.
 
 The first is :meth:`~flask_jwt_extended.JWTManager.user_identity_loader`, which
-will convert any `User` object used to create a JWT into a JSON serializable format.
+will convert any ``User`` object used to create a JWT into a JSON serializable format.
 
 On the flip side, you can use :meth:`~flask_jwt_extended.JWTManager.user_lookup_loader`
-to automaticallly load your `User` object when a JWT is present in the request.
+to automaticallly load your ``User`` object when a JWT is present in the request.
 The loaded user is available in your protected routes via :attr:`~flask_jwt_extended.current_user`.
 
 Lets see an example of this while utilizing SQLAlchemy to store our users:

docs/blocklist_and_token_revoking.rst

@@ -8,7 +8,7 @@ extension, you must defining a callback function via the
 :meth:`~flask_jwt_extended.JWTManager.token_in_blocklist_loader` decorator.
 This function is called whenever a valid JWT is used to access a protected route.
 The callback will receive the JWT header and JWT payload as arguments, and must
-return `True` if the JWT has been revoked.
+return ``True`` if the JWT has been revoked.
 
 In production, you will want to use some form of persistent storage (database,
 redis, etc) to store your JWTs. It would be bad if your application forgot that

docs/optional_endpoints.rst

@@ -3,7 +3,7 @@ Partially protecting routes
 
 There may be cases where you want to use the same route regardless of if a JWT
 is present in the requst or not. In these situations, you can use
-:func:`~flask_jwt_extended.jwt_required` with the `optional=True` argument. This
+:func:`~flask_jwt_extended.jwt_required` with the ``optional=True`` argument. This
 will allow the endpoint to be accessed regardless of if a JWT is sent in with
 the request.
 

docs/refreshing_tokens.rst

@@ -58,12 +58,12 @@ an access token. Here is an example using `HTTPie <https://httpie.io/>`_.
 Token Freshness Pattern
 ~~~~~~~~~~~~~~~~~~~~~~~
 The token freshness pattern is a very simple idea. Every time a user authenticates
-by providing a username and password, they receive a `fresh` access token that
+by providing a username and password, they receive a ``fresh`` access token that
 can access any route. But after some time, that token should no longer be considered
-`fresh`, and some critical or dangerous routes will be blocked until the user
+``fresh``, and some critical or dangerous routes will be blocked until the user
 verifies their password again. All other routes will still work normally for
-the user even though their token is no longer `fresh`. As an example, we might
-not allow users to change their email address unless they have a `fresh` token,
+the user even though their token is no longer ``fresh``. As an example, we might
+not allow users to change their email address unless they have a ``fresh`` token,
 but we do allow them use the rest of our Flask application normally.
 
 The token freshness pattern is built into this extension, and works seamlessly
@@ -74,7 +74,7 @@ refresh example).
 .. literalinclude:: ../examples/token_freshness.py
 
 We also support marking a token as fresh for a given amount of time after it
-is created. You can do this by passing a `datetime.timedelta` to the `fresh`
+is created. You can do this by passing a ``datetime.timedelta`` to the ``fresh``
 option when creating JWTs:
 
 .. code-block :: python

docs/token_locations.rst

@@ -1,9 +1,9 @@
 JWT Locations
 =============
 JWTs can be sent in with a request in many different ways. You can control which
-ways you want to accept JWTs in your Flask application via the `JWT_TOKEN_LOCATION`
+ways you want to accept JWTs in your Flask application via the ``JWT_TOKEN_LOCATION``
 :ref:`configuration option<Configuration Options>`. You can also override that global
-configuration on a per route basis via the `locations` argument in
+configuration on a per route basis via the ``locations`` argument in
 :func:`~flask_jwt_extended.jwt_required`.
 
 .. literalinclude:: ../examples/jwt_locations.py
@@ -70,7 +70,7 @@ token. This cookie is set as http-only, so that it cannot be access via javascri
 (this is what prevents XSS attacks from being able to steal the JWT). The second
 cookie we set contains only the same double submit token, but this time in a
 cookie that is readable by javascript. Whenever a request is made, it needs to
-include an `X-CSRF-TOKEN` header, with the value of the double submit token.
+include an ``X-CSRF-TOKEN`` header, with the value of the double submit token.
 If the value in this header does not match the value stored in the JWT, the
 request is kicked out as invalid.
 
@@ -80,7 +80,7 @@ different domain will not be able to read the cookie containing the double submi
 token on your website, we have successfully thwarted any CSRF attacks.
 
 This does mean that whenever you are making a request, you need to manually
-include the `X-CSRF-TOKEN` header, otherwise your requests will be kicked
+include the ``X-CSRF-TOKEN`` header, otherwise your requests will be kicked
 out as invalid too. Lets look at how to do that:
 
 .. code-block :: javascript