| ︙ | | |
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
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
|
-
-
+
+
+
-
-
+
+
+
+
|
the checklist.
<h2>2.0 How It Works</h2>
CGI Extensions are disabled by default.
An administrator activates the CGI extension mechanism by specifying
an "Extension Root Directory" or "extroot" as part of the server setup.
If the Fossil server is itself run as CGI, then add a line to the CGI
script file that says:
If the Fossil server is itself run as
[./server.wiki#cgi|CGI], then add a line to the
[./cgi.wiki#extroot|CGI script file] that says:
<blockquote><pre>
extroot: <i>DIRECTORY</i>
</pre></blockquote>
Or, if the Fossil server is begin run as using the "fossil server" or
"fossil ui" or "fossil http" commands, then add an extra
Or, if the Fossil server is begin run as using the
"[./server.wiki#standalone|fossil server]" or
"[./server.wiki#standalone|fossil ui]" or
"[./server.wiki#inetd|fossil http]" commands, then add an extra
"--extroot <i>DIRECTORY</i>" option to that command.
The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI.
Files in the DOCUMENT_ROOT are accessed via URLs like this:
<blockquote>
https://example-project.org/ext/<i>FILENAME</i>
|
| ︙ | | |
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
-
+
|
repository: /fossil/fossil.fossil
errorlog: /logs/errors.txt
extroot: /fossil-extroot
</verbatim></blockquote>
The extroot for this Fossil server is /fossil-extroot and in that directory
is an executable file named "fileup1" - another [https://wapp.tcl.tk|Wapp]
script. (The extension mechanism does not have to use Wapp. You can use
script. (The extension mechanism is not required to use Wapp. You can use
any kind of program you like. But the creator of SQLite and Fossil is fond
of [https://www.tcl.tk|Tcl/Tk] and so he tends to gravitate toward Tcl-based
technologies like Wapp.) The fileup1 script is a demo program that lets
the user upload a file using a form, and then displays that file in the reply.
There is a link on the page that causes the fileup1 script to return a copy
of its own source-code, so you can see how it works.
|
| ︙ | | |
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
-
+
+
|
"[https://duckduckgo.com/?q=cgi+environment_variables|cgi environment variables]"
to find more detail about what each of the above variables mean and how
they are used.
Live listings of the values of some or all of these environment variables
can be found at links like these:
* [https://fossil-scm.org/home/test_env]
* [https://sqlite.org/src/ext/checklist/env]
* [https://sqlite.org/src/ext/checklist/top/env]
In addition to the standard CGI environment variables listed above,
Fossil adds the following:
* FOSSIL_CAPABILITIES
* FOSSIL_NONCE
* FOSSIL_REPOSITORY
* FOSSIL_URI
* FOSSIL_USER
The FOSSIL_USER string is the name of the logged-in user. This variable
is missing or is an empty string if the user is not logged in. The
FOSSIL_CAPABILITIES string is a list of
|
| ︙ | | |
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
|
The [https://sqlite.org/src/ext/checklist|checklist application] uses the
FOSSIL_USER environment variable to determine the name of the user and
the FOSSIL_CAPABILITIES variable to determine if the user is allowed to
mark off changes to the checklist. Only users with check-in permission
to the Fossil repository are allowed to mark off checklist items. That
means that the FOSSIL_CAPABILITIES string must contain the letter "i".
Search for "FOSSIL_CAPABILITIES" in the
[https://sqlite.org/src/ext/checklist/self|source listing] to see how
[https://sqlite.org/src/ext/checklist/top/self|source listing] to see how
this happens.
If the CGI output is one of the forms for which Fossil inserts its own
header and footer, then the inserted header will include a
Content Security Policy (CSP) restriction on the use of javascript within
the webpage. Any <script>...</script> elements within the
CGI output must include a nonce or else they will be suppressed by the
web browser. The FOSSIL_NONCE variable contains the value of that nonce.
So, in other words, to get javascript to work, it must be enclosed in:
<blockquote><verbatim>
<script nonce='$FOSSIL_NONCE'>...</script>
</verbatim></blockquote>
Except, of course, the $FOSSIL_NONCE is replace by the value of the
FOSSIL_NONCE environment variable.
If the HTTP request includes content (for example if this is a POST request)
then the CONTENT_LENGTH value will be positive and the data for the content
will be readable on standard input.
<h2>4.0 CGI Outputs</h2>
|
| ︙ | | |