Browse Source

Don't capitalize Token in docs

These uses aren't proper nouns.

Change-Id: If1b217a32970a7bf06e7b7deaf53667d51190e37
tags/3.10.0^2
James E. Blair 1 week ago
parent
commit
fce1798e77
2 changed files with 18 additions and 18 deletions
  1. 12
    12
      doc/source/admin/tenant-scoped-rest-api.rst
  2. 6
    6
      doc/source/admin/tenants.rst

+ 12
- 12
doc/source/admin/tenant-scoped-rest-api.rst View File

@@ -19,21 +19,21 @@ JWT standard as established in this `RFC <https://tools.ietf.org/html/rfc7519>`_
19 19
 Important Security Considerations
20 20
 ---------------------------------
21 21
 
22
-Anybody with a valid Token can perform privileged actions exposed
23
-through the REST API. Furthermore revoking Tokens, especially when manually
22
+Anybody with a valid token can perform privileged actions exposed
23
+through the REST API. Furthermore revoking tokens, especially when manually
24 24
 issued, is not trivial.
25 25
 
26
-As a mitigation, Tokens should be generated with a short time to
27
-live, like 10 minutes or less. If the Token contains authorization Information
26
+As a mitigation, tokens should be generated with a short time to
27
+live, like 10 minutes or less. If the token contains authorization Information
28 28
 (see the ``zuul.admin`` claim below), it should be generated with as little a scope
29 29
 as possible (one tenant only) to reduce the surface of attack should the
30
-Token be compromised.
30
+token be compromised.
31 31
 
32 32
 Exposing administration tasks can impact build results (dequeue-ing buildsets),
33 33
 and pose potential resources problems with Nodepool if the ``autohold`` feature
34 34
 is abused, leading to a significant number of nodes remaining in "hold" state for
35 35
 extended periods of time. As always, "with great power comes great responsibility"
36
-and Tokens should be handed over with discernment.
36
+and tokens should be handed over with discernment.
37 37
 
38 38
 Configuration
39 39
 -------------
@@ -60,8 +60,8 @@ authenticator similar to this one:
60 60
     secret=exampleSecret
61 61
 
62 62
 With such an authenticator, a Zuul operator can use Zuul's CLI to
63
-issue Tokens overriding a tenant's access rules if need
64
-be. A user can then use these Tokens with Zuul's CLI to perform protected actions
63
+issue tokens overriding a tenant's access rules if need
64
+be. A user can then use these tokens with Zuul's CLI to perform protected actions
65 65
 on a tenant temporarily, without having to modify a tenant's access rules.
66 66
 
67 67
 .. _jwt-format:
@@ -81,12 +81,12 @@ Zuul can consume JWTs with the following minimal set of claims:
81 81
    'sub': 'alice'
82 82
   }
83 83
 
84
-* **iss** is the issuer of the Token. It can be used to filter
84
+* **iss** is the issuer of the token. It can be used to filter
85 85
   Identity Providers.
86 86
 * **aud**, as the intended audience, is usually the client id as registered on
87 87
   the Identity Provider.
88
-* **exp** is the Token's expiry timestamp.
89
-* **iat** is the Token's date of issuance timestamp.
88
+* **exp** is the token's expiry timestamp.
89
+* **iat** is the token's date of issuance timestamp.
90 90
 * **sub** is the default, unique identifier of the user.
91 91
 
92 92
 JWTs can be extended arbitrarily with other claims. Zuul however can look for a
@@ -101,7 +101,7 @@ in the authenticator's configuration. This claim has the following format:
101 101
     }
102 102
   }
103 103
 
104
-The **admin** field is a list of tenants on which the Token's bearer is granted
104
+The **admin** field is a list of tenants on which the token's bearer is granted
105 105
 the right to perform privileged actions.
106 106
 
107 107
 Manually Generating a JWT

+ 6
- 6
doc/source/admin/tenants.rst View File

@@ -343,7 +343,7 @@ or **dequeue**.
343 343
 
344 344
 .. note::
345 345
 
346
-   Rules can be overridden by the ``zuul.admin`` claim in a Token if if matches
346
+   Rules can be overridden by the ``zuul.admin`` claim in a token if if matches
347 347
    an authenticator configuration where `allow_authz_override` is set to true.
348 348
    See :ref:`Zuul web server's configuration <web-server-tenant-scoped-api>` for
349 349
    more details.
@@ -381,10 +381,10 @@ Below are some examples of how access rules can be defined:
381 381
       This is the list of conditions that define a rule. A JWT must match **at
382 382
       least one** of the conditions for the rule to apply. A condition is a
383 383
       dictionary where keys are claims. **All** the associated values must
384
-      match the claims in the user's Token.
384
+      match the claims in the user's token.
385 385
 
386 386
       Zuul's authorization engine will adapt matching tests depending on the
387
-      nature of the claim in the Token, eg:
387
+      nature of the claim in the token, eg:
388 388
 
389 389
       * if the claim is a JSON list, check that the condition value is in the
390 390
         claim
@@ -396,10 +396,10 @@ Below are some examples of how access rules can be defined:
396 396
 
397 397
         The special ``zuul_uid`` claim refers to the ``uid_claim`` setting in an
398 398
         authenticator's configuration. By default it refers to the ``sub`` claim
399
-        of a Token. For more details see the :ref:`configuration section
399
+        of a token. For more details see the :ref:`configuration section
400 400
         <web-server-tenant-scoped-api>` for Zuul web server.
401 401
 
402
-        Under the above example, the following Token would match rules
402
+        Under the above example, the following token would match rules
403 403
         ``affiliate_or_admin`` and ``alice_or_bob``:
404 404
 
405 405
         .. code-block:: javascript
@@ -417,7 +417,7 @@ Below are some examples of how access rules can be defined:
417 417
            },
418 418
           }
419 419
 
420
-        And this Token would only match rule ``affiliate_or_admin``:
420
+        And this token would only match rule ``affiliate_or_admin``:
421 421
 
422 422
         .. code-block:: javascript
423 423
 

Loading…
Cancel
Save