Fossil SCM

Update the change log and sync.wiki for the login card additions.

stephan 2025-07-24 02:41 xfer-login-card
Commit edfa01d9d20400c1ef4fa63f225e9c071e93a907ccb66158157ed68b29bc96fb
Parent 286110dec0d1b95…
3 files changed +3 -3 +2 +21 -5
~ src/xfer.c ~ www/changes.wiki ~ www/sync.wiki
M src/xfer.c
+3 -3
--- src/xfer.c
+++ src/xfer.c
@@ -1317,13 +1317,13 @@
13171317
 if( zScript ){ /* NOTE: Are TH1 transfer hooks enabled? */
13181318
 pzUuidList = &zUuidList;
13191319
 pnUuidList = &nUuidList;
13201320
 }
13211321
 if( g.syncInfo.zLoginCard ){
1322
- /* Login card received via HTTP header X-Fossil-Xfer-Login or
1323
- ** x-f-x-l GET parameter. */
1324
- assert( g.syncInfo.bLoginCardHeader && "Set via HTTP header/GET arg" );
1322
+ /* Login card received via HTTP header "X-Fossil-Xfer-Login" or
1323
+ ** "x-f-x-l" URL parameter. */
1324
+ assert( g.syncInfo.bLoginCardHeader && "Set via HTTP header/URL arg" );
13251325
 blob_zero(&xfer.line);
13261326
 blob_append(&xfer.line, g.syncInfo.zLoginCard, -1);
13271327
 xfer.nToken = blob_tokenize(&xfer.line, xfer.aToken,
13281328
 count(xfer.aToken));
13291329
 fossil_free( g.syncInfo.zLoginCard );
13301330
--- src/xfer.c
+++ src/xfer.c
@@ -1317,13 +1317,13 @@
1317 if( zScript ){ /* NOTE: Are TH1 transfer hooks enabled? */
1318 pzUuidList = &zUuidList;
1319 pnUuidList = &nUuidList;
1320 }
1321 if( g.syncInfo.zLoginCard ){
1322 /* Login card received via HTTP header X-Fossil-Xfer-Login or
1323 ** x-f-x-l GET parameter. */
1324 assert( g.syncInfo.bLoginCardHeader && "Set via HTTP header/GET arg" );
1325 blob_zero(&xfer.line);
1326 blob_append(&xfer.line, g.syncInfo.zLoginCard, -1);
1327 xfer.nToken = blob_tokenize(&xfer.line, xfer.aToken,
1328 count(xfer.aToken));
1329 fossil_free( g.syncInfo.zLoginCard );
1330
--- src/xfer.c
+++ src/xfer.c
@@ -1317,13 +1317,13 @@
1317 if( zScript ){ /* NOTE: Are TH1 transfer hooks enabled? */
1318 pzUuidList = &zUuidList;
1319 pnUuidList = &nUuidList;
1320 }
1321 if( g.syncInfo.zLoginCard ){
1322 /* Login card received via HTTP header "X-Fossil-Xfer-Login" or
1323 ** "x-f-x-l" URL parameter. */
1324 assert( g.syncInfo.bLoginCardHeader && "Set via HTTP header/URL arg" );
1325 blob_zero(&xfer.line);
1326 blob_append(&xfer.line, g.syncInfo.zLoginCard, -1);
1327 xfer.nToken = blob_tokenize(&xfer.line, xfer.aToken,
1328 count(xfer.aToken));
1329 fossil_free( g.syncInfo.zLoginCard );
1330
M www/changes.wiki
+2
--- www/changes.wiki
+++ www/changes.wiki
@@ -13,10 +13,12 @@
1313
 <li> Enable the --editor option on the [/help?cmd=amend|fossil amend] command.
1414
 <li> Require at least an anonymous login to access the /blame page and similar,
1515
 to help prevent robots from soaking up excess CPU time on such pages.
1616
 <li> When walking the filesystem looking for Fossil repositories, avoid descending
1717
 into directories named "/proc".
18
+ <ll> Reduce memory requirements for sending authenticated sync protocol
19
+ messages.
1820
 </ol>
1921
2022
 <h2 id='v2_26'>Changes for version 2.26 (2025-04-30)</h2><ol>
2123
 <li>Enhancements to [/help?cmd=diff|fossil diff] and similar:
2224
 <ol type="a">
2325
--- www/changes.wiki
+++ www/changes.wiki
@@ -13,10 +13,12 @@
13 <li> Enable the --editor option on the [/help?cmd=amend|fossil amend] command.
14 <li> Require at least an anonymous login to access the /blame page and similar,
15 to help prevent robots from soaking up excess CPU time on such pages.
16 <li> When walking the filesystem looking for Fossil repositories, avoid descending
17 into directories named "/proc".
 
 
18 </ol>
19
20 <h2 id='v2_26'>Changes for version 2.26 (2025-04-30)</h2><ol>
21 <li>Enhancements to [/help?cmd=diff|fossil diff] and similar:
22 <ol type="a">
23
--- www/changes.wiki
+++ www/changes.wiki
@@ -13,10 +13,12 @@
13 <li> Enable the --editor option on the [/help?cmd=amend|fossil amend] command.
14 <li> Require at least an anonymous login to access the /blame page and similar,
15 to help prevent robots from soaking up excess CPU time on such pages.
16 <li> When walking the filesystem looking for Fossil repositories, avoid descending
17 into directories named "/proc".
18 <ll> Reduce memory requirements for sending authenticated sync protocol
19 messages.
20 </ol>
21
22 <h2 id='v2_26'>Changes for version 2.26 (2025-04-30)</h2><ol>
23 <li>Enhancements to [/help?cmd=diff|fossil diff] and similar:
24 <ol type="a">
25
M www/sync.wiki
+21 -5
--- www/sync.wiki
+++ www/sync.wiki
@@ -220,15 +220,16 @@
220220
 Every message from client to server begins with one or more login
221221
 cards. Each login card has the following format:
222222
223223
 <pre><b>login</b> <i>userid nonce signature</i></pre>
224224
225
-The userid is the name of the user that is requesting service
226
-from the server. The nonce is the SHA1 hash of the remainder of
227
-the message - all text that follows the newline character that
228
-terminates the login card. The signature is the SHA1 hash of
229
-the concatenation of the nonce and the users password.
225
+The userid is the name of the user that is requesting service from the
226
+server, encoded in "fossilized" form (exactly as described for <a
227
+href="#error">the error card</a>). The nonce is the SHA1 hash of the
228
+remainder of the message - all text that follows the newline character
229
+that terminates the login card. The signature is the SHA1 hash of the
230
+concatenation of the nonce and the users password.
230231
231232
 When receving a login card, the server looks up the user and verifies
232233
 that the nonce matches the SHA1 hash of the remainder of the message.
233234
 It then checks the signature hash to make sure the signature matches.
234235
 If everything checks out, then the client is granted all privileges of
@@ -236,10 +237,25 @@
236237
237238
 Only one login card is permitted. A second login card will trigger
238239
 a sync error. (Prior to 2025-07-21, the protocol permitted multiple
239240
 logins, treating the login as the union of all privileges from all
240241
 login cards. That capability was never used and has been removed.)
242
+
243
+As of version 2.27, Fossil supports transfering of the login card
244
+outside of the payload body, in one of the following ways:
245
+
246
+<ul>
247
+<li> URL parameter named "x-f-x-l". The value must be URL-encoded.
248
+<li> An HTTP header named "X-Fossil-Xfer-Login". The caveat for the
249
+ header is that CGI-hosted fossils cannot see the headers. It
250
+ works for standalone severs and those running via fossil's
251
+ "test-http" mechanism. This approach is retained, despite the CGI
252
+ disadvantage, because the URL parameter approach cannot be used
253
+ to capture sync payload bodies for re-use with the "test-http"
254
+ mechanism, a capability useful in testing.
255
+</ul>
256
+
241257
242258
 <h3 id="file">3.3 File Cards</h3>
243259
244260
 Artifacts are transferred using either "file" cards, or "cfile"
245261
 or "uvfile" cards.
246262
--- www/sync.wiki
+++ www/sync.wiki
@@ -220,15 +220,16 @@
220 Every message from client to server begins with one or more login
221 cards. Each login card has the following format:
222
223 <pre><b>login</b> <i>userid nonce signature</i></pre>
224
225 The userid is the name of the user that is requesting service
226 from the server. The nonce is the SHA1 hash of the remainder of
227 the message - all text that follows the newline character that
228 terminates the login card. The signature is the SHA1 hash of
229 the concatenation of the nonce and the users password.
 
230
231 When receving a login card, the server looks up the user and verifies
232 that the nonce matches the SHA1 hash of the remainder of the message.
233 It then checks the signature hash to make sure the signature matches.
234 If everything checks out, then the client is granted all privileges of
@@ -236,10 +237,25 @@
236
237 Only one login card is permitted. A second login card will trigger
238 a sync error. (Prior to 2025-07-21, the protocol permitted multiple
239 logins, treating the login as the union of all privileges from all
240 login cards. That capability was never used and has been removed.)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
241
242 <h3 id="file">3.3 File Cards</h3>
243
244 Artifacts are transferred using either "file" cards, or "cfile"
245 or "uvfile" cards.
246
--- www/sync.wiki
+++ www/sync.wiki
@@ -220,15 +220,16 @@
220 Every message from client to server begins with one or more login
221 cards. Each login card has the following format:
222
223 <pre><b>login</b> <i>userid nonce signature</i></pre>
224
225 The userid is the name of the user that is requesting service from the
226 server, encoded in "fossilized" form (exactly as described for <a
227 href="#error">the error card</a>). The nonce is the SHA1 hash of the
228 remainder of the message - all text that follows the newline character
229 that terminates the login card. The signature is the SHA1 hash of the
230 concatenation of the nonce and the users password.
231
232 When receving a login card, the server looks up the user and verifies
233 that the nonce matches the SHA1 hash of the remainder of the message.
234 It then checks the signature hash to make sure the signature matches.
235 If everything checks out, then the client is granted all privileges of
@@ -236,10 +237,25 @@
237
238 Only one login card is permitted. A second login card will trigger
239 a sync error. (Prior to 2025-07-21, the protocol permitted multiple
240 logins, treating the login as the union of all privileges from all
241 login cards. That capability was never used and has been removed.)
242
243 As of version 2.27, Fossil supports transfering of the login card
244 outside of the payload body, in one of the following ways:
245
246 <ul>
247 <li> URL parameter named "x-f-x-l". The value must be URL-encoded.
248 <li> An HTTP header named "X-Fossil-Xfer-Login". The caveat for the
249 header is that CGI-hosted fossils cannot see the headers. It
250 works for standalone severs and those running via fossil's
251 "test-http" mechanism. This approach is retained, despite the CGI
252 disadvantage, because the URL parameter approach cannot be used
253 to capture sync payload bodies for re-use with the "test-http"
254 mechanism, a capability useful in testing.
255 </ul>
256
257
258 <h3 id="file">3.3 File Cards</h3>
259
260 Artifacts are transferred using either "file" cards, or "cfile"
261 or "uvfile" cards.
262

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button