Fossil SCM
Added link to help page for redirect-to-https. Untested in .wiki.
Commit
7ae65cb84e57406c19c0da858bd5674946842908e0d6bb62c3b9ac23d3ade507
Parent
201004367baed3d…
1 file changed
+3
-1
+3
-1
| --- www/password.wiki | ||
| +++ www/password.wiki | ||
| @@ -64,18 +64,20 @@ | ||
| 64 | 64 | |
| 65 | 65 | <h2>Web Interface Authentication</h2> |
| 66 | 66 | |
| 67 | 67 | When a user logs into Fossil using the web interface, the login name |
| 68 | 68 | and password are sent in the clear to the server. For most modern fossil |
| 69 | -server setups with redirect-to-https enabled, this will be protected by the | |
| 69 | +server setups with [/help?cmd=redirect-to-https|redirect-to-https] enabled, | |
| 70 | +this will be protected by the | |
| 70 | 71 | SSL connection over HTTPS so it cannot be easily viewed. The server then |
| 71 | 72 | hashes the password and compares it against the value stored in USER.PW. |
| 72 | 73 | If they match, the server sets a cookie on the client to record the |
| 73 | 74 | login. This cookie contains a large amount of high-quality randomness |
| 74 | 75 | and is thus intractable to guess. The value of the cookie and the IP |
| 75 | 76 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 76 | 77 | of the USER table on the server. |
| 78 | + | |
| 77 | 79 | The USER.CEXPIRE field holds an expiration date |
| 78 | 80 | for the cookie, encoded as a Julian day number. On all subsequent |
| 79 | 81 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | 82 | enable access to the repository. |
| 81 | 83 | |
| 82 | 84 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -64,18 +64,20 @@ | |
| 64 | |
| 65 | <h2>Web Interface Authentication</h2> |
| 66 | |
| 67 | When a user logs into Fossil using the web interface, the login name |
| 68 | and password are sent in the clear to the server. For most modern fossil |
| 69 | server setups with redirect-to-https enabled, this will be protected by the |
| 70 | SSL connection over HTTPS so it cannot be easily viewed. The server then |
| 71 | hashes the password and compares it against the value stored in USER.PW. |
| 72 | If they match, the server sets a cookie on the client to record the |
| 73 | login. This cookie contains a large amount of high-quality randomness |
| 74 | and is thus intractable to guess. The value of the cookie and the IP |
| 75 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 76 | of the USER table on the server. |
| 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | for the cookie, encoded as a Julian day number. On all subsequent |
| 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | enable access to the repository. |
| 81 | |
| 82 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -64,18 +64,20 @@ | |
| 64 | |
| 65 | <h2>Web Interface Authentication</h2> |
| 66 | |
| 67 | When a user logs into Fossil using the web interface, the login name |
| 68 | and password are sent in the clear to the server. For most modern fossil |
| 69 | server setups with [/help?cmd=redirect-to-https|redirect-to-https] enabled, |
| 70 | this will be protected by the |
| 71 | SSL connection over HTTPS so it cannot be easily viewed. The server then |
| 72 | hashes the password and compares it against the value stored in USER.PW. |
| 73 | If they match, the server sets a cookie on the client to record the |
| 74 | login. This cookie contains a large amount of high-quality randomness |
| 75 | and is thus intractable to guess. The value of the cookie and the IP |
| 76 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 77 | of the USER table on the server. |
| 78 | |
| 79 | The USER.CEXPIRE field holds an expiration date |
| 80 | for the cookie, encoded as a Julian day number. On all subsequent |
| 81 | HTTP requests, the cookie value is matched against the USER table to |
| 82 | enable access to the repository. |
| 83 | |
| 84 |