Fossil SCM
(Typos) www/json/api-auth.md changes.
Commit
e5f37387ea587fed6b1a3a4c6acff2d865cac532e06de6dfe13da0971d362397
Parent
c050e96381128a8…
1 file changed
+3
-3
+3
-3
| --- www/json-api/api-auth.md | ||
| +++ www/json-api/api-auth.md | ||
| @@ -33,11 +33,11 @@ | ||
| 33 | 33 | purposes, the "auth token" and the "login cookie" are the same thing (or |
| 34 | 34 | serve the same purpose), and the auth token is in fact just the value |
| 35 | 35 | part of the login cookie (which has a project-specific key). |
| 36 | 36 | |
| 37 | 37 | Note that fossil has two conventional user names which can show up in |
| 38 | -various response but do not refer to specific people: nobody and | |
| 38 | +various responses but do not refer to specific people: nobody and | |
| 39 | 39 | anonymous. The nobody user is anyone who is not logged in. The anonymous |
| 40 | 40 | user is logged in but has no persistent user data (no associated user |
| 41 | 41 | name, email address, or similar). Normally the guest (nobody) user has |
| 42 | 42 | more access restrictions. The distinction between the two is largely |
| 43 | 43 | historical - it is a mechanism to keep bots from following the |
| @@ -158,11 +158,11 @@ | ||
| 158 | 158 | tickets is disabled for the guest user then all non-guest users must |
| 159 | 159 | send authentication info in their requests in order to be able to fetch |
| 160 | 160 | ticket info. |
| 161 | 161 | |
| 162 | 162 | Cookie-aware clients should send the login-generated cookie with each |
| 163 | -request, in which case they do not need explicitly include the | |
| 163 | +request, in which case they do not need to explicitly include the | |
| 164 | 164 | `authToken` in the JSON envelope/GET arguments. If submitted, the |
| 165 | 165 | `authToken` is used, otherwise the cookie, if set, is used. Note that |
| 166 | 166 | fossil uses a project-dependent cookie name in order to help thwart |
| 167 | 167 | attacks, so there is no simple mapping of cookie *name* to auth |
| 168 | 168 | token. That said, the cookie's *value* is also the auth token's value. |
| @@ -200,11 +200,11 @@ | ||
| 200 | 200 | |
| 201 | 201 | The password value *may* be time-limited, and *may* eventually become |
| 202 | 202 | invalidated due to old age. This is unspecified. |
| 203 | 203 | |
| 204 | 204 | ***Potential***** (low-probability) bug regarding the seed value:** from |
| 205 | -what i hear, some unusual JSON platforms don't support full 32-bit | |
| 205 | +what I hear, some unusual JSON platforms don't support full 32-bit | |
| 206 | 206 | precision. If absolutely necessary we could chop off a bit or two from |
| 207 | 207 | the seed value (*if* it ever becomes a problem and if DRH blesses it). |
| 208 | 208 | Or we could just make it a double. |
| 209 | 209 | |
| 210 | 210 | |
| 211 | 211 |
| --- www/json-api/api-auth.md | |
| +++ www/json-api/api-auth.md | |
| @@ -33,11 +33,11 @@ | |
| 33 | purposes, the "auth token" and the "login cookie" are the same thing (or |
| 34 | serve the same purpose), and the auth token is in fact just the value |
| 35 | part of the login cookie (which has a project-specific key). |
| 36 | |
| 37 | Note that fossil has two conventional user names which can show up in |
| 38 | various response but do not refer to specific people: nobody and |
| 39 | anonymous. The nobody user is anyone who is not logged in. The anonymous |
| 40 | user is logged in but has no persistent user data (no associated user |
| 41 | name, email address, or similar). Normally the guest (nobody) user has |
| 42 | more access restrictions. The distinction between the two is largely |
| 43 | historical - it is a mechanism to keep bots from following the |
| @@ -158,11 +158,11 @@ | |
| 158 | tickets is disabled for the guest user then all non-guest users must |
| 159 | send authentication info in their requests in order to be able to fetch |
| 160 | ticket info. |
| 161 | |
| 162 | Cookie-aware clients should send the login-generated cookie with each |
| 163 | request, in which case they do not need explicitly include the |
| 164 | `authToken` in the JSON envelope/GET arguments. If submitted, the |
| 165 | `authToken` is used, otherwise the cookie, if set, is used. Note that |
| 166 | fossil uses a project-dependent cookie name in order to help thwart |
| 167 | attacks, so there is no simple mapping of cookie *name* to auth |
| 168 | token. That said, the cookie's *value* is also the auth token's value. |
| @@ -200,11 +200,11 @@ | |
| 200 | |
| 201 | The password value *may* be time-limited, and *may* eventually become |
| 202 | invalidated due to old age. This is unspecified. |
| 203 | |
| 204 | ***Potential***** (low-probability) bug regarding the seed value:** from |
| 205 | what i hear, some unusual JSON platforms don't support full 32-bit |
| 206 | precision. If absolutely necessary we could chop off a bit or two from |
| 207 | the seed value (*if* it ever becomes a problem and if DRH blesses it). |
| 208 | Or we could just make it a double. |
| 209 | |
| 210 | |
| 211 |
| --- www/json-api/api-auth.md | |
| +++ www/json-api/api-auth.md | |
| @@ -33,11 +33,11 @@ | |
| 33 | purposes, the "auth token" and the "login cookie" are the same thing (or |
| 34 | serve the same purpose), and the auth token is in fact just the value |
| 35 | part of the login cookie (which has a project-specific key). |
| 36 | |
| 37 | Note that fossil has two conventional user names which can show up in |
| 38 | various responses but do not refer to specific people: nobody and |
| 39 | anonymous. The nobody user is anyone who is not logged in. The anonymous |
| 40 | user is logged in but has no persistent user data (no associated user |
| 41 | name, email address, or similar). Normally the guest (nobody) user has |
| 42 | more access restrictions. The distinction between the two is largely |
| 43 | historical - it is a mechanism to keep bots from following the |
| @@ -158,11 +158,11 @@ | |
| 158 | tickets is disabled for the guest user then all non-guest users must |
| 159 | send authentication info in their requests in order to be able to fetch |
| 160 | ticket info. |
| 161 | |
| 162 | Cookie-aware clients should send the login-generated cookie with each |
| 163 | request, in which case they do not need to explicitly include the |
| 164 | `authToken` in the JSON envelope/GET arguments. If submitted, the |
| 165 | `authToken` is used, otherwise the cookie, if set, is used. Note that |
| 166 | fossil uses a project-dependent cookie name in order to help thwart |
| 167 | attacks, so there is no simple mapping of cookie *name* to auth |
| 168 | token. That said, the cookie's *value* is also the auth token's value. |
| @@ -200,11 +200,11 @@ | |
| 200 | |
| 201 | The password value *may* be time-limited, and *may* eventually become |
| 202 | invalidated due to old age. This is unspecified. |
| 203 | |
| 204 | ***Potential***** (low-probability) bug regarding the seed value:** from |
| 205 | what I hear, some unusual JSON platforms don't support full 32-bit |
| 206 | precision. If absolutely necessary we could chop off a bit or two from |
| 207 | the seed value (*if* it ever becomes a problem and if DRH blesses it). |
| 208 | Or we could just make it a double. |
| 209 | |
| 210 | |
| 211 |