Fossil: Diff

Differences From Artifact [9f182349c9]:

File www/password.wiki — part of check-in [2572e48b93] at 2024-01-27 15:11:04 on branch inskinerator-modern-backport — Removed redundant h1 tags in wiki docs, duplicating "title" elements that already display in the skin's header area. They take up vertical space without adding any new information. (user: wyoung size: 6765)

To Artifact [54f05c9321]:

File www/password.wiki — part of check-in [54977e1413] at 2024-02-04 04:29:29 on branch inskinerator-modern-backport — Replaced nearly all explicit uses of the "blockquote" tag in the embedded docs:
- Constructs like "<blockquote><pre>" are now simply "<pre>"
- Ditto "<blockquote><b>" for command examples, which then allowed me to get rid of explicit "br" elements; pre does that for us.
- Where it was used merely to get an indent for a code block, we're now using pre or verbatim instead, depending on whether we need embedded HTML and/or pre-wrap handling. (Not the same thing as the prior item.) In some places, this let us replace use of HTML-escaped code blocks in pre with verbatim equivalents, not needing the escaping, allownig the doc source to read more like the rendered HTML.
- Use of blockquotes to get hierarchical indenting is no longer necessary; the skin does that. A good example is indenting ol and ul lists under the parent paragraph; additional manual indenting is no longer necessary.
The only remaining instances of "blockquote" under www/ are necessary:
1. The copyright release doc is plain HTML, without the fossil-doc wrapper, giving it no access to the new skin improvements.
2. One MD doc wants a blockquote in the middle of a list, and the current parsing rules don't let us use ">" there.
3. The skinning docs talk about styling blockquote elements at one point; it isn't a use of the tag, it is a prose reference to it.
(user: wyoung size: 6651) [more...]

︙			︙
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60	The SHA1 hash in the USER.PW field is a hash of a string composed of the project-code, the user login, and the user cleartext password. Suppose user "alice" with password "asdfg" had an account on the Fossil self-hosting repository. Then the value of USER.PW for alice would be the SHA1 hash of ~~<~~blockquot~~e>~~ CE59BB9F186226D80E49D1FA2DB29F935CCA0333/alice/asdfg ~~</~~blockquot~~e>~~ Note that by including the project-code and the login as part of the hash, a different USER.PW value results even if two or more users on the repository select the same "asdfg" password or if user alice reuses the same password on multiple projects. Whenever a password is changed using the web interface or using the "user" command-line method, the new password is stored using the SHA1 encoding. Thus, cleartext passwords will gradually migrate to become SHA1 passwords. All remaining cleartext passwords can be converted to SHA1 passwords using the following command: ~~~~<blockquote>~~<pre>~~ fossil test-hash-passwords <i>REPOSITORY-NAME</i> ~~</pre>~~</blockquote>~~~~ Remember that converting from cleartext to SHA1 passwords is an irreversible operation. The only way to insert a new cleartext password into the USER table is to do so manually using SQL commands. For example: ~~~~<blockquote>~~<pre>~~ UPDATE user SET pw='asdfg' WHERE login='alice'; ~~</pre>~~</blockquote>~~~~ Note that an password that is an empty string or NULL will disable all login for that user. Thus, to lock a user out of the system, one has only to set their password to an empty string, using either the web interface or direct SQL manipulation of the USER table. Note also that the password field is essentially ignored for the special users named "anonymous", "developer",	\| \| \| \| \| \|	19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60	The SHA1 hash in the USER.PW field is a hash of a string composed of the project-code, the user login, and the user cleartext password. Suppose user "alice" with password "asdfg" had an account on the Fossil self-hosting repository. Then the value of USER.PW for alice would be the SHA1 hash of <pre> CE59BB9F186226D80E49D1FA2DB29F935CCA0333/alice/asdfg </pre> Note that by including the project-code and the login as part of the hash, a different USER.PW value results even if two or more users on the repository select the same "asdfg" password or if user alice reuses the same password on multiple projects. Whenever a password is changed using the web interface or using the "user" command-line method, the new password is stored using the SHA1 encoding. Thus, cleartext passwords will gradually migrate to become SHA1 passwords. All remaining cleartext passwords can be converted to SHA1 passwords using the following command: <pre> fossil test-hash-passwords <i>REPOSITORY-NAME</i> </pre> Remember that converting from cleartext to SHA1 passwords is an irreversible operation. The only way to insert a new cleartext password into the USER table is to do so manually using SQL commands. For example: <pre> UPDATE user SET pw='asdfg' WHERE login='alice'; </pre> Note that an password that is an empty string or NULL will disable all login for that user. Thus, to lock a user out of the system, one has only to set their password to an empty string, using either the web interface or direct SQL manipulation of the USER table. Note also that the password field is essentially ignored for the special users named "anonymous", "developer",
︙			︙
114 115 116 117 118 119 120 ~~121~~ 122 ~~123~~ 124 125 126 127 128 129 130 131 132 ~~133~~ 134 ~~135~~ 136 137 138 139	This means that when USER.PW holds a cleartext password, the login card will work for both older and newer clients. If the USER.PW on the server only holds the SHA1 hash of the password, then only newer clients will be able to authenticate to the server. The client normally gets the login and password from the "remote URL". ~~~~<blockquote>~~<pre>~~ http://<span style="color:blue">login:password</span>@servername.org/path ~~</pre>~~</blockquote>~~~~ For older clients, the password is used for the shared secret as stated in the URL and with no encoding. For newer clients, the shared secret is derived from the password by transformed the password using the SHA1 hash encoding described above. However, if the first character of the password is "" (ASCII 0x2a) then the "" is skipped and the rest of the password is used directly as the share secret without the SHA1 encoding. ~~~~<blockquote>~~<pre>~~ http://<span style="color:blue">login:password</span>@servername.org/path ~~</pre>~~</blockquote>~~~~ This -before-the-password trick can be used by newer clients to sync against a legacy server that does not understand the new SHA1 password encoding.	\| \| \| \|	114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139	This means that when USER.PW holds a cleartext password, the login card will work for both older and newer clients. If the USER.PW on the server only holds the SHA1 hash of the password, then only newer clients will be able to authenticate to the server. The client normally gets the login and password from the "remote URL". <pre> http://<span style="color:blue">login:password</span>@servername.org/path </pre> For older clients, the password is used for the shared secret as stated in the URL and with no encoding. For newer clients, the shared secret is derived from the password by transformed the password using the SHA1 hash encoding described above. However, if the first character of the password is "" (ASCII 0x2a) then the "" is skipped and the rest of the password is used directly as the share secret without the SHA1 encoding. <pre> http://<span style="color:blue">login:password</span>@servername.org/path </pre> This -before-the-password trick can be used by newer clients to sync against a legacy server that does not understand the new SHA1 password encoding.