Fossil SCM
Enhancements to the CGI extension documentation.
Commit
f80f753050ce286f7d1878d3a593177beedf2f643ab94427dc2038b1ee5fbd23
Parent
dfa5d50971c757a…
1 file changed
+21
-20
+21
-20
| --- www/serverext.wiki | ||
| +++ www/serverext.wiki | ||
| @@ -1,29 +1,29 @@ | ||
| 1 | 1 | <title>CGI Server Extensions</title> |
| 2 | 2 | |
| 3 | 3 | <h2>1.0 Introduction</h2> |
| 4 | 4 | |
| 5 | -If you choose to have a [./server.wiki|central server] for your Fossil-based | |
| 6 | -project (which is optional - Fossil can be used in a pure peer-to-peer | |
| 7 | -mode) then you can add CGI extensions to the Fossil website. These | |
| 8 | -extensions work like any other CGI program, except that they also have access | |
| 9 | -to the Fossil login information, so that they can restrict access based on | |
| 10 | -the currently logged in user. The CGI output can be a stand-alone webpage, | |
| 11 | -or it can be incorporated into the Fossil site using the standard Fossil | |
| 12 | -header and footer. | |
| 5 | +If you have a [./server.wiki|Fossil server] for your project, | |
| 6 | +you can add [https://en.wikipedia.org/wiki/Common_Gateway_Interface|CGI] | |
| 7 | +extensions to that server. These extensions work like | |
| 8 | +any other CGI program, except that they also have access to the Fossil | |
| 9 | +login information and can (optionally) leverage the "skins" of Fossil | |
| 10 | +so that they appear to be more tightly integrated into the project. | |
| 13 | 11 | |
| 14 | 12 | An example of where this is useful is the |
| 15 | 13 | [https://sqlite.org/src/ext/checklist|checklist application] on |
| 16 | 14 | the [https://sqlite.org/|SQLite] project. The checklist |
| 17 | 15 | helps the SQLite developers track which release tests have passed, |
| 18 | 16 | or failed, or are still to be done. The checklist program began as a |
| 19 | 17 | stand-alone CGI which kept its own private user database and implemented |
| 20 | -its own permissions and login system. By converting checklist into | |
| 21 | -a Fossil extension, the same login that works for the | |
| 22 | -[https://sqlite.org/src|main SQLite source repository] also works | |
| 23 | -for the checklist. And permission to change elements of the checklist | |
| 24 | -is based on permission to check-in to the main source repository. | |
| 18 | +its own permissions and login system and provided its own CSS. By | |
| 19 | +converting checklist into a Fossil extension, the same login that works | |
| 20 | +for the [https://sqlite.org/src|main SQLite source repository] also works | |
| 21 | +for the checklist. Permission to change elements of the checklist | |
| 22 | +is tied on permission to check-in to the main source repository. And | |
| 23 | +the standard Fossil header menu and footer appear on each page of | |
| 24 | +the checklist. | |
| 25 | 25 | |
| 26 | 26 | <h2>2.0 How It Works</h2> |
| 27 | 27 | |
| 28 | 28 | CGI Extensions are disabled by default. |
| 29 | 29 | An administrator activates the CGI extension mechanism by specifying |
| @@ -81,12 +81,13 @@ | ||
| 81 | 81 | |
| 82 | 82 | The /sqlite-src-ext/checklist file is a |
| 83 | 83 | [https://wapp.tcl.tk|Wapp program]. The current source code to the |
| 84 | 84 | this program can be seen at |
| 85 | 85 | [https://www.sqlite.org/src/ext/checklist/self] and |
| 86 | -historical versions are available at | |
| 87 | -[https://sqlite.org/docsrc/finfo/misc/checklist.tcl]. | |
| 86 | +recent historical versions are available at | |
| 87 | +[https://sqlite.org/docsrc/finfo/misc/checklist.tcl] with | |
| 88 | +older legacy at [https://sqlite.org/checklistapp/timeline?n=all] | |
| 88 | 89 | |
| 89 | 90 | There is a cascade of CGIs happening here. The webserver that receives |
| 90 | 91 | the initial HTTP request runs Fossil as a CGI based on the |
| 91 | 92 | "https://sqlite.org/src" portion of the URL. The Fossil instance then |
| 92 | 93 | runs the checklist sub-CGI based on the "/ext/checklists" suffix. The |
| @@ -107,15 +108,15 @@ | ||
| 107 | 108 | |
| 108 | 109 | The extroot for this Fossil server is /fossil-extroot and in that directory |
| 109 | 110 | is an executable file named "fileup1" - another [https://wapp.tcl.tk|Wapp] |
| 110 | 111 | script. (The extension mechanism does not have to use Wapp. You can use |
| 111 | 112 | any kind of program you like. But the creator of SQLite and Fossil is fond |
| 112 | -of Tcl/Tk and so he tends to gravitate toward Tcl-based technologies like | |
| 113 | -Wapp.) The fileup1 script is a demo program that lets the user upload | |
| 114 | -a file using a form, and then displays that file in the reply. There is | |
| 115 | -a link on the page that causes the fileup1 script to return a copy of its | |
| 116 | -own source-code, so you can see how it works. | |
| 113 | +of [https://www.tcl.tk|Tcl/Tk] and so he tends to gravitate toward Tcl-based | |
| 114 | +technologies like Wapp.) The fileup1 script is a demo program that lets | |
| 115 | +the user upload a file using a form, and then displays that file in the reply. | |
| 116 | +There is a link on the page that causes the fileup1 script to return a copy | |
| 117 | +of its own source-code, so you can see how it works. | |
| 117 | 118 | |
| 118 | 119 | <h2>3.0 CGI Inputs</h2> |
| 119 | 120 | |
| 120 | 121 | The /ext extension mechanism is an ordinary CGI interface. Parameters |
| 121 | 122 | are passed to the CGI program using environment variables. The following |
| 122 | 123 |
| --- www/serverext.wiki | |
| +++ www/serverext.wiki | |
| @@ -1,29 +1,29 @@ | |
| 1 | <title>CGI Server Extensions</title> |
| 2 | |
| 3 | <h2>1.0 Introduction</h2> |
| 4 | |
| 5 | If you choose to have a [./server.wiki|central server] for your Fossil-based |
| 6 | project (which is optional - Fossil can be used in a pure peer-to-peer |
| 7 | mode) then you can add CGI extensions to the Fossil website. These |
| 8 | extensions work like any other CGI program, except that they also have access |
| 9 | to the Fossil login information, so that they can restrict access based on |
| 10 | the currently logged in user. The CGI output can be a stand-alone webpage, |
| 11 | or it can be incorporated into the Fossil site using the standard Fossil |
| 12 | header and footer. |
| 13 | |
| 14 | An example of where this is useful is the |
| 15 | [https://sqlite.org/src/ext/checklist|checklist application] on |
| 16 | the [https://sqlite.org/|SQLite] project. The checklist |
| 17 | helps the SQLite developers track which release tests have passed, |
| 18 | or failed, or are still to be done. The checklist program began as a |
| 19 | stand-alone CGI which kept its own private user database and implemented |
| 20 | its own permissions and login system. By converting checklist into |
| 21 | a Fossil extension, the same login that works for the |
| 22 | [https://sqlite.org/src|main SQLite source repository] also works |
| 23 | for the checklist. And permission to change elements of the checklist |
| 24 | is based on permission to check-in to the main source repository. |
| 25 | |
| 26 | <h2>2.0 How It Works</h2> |
| 27 | |
| 28 | CGI Extensions are disabled by default. |
| 29 | An administrator activates the CGI extension mechanism by specifying |
| @@ -81,12 +81,13 @@ | |
| 81 | |
| 82 | The /sqlite-src-ext/checklist file is a |
| 83 | [https://wapp.tcl.tk|Wapp program]. The current source code to the |
| 84 | this program can be seen at |
| 85 | [https://www.sqlite.org/src/ext/checklist/self] and |
| 86 | historical versions are available at |
| 87 | [https://sqlite.org/docsrc/finfo/misc/checklist.tcl]. |
| 88 | |
| 89 | There is a cascade of CGIs happening here. The webserver that receives |
| 90 | the initial HTTP request runs Fossil as a CGI based on the |
| 91 | "https://sqlite.org/src" portion of the URL. The Fossil instance then |
| 92 | runs the checklist sub-CGI based on the "/ext/checklists" suffix. The |
| @@ -107,15 +108,15 @@ | |
| 107 | |
| 108 | The extroot for this Fossil server is /fossil-extroot and in that directory |
| 109 | is an executable file named "fileup1" - another [https://wapp.tcl.tk|Wapp] |
| 110 | script. (The extension mechanism does not have to use Wapp. You can use |
| 111 | any kind of program you like. But the creator of SQLite and Fossil is fond |
| 112 | of Tcl/Tk and so he tends to gravitate toward Tcl-based technologies like |
| 113 | Wapp.) The fileup1 script is a demo program that lets the user upload |
| 114 | a file using a form, and then displays that file in the reply. There is |
| 115 | a link on the page that causes the fileup1 script to return a copy of its |
| 116 | own source-code, so you can see how it works. |
| 117 | |
| 118 | <h2>3.0 CGI Inputs</h2> |
| 119 | |
| 120 | The /ext extension mechanism is an ordinary CGI interface. Parameters |
| 121 | are passed to the CGI program using environment variables. The following |
| 122 |
| --- www/serverext.wiki | |
| +++ www/serverext.wiki | |
| @@ -1,29 +1,29 @@ | |
| 1 | <title>CGI Server Extensions</title> |
| 2 | |
| 3 | <h2>1.0 Introduction</h2> |
| 4 | |
| 5 | If you have a [./server.wiki|Fossil server] for your project, |
| 6 | you can add [https://en.wikipedia.org/wiki/Common_Gateway_Interface|CGI] |
| 7 | extensions to that server. These extensions work like |
| 8 | any other CGI program, except that they also have access to the Fossil |
| 9 | login information and can (optionally) leverage the "skins" of Fossil |
| 10 | so that they appear to be more tightly integrated into the project. |
| 11 | |
| 12 | An example of where this is useful is the |
| 13 | [https://sqlite.org/src/ext/checklist|checklist application] on |
| 14 | the [https://sqlite.org/|SQLite] project. The checklist |
| 15 | helps the SQLite developers track which release tests have passed, |
| 16 | or failed, or are still to be done. The checklist program began as a |
| 17 | stand-alone CGI which kept its own private user database and implemented |
| 18 | its own permissions and login system and provided its own CSS. By |
| 19 | converting checklist into a Fossil extension, the same login that works |
| 20 | for the [https://sqlite.org/src|main SQLite source repository] also works |
| 21 | for the checklist. Permission to change elements of the checklist |
| 22 | is tied on permission to check-in to the main source repository. And |
| 23 | the standard Fossil header menu and footer appear on each page of |
| 24 | the checklist. |
| 25 | |
| 26 | <h2>2.0 How It Works</h2> |
| 27 | |
| 28 | CGI Extensions are disabled by default. |
| 29 | An administrator activates the CGI extension mechanism by specifying |
| @@ -81,12 +81,13 @@ | |
| 81 | |
| 82 | The /sqlite-src-ext/checklist file is a |
| 83 | [https://wapp.tcl.tk|Wapp program]. The current source code to the |
| 84 | this program can be seen at |
| 85 | [https://www.sqlite.org/src/ext/checklist/self] and |
| 86 | recent historical versions are available at |
| 87 | [https://sqlite.org/docsrc/finfo/misc/checklist.tcl] with |
| 88 | older legacy at [https://sqlite.org/checklistapp/timeline?n=all] |
| 89 | |
| 90 | There is a cascade of CGIs happening here. The webserver that receives |
| 91 | the initial HTTP request runs Fossil as a CGI based on the |
| 92 | "https://sqlite.org/src" portion of the URL. The Fossil instance then |
| 93 | runs the checklist sub-CGI based on the "/ext/checklists" suffix. The |
| @@ -107,15 +108,15 @@ | |
| 108 | |
| 109 | The extroot for this Fossil server is /fossil-extroot and in that directory |
| 110 | is an executable file named "fileup1" - another [https://wapp.tcl.tk|Wapp] |
| 111 | script. (The extension mechanism does not have to use Wapp. You can use |
| 112 | any kind of program you like. But the creator of SQLite and Fossil is fond |
| 113 | of [https://www.tcl.tk|Tcl/Tk] and so he tends to gravitate toward Tcl-based |
| 114 | technologies like Wapp.) The fileup1 script is a demo program that lets |
| 115 | the user upload a file using a form, and then displays that file in the reply. |
| 116 | There is a link on the page that causes the fileup1 script to return a copy |
| 117 | of its own source-code, so you can see how it works. |
| 118 | |
| 119 | <h2>3.0 CGI Inputs</h2> |
| 120 | |
| 121 | The /ext extension mechanism is an ordinary CGI interface. Parameters |
| 122 | are passed to the CGI program using environment variables. The following |
| 123 |