Fossil SCM
Linked to the new caps docs from the existing www/* docs wherever "capability" or "capabilities" was mentioned before.
Commit
0af0e14688c7bfc4f1024ae68e0b87161b5b0b686d79c46e88e60d0772379247
Parent
4aceb600dc34c9f…
8 files changed
+15
-9
+21
-24
+5
-5
+1
-1
+34
-42
+1
-2
+4
-4
+2
-2
+15
-9
| --- www/alerts.md | ||
| +++ www/alerts.md | ||
| @@ -30,11 +30,11 @@ | ||
| 30 | 30 | |
| 31 | 31 | Much of this document describes how to set up Fossil's email alert |
| 32 | 32 | system. To follow this guide, you will need a Fossil UI browser window |
| 33 | 33 | open to the [Admin → Notification](/setup_notification) Fossil UI screen |
| 34 | 34 | on the Fossil server that will be sending these email alerts, logged |
| 35 | -in as a user with Admin capability. It is not possible to work on a | |
| 35 | +in as a user with [**Admin** capability](./caps/ref.html#a). It is not possible to work on a | |
| 36 | 36 | clone of the server's repository and push the configuration changes up |
| 37 | 37 | to that repo as an Admin user, [on purpose](#backup). |
| 38 | 38 | |
| 39 | 39 | **Important:** Do not confuse that screen with Admin → Email-Server, |
| 40 | 40 | which sets up a different subsystem within Fossil. That feature is |
| @@ -160,11 +160,12 @@ | ||
| 160 | 160 | <blockquote> |
| 161 | 161 | Use a different login with greater privilege than FOO to access |
| 162 | 162 | /subscribe |
| 163 | 163 | </blockquote> |
| 164 | 164 | |
| 165 | -...then the repository's administrator forgot to [give the Alerts capability](#cap7) | |
| 165 | +...then the repository's administrator forgot to give the | |
| 166 | +[**EmailAlert** capability][cap7] | |
| 166 | 167 | to that user or to a user category that the user is a member of. |
| 167 | 168 | |
| 168 | 169 | After a subscriber signs up for alerts for the first time, a single |
| 169 | 170 | verification email is sent to that subscriber's given email address. |
| 170 | 171 | The new subscriber must click a link in that email in order to activate |
| @@ -188,10 +189,12 @@ | ||
| 188 | 189 | settings by visiting the `/alerts` page on the repository. With the |
| 189 | 190 | default skin, you can get there by clicking the "Logout" link in the |
| 190 | 191 | upper right corner of any Fossil UI page then clicking the "Email |
| 191 | 192 | Alerts" link. That link is also available via the Sitemap (`/sitemap`) |
| 192 | 193 | and via the default skin's hamburger menu (☰). |
| 194 | + | |
| 195 | +[cap7]: ./caps/ref.html#7 | |
| 193 | 196 | |
| 194 | 197 | |
| 195 | 198 | <a id="unsub" name="unsubscribe"></a> |
| 196 | 199 | ### Unsubscribing |
| 197 | 200 | |
| @@ -223,24 +226,27 @@ | ||
| 223 | 226 | Checklist][cl], right? Right. |
| 224 | 227 | |
| 225 | 228 | [cl]: https://sendgrid.com/blog/programming-style-guide-checklist/ |
| 226 | 229 | |
| 227 | 230 | |
| 228 | -<a id="cap7"></a> | |
| 231 | +<a id="cap7" name="ucap"></a> | |
| 229 | 232 | ### User Capabilities |
| 230 | 233 | |
| 231 | -Once email alerts are working, one must also adjust user permissions to | |
| 232 | -allow users to subscribe to email alerts. In the capability list for | |
| 233 | -each user on the Admin → Users page is a new capability called "Email | |
| 234 | -Alerts". The corresponding capability letter is "7", which you must | |
| 235 | -give to any user that needs to use the subscription setup pages, | |
| 236 | -`/subscribe` and `/alerts`. | |
| 234 | +Once email alerts are working, you may need to [adjust the default user | |
| 235 | +capabilities](./caps/) to give "[Email Alerts][cap7]" capability to any | |
| 236 | +[user category](./caps/#ucat) or [individual user](./caps/#ucap) that | |
| 237 | +needs to use the subscription setup pages, `/subscribe` and `/alerts`. | |
| 238 | +[**Admin**][capa] and [**Setup**][caps] users always have this | |
| 239 | +capability. | |
| 237 | 240 | |
| 238 | 241 | To allow any passer-by on the Internet to subscribe, give the "Email |
| 239 | 242 | Alerts" capability to the "nobody" user category. To require that a |
| 240 | 243 | person solve a simple CAPTCHA first, give that capability to the |
| 241 | 244 | "anonymous" user category instead. |
| 245 | + | |
| 246 | +[capa]: ./caps/ref.html#a | |
| 247 | +[caps]: ./caps/ref.html#s | |
| 242 | 248 | |
| 243 | 249 | |
| 244 | 250 | <a id="first" name="frist"></a> |
| 245 | 251 | ### First Post |
| 246 | 252 | |
| 247 | 253 |
| --- www/alerts.md | |
| +++ www/alerts.md | |
| @@ -30,11 +30,11 @@ | |
| 30 | |
| 31 | Much of this document describes how to set up Fossil's email alert |
| 32 | system. To follow this guide, you will need a Fossil UI browser window |
| 33 | open to the [Admin → Notification](/setup_notification) Fossil UI screen |
| 34 | on the Fossil server that will be sending these email alerts, logged |
| 35 | in as a user with Admin capability. It is not possible to work on a |
| 36 | clone of the server's repository and push the configuration changes up |
| 37 | to that repo as an Admin user, [on purpose](#backup). |
| 38 | |
| 39 | **Important:** Do not confuse that screen with Admin → Email-Server, |
| 40 | which sets up a different subsystem within Fossil. That feature is |
| @@ -160,11 +160,12 @@ | |
| 160 | <blockquote> |
| 161 | Use a different login with greater privilege than FOO to access |
| 162 | /subscribe |
| 163 | </blockquote> |
| 164 | |
| 165 | ...then the repository's administrator forgot to [give the Alerts capability](#cap7) |
| 166 | to that user or to a user category that the user is a member of. |
| 167 | |
| 168 | After a subscriber signs up for alerts for the first time, a single |
| 169 | verification email is sent to that subscriber's given email address. |
| 170 | The new subscriber must click a link in that email in order to activate |
| @@ -188,10 +189,12 @@ | |
| 188 | settings by visiting the `/alerts` page on the repository. With the |
| 189 | default skin, you can get there by clicking the "Logout" link in the |
| 190 | upper right corner of any Fossil UI page then clicking the "Email |
| 191 | Alerts" link. That link is also available via the Sitemap (`/sitemap`) |
| 192 | and via the default skin's hamburger menu (☰). |
| 193 | |
| 194 | |
| 195 | <a id="unsub" name="unsubscribe"></a> |
| 196 | ### Unsubscribing |
| 197 | |
| @@ -223,24 +226,27 @@ | |
| 223 | Checklist][cl], right? Right. |
| 224 | |
| 225 | [cl]: https://sendgrid.com/blog/programming-style-guide-checklist/ |
| 226 | |
| 227 | |
| 228 | <a id="cap7"></a> |
| 229 | ### User Capabilities |
| 230 | |
| 231 | Once email alerts are working, one must also adjust user permissions to |
| 232 | allow users to subscribe to email alerts. In the capability list for |
| 233 | each user on the Admin → Users page is a new capability called "Email |
| 234 | Alerts". The corresponding capability letter is "7", which you must |
| 235 | give to any user that needs to use the subscription setup pages, |
| 236 | `/subscribe` and `/alerts`. |
| 237 | |
| 238 | To allow any passer-by on the Internet to subscribe, give the "Email |
| 239 | Alerts" capability to the "nobody" user category. To require that a |
| 240 | person solve a simple CAPTCHA first, give that capability to the |
| 241 | "anonymous" user category instead. |
| 242 | |
| 243 | |
| 244 | <a id="first" name="frist"></a> |
| 245 | ### First Post |
| 246 | |
| 247 |
| --- www/alerts.md | |
| +++ www/alerts.md | |
| @@ -30,11 +30,11 @@ | |
| 30 | |
| 31 | Much of this document describes how to set up Fossil's email alert |
| 32 | system. To follow this guide, you will need a Fossil UI browser window |
| 33 | open to the [Admin → Notification](/setup_notification) Fossil UI screen |
| 34 | on the Fossil server that will be sending these email alerts, logged |
| 35 | in as a user with [**Admin** capability](./caps/ref.html#a). It is not possible to work on a |
| 36 | clone of the server's repository and push the configuration changes up |
| 37 | to that repo as an Admin user, [on purpose](#backup). |
| 38 | |
| 39 | **Important:** Do not confuse that screen with Admin → Email-Server, |
| 40 | which sets up a different subsystem within Fossil. That feature is |
| @@ -160,11 +160,12 @@ | |
| 160 | <blockquote> |
| 161 | Use a different login with greater privilege than FOO to access |
| 162 | /subscribe |
| 163 | </blockquote> |
| 164 | |
| 165 | ...then the repository's administrator forgot to give the |
| 166 | [**EmailAlert** capability][cap7] |
| 167 | to that user or to a user category that the user is a member of. |
| 168 | |
| 169 | After a subscriber signs up for alerts for the first time, a single |
| 170 | verification email is sent to that subscriber's given email address. |
| 171 | The new subscriber must click a link in that email in order to activate |
| @@ -188,10 +189,12 @@ | |
| 189 | settings by visiting the `/alerts` page on the repository. With the |
| 190 | default skin, you can get there by clicking the "Logout" link in the |
| 191 | upper right corner of any Fossil UI page then clicking the "Email |
| 192 | Alerts" link. That link is also available via the Sitemap (`/sitemap`) |
| 193 | and via the default skin's hamburger menu (☰). |
| 194 | |
| 195 | [cap7]: ./caps/ref.html#7 |
| 196 | |
| 197 | |
| 198 | <a id="unsub" name="unsubscribe"></a> |
| 199 | ### Unsubscribing |
| 200 | |
| @@ -223,24 +226,27 @@ | |
| 226 | Checklist][cl], right? Right. |
| 227 | |
| 228 | [cl]: https://sendgrid.com/blog/programming-style-guide-checklist/ |
| 229 | |
| 230 | |
| 231 | <a id="cap7" name="ucap"></a> |
| 232 | ### User Capabilities |
| 233 | |
| 234 | Once email alerts are working, you may need to [adjust the default user |
| 235 | capabilities](./caps/) to give "[Email Alerts][cap7]" capability to any |
| 236 | [user category](./caps/#ucat) or [individual user](./caps/#ucap) that |
| 237 | needs to use the subscription setup pages, `/subscribe` and `/alerts`. |
| 238 | [**Admin**][capa] and [**Setup**][caps] users always have this |
| 239 | capability. |
| 240 | |
| 241 | To allow any passer-by on the Internet to subscribe, give the "Email |
| 242 | Alerts" capability to the "nobody" user category. To require that a |
| 243 | person solve a simple CAPTCHA first, give that capability to the |
| 244 | "anonymous" user category instead. |
| 245 | |
| 246 | [capa]: ./caps/ref.html#a |
| 247 | [caps]: ./caps/ref.html#s |
| 248 | |
| 249 | |
| 250 | <a id="first" name="frist"></a> |
| 251 | ### First Post |
| 252 | |
| 253 |
+21
-24
| --- www/antibot.wiki | ||
| +++ www/antibot.wiki | ||
| @@ -10,44 +10,41 @@ | ||
| 10 | 10 | The website presented by a Fossil server is intended to be used |
| 11 | 11 | interactively by humans, not walked by spiders. This article |
| 12 | 12 | describes the techniques used by Fossil to try to welcome human |
| 13 | 13 | users while keeping out spiders. |
| 14 | 14 | |
| 15 | -<h2>The "hyperlink" user capability</h2> | |
| 15 | +<h2>The Hyperlink User Capability</h2> | |
| 16 | 16 | |
| 17 | 17 | Every Fossil web session has a "user". For random passers-by on the internet |
| 18 | 18 | (and for spiders) that user is "nobody". The "anonymous" user is also |
| 19 | 19 | available for humans who do not wish to identify themselves. The difference |
| 20 | 20 | is that "anonymous" requires a login (using a password supplied via |
| 21 | 21 | a CAPTCHA) whereas "nobody" does not require a login. |
| 22 | 22 | The site administrator can also create logins with |
| 23 | 23 | passwords for specific individuals. |
| 24 | 24 | |
| 25 | -The "h" or "hyperlink" capability is a permission that can be granted | |
| 26 | -to users that enables the display of hyperlinks. Most of the hyperlinks | |
| 27 | -generated by Fossil are suppressed if this capability is missing. So | |
| 28 | -one simple defense against spiders is to disable the "h" permission for | |
| 29 | -the "nobody" user. This means that users must log in (perhaps as | |
| 30 | -"anonymous") before they can see any of the hyperlinks. Spiders do not | |
| 31 | -normally attempt to log into websites and will therefore | |
| 32 | -not see most of the hyperlinks and will not try to walk the millions of | |
| 33 | -historical check-ins and diffs available on a Fossil-generated website. | |
| 34 | - | |
| 35 | -If the "h" capability is missing from user "nobody" but is present for | |
| 36 | -user "anonymous", then a message automatically appears at the top of each | |
| 37 | -page inviting the user to log in as anonymous in order to activate hyperlinks. | |
| 38 | - | |
| 39 | -Removing the "h" capability from user "nobody" is an effective means | |
| 40 | -of preventing spiders from walking a Fossil-generated website. But | |
| 41 | -it can also be annoying to humans, since it requires them to log in. | |
| 42 | -Hence, Fossil provides other techniques for blocking spiders which | |
| 25 | +Users without the <b>[./caps/ref.html#h | Hyperlink]</b> capability | |
| 26 | +do not see most Fossil-generated hyperlinks. This is | |
| 27 | +a simple defense against spiders, since [./caps/#ucat | the "nobody" | |
| 28 | +user category] does not have this capability by default. | |
| 29 | +Users must log in (perhaps as | |
| 30 | +"anonymous") before they can see any of the hyperlinks. A spider | |
| 31 | +that cannot log into your Fossil repository will be unable to walk | |
| 32 | +its historical check-ins, create diffs between versions, pull zip | |
| 33 | +archives, etc. by visiting links, because they aren't there. | |
| 34 | + | |
| 35 | +A text message appears at the top of each page in this situation to | |
| 36 | +invite humans to log in as anonymous in order to activate hyperlinks. | |
| 37 | + | |
| 38 | +Because this required login step is annoying to some, | |
| 39 | +Fossil provides other techniques for blocking spiders which | |
| 43 | 40 | are less cumbersome to humans. |
| 44 | 41 | |
| 45 | -<h2>Automatic hyperlinks based on UserAgent</h2> | |
| 42 | +<h2>Automatic Hyperlinks Based on UserAgent</h2> | |
| 46 | 43 | |
| 47 | 44 | Fossil has the ability to selectively enable hyperlinks for users |
| 48 | -that lack the "h" capability based on their UserAgent string in the | |
| 45 | +that lack the <b>Hyperlink</b> capability based on their UserAgent string in the | |
| 49 | 46 | HTTP request header and on the browsers ability to run Javascript. |
| 50 | 47 | |
| 51 | 48 | The UserAgent string is a text identifier that is included in the header |
| 52 | 49 | of most HTTP requests that identifies the specific maker and version of |
| 53 | 50 | the browser (or spider) that generated the request. Typical UserAgent |
| @@ -76,11 +73,11 @@ | ||
| 76 | 73 | |
| 77 | 74 | In Fossil, under the Admin/Access menu, there is a setting entitled |
| 78 | 75 | "<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>". |
| 79 | 76 | If this setting is enabled, and if the UserAgent string looks like a |
| 80 | 77 | human and not a spider, then Fossil will enable hyperlinks even if |
| 81 | -the "h" capability is omitted from the user permissions. This setting | |
| 78 | +the <b>Hyperlink</b> capability is omitted from the user permissions. This setting | |
| 82 | 79 | gives humans easy access to the hyperlinks while preventing spiders |
| 83 | 80 | from walking the millions of pages on a typical Fossil site. |
| 84 | 81 | |
| 85 | 82 | But the hyperlinks are not enabled directly with the setting above. |
| 86 | 83 | Instead, the HTML code that is generated contains anchor tags ("<a>") |
| @@ -92,11 +89,11 @@ | ||
| 92 | 89 | UserAgent string. Most spiders do not bother to run JavaScript and |
| 93 | 90 | so to the spider the empty anchor tag will be useless. But all modern |
| 94 | 91 | web browsers implement JavaScript, so hyperlinks will show up |
| 95 | 92 | normally for human users. |
| 96 | 93 | |
| 97 | -<h2>Further defenses</h2> | |
| 94 | +<h2>Further Defenses</h2> | |
| 98 | 95 | |
| 99 | 96 | Recently (as of this writing, in the spring of 2013) the Fossil server |
| 100 | 97 | on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly |
| 101 | 98 | by Chinese spiders that use forged UserAgent strings to make them look |
| 102 | 99 | like normal web browsers and which interpret JavaScript. We do not |
| @@ -134,11 +131,11 @@ | ||
| 134 | 131 | |
| 135 | 132 | See also [./loadmgmt.md|Managing Server Load] for a description |
| 136 | 133 | of how expensive pages can be disabled when the server is under heavy |
| 137 | 134 | load. |
| 138 | 135 | |
| 139 | -<h2>The ongoing struggle</h2> | |
| 136 | +<h2>The Ongoing Struggle</h2> | |
| 140 | 137 | |
| 141 | 138 | Fossil currently does a very good job of providing easy access to humans |
| 142 | 139 | while keeping out troublesome robots and spiders. However, spiders and |
| 143 | 140 | bots continue to grow more sophisticated, requiring ever more advanced |
| 144 | 141 | defenses. This "arms race" is unlikely to ever end. The developers of |
| 145 | 142 |
| --- www/antibot.wiki | |
| +++ www/antibot.wiki | |
| @@ -10,44 +10,41 @@ | |
| 10 | The website presented by a Fossil server is intended to be used |
| 11 | interactively by humans, not walked by spiders. This article |
| 12 | describes the techniques used by Fossil to try to welcome human |
| 13 | users while keeping out spiders. |
| 14 | |
| 15 | <h2>The "hyperlink" user capability</h2> |
| 16 | |
| 17 | Every Fossil web session has a "user". For random passers-by on the internet |
| 18 | (and for spiders) that user is "nobody". The "anonymous" user is also |
| 19 | available for humans who do not wish to identify themselves. The difference |
| 20 | is that "anonymous" requires a login (using a password supplied via |
| 21 | a CAPTCHA) whereas "nobody" does not require a login. |
| 22 | The site administrator can also create logins with |
| 23 | passwords for specific individuals. |
| 24 | |
| 25 | The "h" or "hyperlink" capability is a permission that can be granted |
| 26 | to users that enables the display of hyperlinks. Most of the hyperlinks |
| 27 | generated by Fossil are suppressed if this capability is missing. So |
| 28 | one simple defense against spiders is to disable the "h" permission for |
| 29 | the "nobody" user. This means that users must log in (perhaps as |
| 30 | "anonymous") before they can see any of the hyperlinks. Spiders do not |
| 31 | normally attempt to log into websites and will therefore |
| 32 | not see most of the hyperlinks and will not try to walk the millions of |
| 33 | historical check-ins and diffs available on a Fossil-generated website. |
| 34 | |
| 35 | If the "h" capability is missing from user "nobody" but is present for |
| 36 | user "anonymous", then a message automatically appears at the top of each |
| 37 | page inviting the user to log in as anonymous in order to activate hyperlinks. |
| 38 | |
| 39 | Removing the "h" capability from user "nobody" is an effective means |
| 40 | of preventing spiders from walking a Fossil-generated website. But |
| 41 | it can also be annoying to humans, since it requires them to log in. |
| 42 | Hence, Fossil provides other techniques for blocking spiders which |
| 43 | are less cumbersome to humans. |
| 44 | |
| 45 | <h2>Automatic hyperlinks based on UserAgent</h2> |
| 46 | |
| 47 | Fossil has the ability to selectively enable hyperlinks for users |
| 48 | that lack the "h" capability based on their UserAgent string in the |
| 49 | HTTP request header and on the browsers ability to run Javascript. |
| 50 | |
| 51 | The UserAgent string is a text identifier that is included in the header |
| 52 | of most HTTP requests that identifies the specific maker and version of |
| 53 | the browser (or spider) that generated the request. Typical UserAgent |
| @@ -76,11 +73,11 @@ | |
| 76 | |
| 77 | In Fossil, under the Admin/Access menu, there is a setting entitled |
| 78 | "<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>". |
| 79 | If this setting is enabled, and if the UserAgent string looks like a |
| 80 | human and not a spider, then Fossil will enable hyperlinks even if |
| 81 | the "h" capability is omitted from the user permissions. This setting |
| 82 | gives humans easy access to the hyperlinks while preventing spiders |
| 83 | from walking the millions of pages on a typical Fossil site. |
| 84 | |
| 85 | But the hyperlinks are not enabled directly with the setting above. |
| 86 | Instead, the HTML code that is generated contains anchor tags ("<a>") |
| @@ -92,11 +89,11 @@ | |
| 92 | UserAgent string. Most spiders do not bother to run JavaScript and |
| 93 | so to the spider the empty anchor tag will be useless. But all modern |
| 94 | web browsers implement JavaScript, so hyperlinks will show up |
| 95 | normally for human users. |
| 96 | |
| 97 | <h2>Further defenses</h2> |
| 98 | |
| 99 | Recently (as of this writing, in the spring of 2013) the Fossil server |
| 100 | on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly |
| 101 | by Chinese spiders that use forged UserAgent strings to make them look |
| 102 | like normal web browsers and which interpret JavaScript. We do not |
| @@ -134,11 +131,11 @@ | |
| 134 | |
| 135 | See also [./loadmgmt.md|Managing Server Load] for a description |
| 136 | of how expensive pages can be disabled when the server is under heavy |
| 137 | load. |
| 138 | |
| 139 | <h2>The ongoing struggle</h2> |
| 140 | |
| 141 | Fossil currently does a very good job of providing easy access to humans |
| 142 | while keeping out troublesome robots and spiders. However, spiders and |
| 143 | bots continue to grow more sophisticated, requiring ever more advanced |
| 144 | defenses. This "arms race" is unlikely to ever end. The developers of |
| 145 |
| --- www/antibot.wiki | |
| +++ www/antibot.wiki | |
| @@ -10,44 +10,41 @@ | |
| 10 | The website presented by a Fossil server is intended to be used |
| 11 | interactively by humans, not walked by spiders. This article |
| 12 | describes the techniques used by Fossil to try to welcome human |
| 13 | users while keeping out spiders. |
| 14 | |
| 15 | <h2>The Hyperlink User Capability</h2> |
| 16 | |
| 17 | Every Fossil web session has a "user". For random passers-by on the internet |
| 18 | (and for spiders) that user is "nobody". The "anonymous" user is also |
| 19 | available for humans who do not wish to identify themselves. The difference |
| 20 | is that "anonymous" requires a login (using a password supplied via |
| 21 | a CAPTCHA) whereas "nobody" does not require a login. |
| 22 | The site administrator can also create logins with |
| 23 | passwords for specific individuals. |
| 24 | |
| 25 | Users without the <b>[./caps/ref.html#h | Hyperlink]</b> capability |
| 26 | do not see most Fossil-generated hyperlinks. This is |
| 27 | a simple defense against spiders, since [./caps/#ucat | the "nobody" |
| 28 | user category] does not have this capability by default. |
| 29 | Users must log in (perhaps as |
| 30 | "anonymous") before they can see any of the hyperlinks. A spider |
| 31 | that cannot log into your Fossil repository will be unable to walk |
| 32 | its historical check-ins, create diffs between versions, pull zip |
| 33 | archives, etc. by visiting links, because they aren't there. |
| 34 | |
| 35 | A text message appears at the top of each page in this situation to |
| 36 | invite humans to log in as anonymous in order to activate hyperlinks. |
| 37 | |
| 38 | Because this required login step is annoying to some, |
| 39 | Fossil provides other techniques for blocking spiders which |
| 40 | are less cumbersome to humans. |
| 41 | |
| 42 | <h2>Automatic Hyperlinks Based on UserAgent</h2> |
| 43 | |
| 44 | Fossil has the ability to selectively enable hyperlinks for users |
| 45 | that lack the <b>Hyperlink</b> capability based on their UserAgent string in the |
| 46 | HTTP request header and on the browsers ability to run Javascript. |
| 47 | |
| 48 | The UserAgent string is a text identifier that is included in the header |
| 49 | of most HTTP requests that identifies the specific maker and version of |
| 50 | the browser (or spider) that generated the request. Typical UserAgent |
| @@ -76,11 +73,11 @@ | |
| 73 | |
| 74 | In Fossil, under the Admin/Access menu, there is a setting entitled |
| 75 | "<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>". |
| 76 | If this setting is enabled, and if the UserAgent string looks like a |
| 77 | human and not a spider, then Fossil will enable hyperlinks even if |
| 78 | the <b>Hyperlink</b> capability is omitted from the user permissions. This setting |
| 79 | gives humans easy access to the hyperlinks while preventing spiders |
| 80 | from walking the millions of pages on a typical Fossil site. |
| 81 | |
| 82 | But the hyperlinks are not enabled directly with the setting above. |
| 83 | Instead, the HTML code that is generated contains anchor tags ("<a>") |
| @@ -92,11 +89,11 @@ | |
| 89 | UserAgent string. Most spiders do not bother to run JavaScript and |
| 90 | so to the spider the empty anchor tag will be useless. But all modern |
| 91 | web browsers implement JavaScript, so hyperlinks will show up |
| 92 | normally for human users. |
| 93 | |
| 94 | <h2>Further Defenses</h2> |
| 95 | |
| 96 | Recently (as of this writing, in the spring of 2013) the Fossil server |
| 97 | on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly |
| 98 | by Chinese spiders that use forged UserAgent strings to make them look |
| 99 | like normal web browsers and which interpret JavaScript. We do not |
| @@ -134,11 +131,11 @@ | |
| 131 | |
| 132 | See also [./loadmgmt.md|Managing Server Load] for a description |
| 133 | of how expensive pages can be disabled when the server is under heavy |
| 134 | load. |
| 135 | |
| 136 | <h2>The Ongoing Struggle</h2> |
| 137 | |
| 138 | Fossil currently does a very good job of providing easy access to humans |
| 139 | while keeping out troublesome robots and spiders. However, spiders and |
| 140 | bots continue to grow more sophisticated, requiring ever more advanced |
| 141 | defenses. This "arms race" is unlikely to ever end. The developers of |
| 142 |
+5
-5
| --- www/cgi.wiki | ||
| +++ www/cgi.wiki | ||
| @@ -67,11 +67,11 @@ | ||
| 67 | 67 | of the HTTP request does not correspond to any Fossil repository, then |
| 68 | 68 | the request redirects to URL. |
| 69 | 69 | |
| 70 | 70 | <h2 id="repolist">repolist</h2> |
| 71 | 71 | |
| 72 | -This is a boolean property. | |
| 72 | +This is a Boolean property. | |
| 73 | 73 | If it is present, and if the [#directory:|<b>directory:</b>] option is used, |
| 74 | 74 | and if the PATH_INFO string is empty, then Fossil will show a list |
| 75 | 75 | of available Fossil repositories. |
| 76 | 76 | |
| 77 | 77 | The "skin" of the reply is determined by the first |
| @@ -100,15 +100,15 @@ | ||
| 100 | 100 | If N is zero, then there is no timeout. If this property is omitted, |
| 101 | 101 | then the default timeout is 300 seconds (5 minutes). |
| 102 | 102 | |
| 103 | 103 | <h2 id="localauth">localauth</h2> |
| 104 | 104 | |
| 105 | -This is a boolean property. | |
| 106 | -If it is present, setup administrator privileges | |
| 107 | -(capability letter 's') are granted to any HTTP request that | |
| 105 | +This is a Boolean property. | |
| 106 | +If it is present, [./caps/ref.html#s | setup capability] | |
| 107 | +is granted to any HTTP request that | |
| 108 | 108 | comes in over a loopback interface, such as 127.0.0.1. |
| 109 | -and if the PATH_INFO string is empty, then Fossil will show a list | |
| 109 | +If the PATH_INFO string is empty, Fossil will show a list | |
| 110 | 110 | of available Fossil repositories. |
| 111 | 111 | |
| 112 | 112 | <h2 id="skin">skin: <i>NAME</i></h2> |
| 113 | 113 | |
| 114 | 114 | If NAME is the name of one of the built-in skins supported by Fossil, |
| 115 | 115 |
| --- www/cgi.wiki | |
| +++ www/cgi.wiki | |
| @@ -67,11 +67,11 @@ | |
| 67 | of the HTTP request does not correspond to any Fossil repository, then |
| 68 | the request redirects to URL. |
| 69 | |
| 70 | <h2 id="repolist">repolist</h2> |
| 71 | |
| 72 | This is a boolean property. |
| 73 | If it is present, and if the [#directory:|<b>directory:</b>] option is used, |
| 74 | and if the PATH_INFO string is empty, then Fossil will show a list |
| 75 | of available Fossil repositories. |
| 76 | |
| 77 | The "skin" of the reply is determined by the first |
| @@ -100,15 +100,15 @@ | |
| 100 | If N is zero, then there is no timeout. If this property is omitted, |
| 101 | then the default timeout is 300 seconds (5 minutes). |
| 102 | |
| 103 | <h2 id="localauth">localauth</h2> |
| 104 | |
| 105 | This is a boolean property. |
| 106 | If it is present, setup administrator privileges |
| 107 | (capability letter 's') are granted to any HTTP request that |
| 108 | comes in over a loopback interface, such as 127.0.0.1. |
| 109 | and if the PATH_INFO string is empty, then Fossil will show a list |
| 110 | of available Fossil repositories. |
| 111 | |
| 112 | <h2 id="skin">skin: <i>NAME</i></h2> |
| 113 | |
| 114 | If NAME is the name of one of the built-in skins supported by Fossil, |
| 115 |
| --- www/cgi.wiki | |
| +++ www/cgi.wiki | |
| @@ -67,11 +67,11 @@ | |
| 67 | of the HTTP request does not correspond to any Fossil repository, then |
| 68 | the request redirects to URL. |
| 69 | |
| 70 | <h2 id="repolist">repolist</h2> |
| 71 | |
| 72 | This is a Boolean property. |
| 73 | If it is present, and if the [#directory:|<b>directory:</b>] option is used, |
| 74 | and if the PATH_INFO string is empty, then Fossil will show a list |
| 75 | of available Fossil repositories. |
| 76 | |
| 77 | The "skin" of the reply is determined by the first |
| @@ -100,15 +100,15 @@ | |
| 100 | If N is zero, then there is no timeout. If this property is omitted, |
| 101 | then the default timeout is 300 seconds (5 minutes). |
| 102 | |
| 103 | <h2 id="localauth">localauth</h2> |
| 104 | |
| 105 | This is a Boolean property. |
| 106 | If it is present, [./caps/ref.html#s | setup capability] |
| 107 | is granted to any HTTP request that |
| 108 | comes in over a loopback interface, such as 127.0.0.1. |
| 109 | If the PATH_INFO string is empty, Fossil will show a list |
| 110 | of available Fossil repositories. |
| 111 | |
| 112 | <h2 id="skin">skin: <i>NAME</i></h2> |
| 113 | |
| 114 | If NAME is the name of one of the built-in skins supported by Fossil, |
| 115 |
+1
-1
| --- www/custom_ticket.wiki | ||
| +++ www/custom_ticket.wiki | ||
| @@ -83,11 +83,11 @@ | ||
| 83 | 83 | <td align="right">Opened by:</td><td bgcolor="#d0d0d0"> |
| 84 | 84 | $<opened_by> |
| 85 | 85 | </td> |
| 86 | 86 | </pre> |
| 87 | 87 | This will add a row which displays these two fields, in the event the user has |
| 88 | -"edit" capability. | |
| 88 | +<a href="./caps/ref.html#w">ticket "edit" capability</a>. | |
| 89 | 89 | </p> |
| 90 | 90 | </blockquote> |
| 91 | 91 | |
| 92 | 92 | <h2>Modify the 'edit ticket' page</h2><blockquote> |
| 93 | 93 | <p> |
| 94 | 94 |
| --- www/custom_ticket.wiki | |
| +++ www/custom_ticket.wiki | |
| @@ -83,11 +83,11 @@ | |
| 83 | <td align="right">Opened by:</td><td bgcolor="#d0d0d0"> |
| 84 | $<opened_by> |
| 85 | </td> |
| 86 | </pre> |
| 87 | This will add a row which displays these two fields, in the event the user has |
| 88 | "edit" capability. |
| 89 | </p> |
| 90 | </blockquote> |
| 91 | |
| 92 | <h2>Modify the 'edit ticket' page</h2><blockquote> |
| 93 | <p> |
| 94 |
| --- www/custom_ticket.wiki | |
| +++ www/custom_ticket.wiki | |
| @@ -83,11 +83,11 @@ | |
| 83 | <td align="right">Opened by:</td><td bgcolor="#d0d0d0"> |
| 84 | $<opened_by> |
| 85 | </td> |
| 86 | </pre> |
| 87 | This will add a row which displays these two fields, in the event the user has |
| 88 | <a href="./caps/ref.html#w">ticket "edit" capability</a>. |
| 89 | </p> |
| 90 | </blockquote> |
| 91 | |
| 92 | <h2>Modify the 'edit ticket' page</h2><blockquote> |
| 93 | <p> |
| 94 |
+34
-42
| --- www/forum.wiki | ||
| +++ www/forum.wiki | ||
| @@ -74,14 +74,14 @@ | ||
| 74 | 74 | third-party forum software and mailing list search engines, your |
| 75 | 75 | links are only valid until the third-party component changes its |
| 76 | 76 | URL scheme or disappears from the web. |
| 77 | 77 | |
| 78 | 78 | * <b>Role-Based Access Control:</b> The forum uses the same |
| 79 | - [https://en.wikipedia.org/wiki/Role-based_access_control | RBAC | |
| 79 | + [./caps/ | capability-based access control | |
| 80 | 80 | system] that Fossil uses to control all other repository accesses. |
| 81 | - The Fossil forum feature simply adds several new fine-grained | |
| 82 | - capability bits to the existing system. | |
| 81 | + The Fossil forum feature simply adds [./caps/ref.html#2 | several new fine-grained | |
| 82 | + capabilities] to the existing system. | |
| 83 | 83 | |
| 84 | 84 | * <b>Enduring, Open File Format:</b> Since Fossil has an |
| 85 | 85 | [./fileformat.wiki | open and well-documented file format], your |
| 86 | 86 | discussion archives are truly that: <em>archives</em>. You are no |
| 87 | 87 | longer dependent on the lifetime and business model of a |
| @@ -109,39 +109,37 @@ | ||
| 109 | 109 | |
| 110 | 110 | <h2 id="setup">Setting up a Fossil Forum</h2> |
| 111 | 111 | |
| 112 | 112 | <h3 id="caps">Capabilities</h3> |
| 113 | 113 | |
| 114 | -Fossil forums use the same [./capability.md | role-based access control | |
| 115 | -mechanism] as for normal Fossil repository logins. There are | |
| 116 | -[./capability.md#2 | several dedicated forum-related capabilities] you | |
| 117 | -can grant to a user. | |
| 118 | - | |
| 119 | 114 | By default, no Fossil user has permission to use the forums except for |
| 120 | 115 | users with Setup and Admin capabilities, which get these as part of the |
| 121 | 116 | large package of other capabilities they get. |
| 122 | 117 | |
| 123 | 118 | For public Fossil repositories that wish to accept new users without |
| 124 | 119 | involving a human, go into Admin → Access and enable the "Allow |
| 125 | 120 | users to register themselves" setting. You may also wish to give users |
| 126 | -in the <tt>anonymous</tt> category the Read Forum (2) and Write Forum | |
| 127 | -(3) capabilities: this allows people to post without creating an account | |
| 121 | +in [./caps/#ucat | the <tt>anonymous</tt> user category] the | |
| 122 | +<b>[./caps/ref.html#2 | RdForum]</b> and | |
| 123 | +<b>[./caps/ref.html#3 | WrForum]</b> | |
| 124 | +capabilities: this allows people to post without creating an account | |
| 128 | 125 | simply by solving [./antibot.wiki | a simple CAPTCHA]. |
| 129 | 126 | |
| 130 | 127 | For a private repository, you probably won't want to give the |
| 131 | 128 | <tt>anonymous</tt> user any forum access, but you may wish to give the |
| 132 | -Read Forum capability (2) to users in the <tt>reader</tt> category. | |
| 129 | +<b>RdForum</b> capability to users in the <tt>reader</tt> category. | |
| 133 | 130 | |
| 134 | 131 | For either type of repository, you are likely to want to give at least |
| 135 | -the WriteTrusted capability (4) to users in the <tt>developer</tt> | |
| 136 | -category. If you did not give the Read Forum capability (2) to | |
| 132 | +the <b>[./caps/ref.html#4 | WrTForum]</b> capability to users in the <tt>developer</tt> | |
| 133 | +category. If you did not give the <b>RdForum</b> capability to | |
| 137 | 134 | <tt>anonymous</tt> above, you should give <tt>developer</tt> that |
| 138 | -capability here if you choose to give it capability 3 or 4. | |
| 135 | +capability here if you choose to give it <b>WrForum</b> or | |
| 136 | +<b>WrTForum</b> capability. | |
| 139 | 137 | |
| 140 | 138 | If you want to use the email alert feature, by default only those |
| 141 | 139 | users in the Setup and Admin user categories can make use of it. Grant |
| 142 | -the Email Alerts capability (7) to give others access to this feature. | |
| 140 | +the <b>[./caps/ref.html#7 | EmailAlert]</b> capability to give others access to this feature. | |
| 143 | 141 | Alternately, you can handle alert signups outside of Fossil, with |
| 144 | 142 | a Setup or Admin users manually signing users up via Admin → |
| 145 | 143 | Notification. You'll want to grant this capability to the |
| 146 | 144 | <tt>nobody</tt> user category if you want anyone to sign up without any |
| 147 | 145 | restrictions. Give it to <tt>anonymous</tt> instead if you want the |
| @@ -150,11 +148,11 @@ | ||
| 150 | 148 | logins to have this ability. (That's assuming you give one or both of |
| 151 | 149 | these capabilities to every user on your Fossil repository.) |
| 152 | 150 | |
| 153 | 151 | By following this advice, you should not need to tediously add |
| 154 | 152 | capabilities to individual accounts except in atypical cases, such as |
| 155 | -to grant the Moderate Forum capability (5) to an uncommonly | |
| 153 | +to grant the <b>[./caps/ref.html#5 | ModForum]</b> capability to an uncommonly | |
| 156 | 154 | highly-trusted user. |
| 157 | 155 | |
| 158 | 156 | |
| 159 | 157 | <h3 id="skin">Skin Setup</h3> |
| 160 | 158 | |
| @@ -186,13 +184,13 @@ | ||
| 186 | 184 | if {[anycap 23456] || [anoncap 2] || [anoncap 3]} { |
| 187 | 185 | menulink /forum Forum |
| 188 | 186 | } |
| 189 | 187 | </verbatim> |
| 190 | 188 | |
| 191 | -These rules say that any logged-in user with any forum-related | |
| 192 | -capability (2-6 inclusive, as of this writing) or an anonymous user with | |
| 193 | -read or write capability on the forum (2, 3) will see the "Forum" navbar | |
| 189 | +These rules say that any logged-in user with any [./caps/ref.html#2 | | |
| 190 | +forum-related capability] or an anonymous user <b>RdForum</b> or | |
| 191 | +<b>WrForum</b> capability will see the "Forum" navbar | |
| 194 | 192 | link, which just takes you to <tt>/forum</tt>. |
| 195 | 193 | |
| 196 | 194 | The exact code you need here varies depending on which skin you're |
| 197 | 195 | using. Follow the style you see for the other navbar links. |
| 198 | 196 | |
| @@ -279,14 +277,11 @@ | ||
| 279 | 277 | |
| 280 | 278 | Yet, what of the users who will have logins on both repositories? Some |
| 281 | 279 | users will be trusted with access to the project's main Fossil |
| 282 | 280 | repository, and these users will probably also participate in the |
| 283 | 281 | project's Fossil-hosted forum. Fossil has a feature to solve this |
| 284 | -problem which is probably less well known than it should be, and which | |
| 285 | -has been a feature of Fossil since April of 2011: Admin → | |
| 286 | -Login-Group. This allows one Fossil repository to recognize users | |
| 287 | -authorized on a different Fossil repository. | |
| 282 | +problem: [./caps/login-groups.md | login groups]. | |
| 288 | 283 | |
| 289 | 284 | |
| 290 | 285 | <h3 id="alerts">Email Alerts (a.k.a. Notifications)</h3> |
| 291 | 286 | |
| 292 | 287 | Internet email service has become rather complicated since its initial |
| @@ -303,20 +298,18 @@ | ||
| 303 | 298 | |
| 304 | 299 | There are many paths to a repository's Fossil forum: |
| 305 | 300 | |
| 306 | 301 | <ul> |
| 307 | 302 | <li> |
| 308 | - <p>If you're using the default Fossil skin as shipped with Fossil | |
| 309 | - 2.7 or one updated to include the changes since 2.6 or prior, there | |
| 310 | - is a Forum button in the navbar which appears for users with any of | |
| 311 | - the forum-related user capabilities: 2 through 6 inclusive for those | |
| 312 | - with repository logins, or caps 2 and 3 for users without a user | |
| 313 | - account but who have solved the Anonymous user CAPTCHA.</p> | |
| 314 | - <p>This button will not appear in the default skin for such users if | |
| 315 | - their browser window is not greater than 1200 pixels wide. The | |
| 303 | + If you're using the default Fossil skin as shipped with Fossil | |
| 304 | + 2.7+ or one [#skin | updated] to support it, there | |
| 305 | + is a Forum button in the navbar which appears for users able to | |
| 306 | + access the forum. With the default skin, that button will only | |
| 307 | + appear if the user's browser window is at least | |
| 308 | + 1200 pixels wide. The | |
| 316 | 309 | Fossil admin can adjust this limit in the skin's CSS section, down |
| 317 | - near the bottom in the definition of the `wideonly` style.</p> | |
| 310 | + near the bottom in the definition of the `wideonly` style. | |
| 318 | 311 | </li> |
| 319 | 312 | |
| 320 | 313 | <li>The other stock skins have this button in them as of 2.7 as well, |
| 321 | 314 | without the screen width restriction, since the navbar in those skins |
| 322 | 315 | wraps on narrow screens more gracefully than the default skin |
| @@ -344,11 +337,11 @@ | ||
| 344 | 337 | |
| 345 | 338 | * create a new post |
| 346 | 339 | * reply to an existing post |
| 347 | 340 | * edit a post or reply |
| 348 | 341 | |
| 349 | -When a person with the normal <b>Write Forum</b> capability (<tt>3</tt>) | |
| 342 | +When a person with the normal <b>WrForum</b> capability | |
| 350 | 343 | updates the forum, Fossil saves the update in its block chain, but this |
| 351 | 344 | update is impermanent because of two other table updates made at the |
| 352 | 345 | same time: |
| 353 | 346 | |
| 354 | 347 | <ol> |
| @@ -362,14 +355,13 @@ | ||
| 362 | 355 | what causes Fossil to leave out the Reply button when rendering that |
| 363 | 356 | post's HTML in the forum's web interface.</li> |
| 364 | 357 | </ol> |
| 365 | 358 | |
| 366 | 359 | When a moderator approves an update, Fossil deletes these table entries, |
| 367 | -making the update semi-permanent. This changes how Fossil renders the | |
| 360 | +making the update [./shunning.wiki | semi-permanent]. This changes how Fossil renders the | |
| 368 | 361 | HTML for that update. It also means the artifact will now sync to |
| 369 | -clones, if the sync is done by a user with <b>Check-Out</b> capability | |
| 370 | -(<tt>o</tt>). | |
| 362 | +users with <b>[./caps/ref.html#g | Clone]</b> capability. | |
| 371 | 363 | |
| 372 | 364 | When a forum user edits a moderator-approved artifact, what actually |
| 373 | 365 | happens under the hood is that Fossil writes another artifact to the |
| 374 | 366 | repository which refers to the original version as its parent, causing |
| 375 | 367 | Fossil UI to present the new version instead of the original. The |
| @@ -379,11 +371,11 @@ | ||
| 379 | 371 | |
| 380 | 372 | When you "Delete" a moderator-approved post or reply through Fossil UI, |
| 381 | 373 | it's actually an edit with blank replacement content. The only way to |
| 382 | 374 | truly delete such artifacts is through [./shunning.wiki | shunning]. |
| 383 | 375 | |
| 384 | -When a user with <b>WriteTrusted Forum</b> capability (<tt>4</tt>) | |
| 376 | +When a user with <b>WrTForum</b> capability | |
| 385 | 377 | updates the forum, it happens in the same way except that Fossil skips |
| 386 | 378 | the <tt>private</tt> and <tt>modreq</tt> table insertions. |
| 387 | 379 | |
| 388 | 380 | When a moderator rejects an update, that artifact is unceremoniously |
| 389 | 381 | removed from the tip of the block chain. This is safe because Fossil |
| @@ -398,21 +390,21 @@ | ||
| 398 | 390 | Having described all of the work that Fossil performs under the hood on |
| 399 | 391 | behalf of its users, we can now give the short list of work left for the |
| 400 | 392 | repository's administrators and moderators: |
| 401 | 393 | |
| 402 | 394 | <ol> |
| 403 | - <li>Add the <b>Moderate Forum</b> capability (<tt>5</tt>) to any of | |
| 395 | + <li>Add the <b>[./caps/ref.html#5 | ModForum]</b> capability to any of | |
| 404 | 396 | your users who should have this ability. You don't need to do this |
| 405 | - for any user with Setup (<tt>s</tt>) or Admin (<tt>a</tt>) | |
| 406 | - capability; it's | |
| 397 | + for any user with <b>[./caps/ref.html#s | Setup]</b> or | |
| 398 | + <b>[./caps/ref.html#a | Admin]</b> capability; it's | |
| 407 | 399 | [http://fossil-scm.org/index.html/artifact/b16221ffb736caa2?ln=1246-1257 |
| 408 | 400 | | already included].</li> |
| 409 | 401 | |
| 410 | 402 | <li>When someone updates the forum, an entry will appear in the |
| 411 | 403 | timeline if the type filter is set to "Forum" or "Any Type". If that |
| 412 | - user has only the <b>Write Forum</b> capability (<tt>3</tt>), any | |
| 413 | - other user with the <b>Moderate Forum</b> capability (<tt>5</tt>) | |
| 404 | + user has only the <b>WrForum</b> capability, any | |
| 405 | + other user with the <b>ModForum</b> capability | |
| 414 | 406 | will see a conditional link appear at the top of the main forum |
| 415 | 407 | page: "Moderation Requests". Clicking this takes the moderator to |
| 416 | 408 | the <tt>/modreq</tt> page. A moderator may wish to keep the main |
| 417 | 409 | forum page open in a browser tab, reloading it occasionally to see |
| 418 | 410 | when the "Moderation Requests" link reappears.</li> |
| 419 | 411 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -74,14 +74,14 @@ | |
| 74 | third-party forum software and mailing list search engines, your |
| 75 | links are only valid until the third-party component changes its |
| 76 | URL scheme or disappears from the web. |
| 77 | |
| 78 | * <b>Role-Based Access Control:</b> The forum uses the same |
| 79 | [https://en.wikipedia.org/wiki/Role-based_access_control | RBAC |
| 80 | system] that Fossil uses to control all other repository accesses. |
| 81 | The Fossil forum feature simply adds several new fine-grained |
| 82 | capability bits to the existing system. |
| 83 | |
| 84 | * <b>Enduring, Open File Format:</b> Since Fossil has an |
| 85 | [./fileformat.wiki | open and well-documented file format], your |
| 86 | discussion archives are truly that: <em>archives</em>. You are no |
| 87 | longer dependent on the lifetime and business model of a |
| @@ -109,39 +109,37 @@ | |
| 109 | |
| 110 | <h2 id="setup">Setting up a Fossil Forum</h2> |
| 111 | |
| 112 | <h3 id="caps">Capabilities</h3> |
| 113 | |
| 114 | Fossil forums use the same [./capability.md | role-based access control |
| 115 | mechanism] as for normal Fossil repository logins. There are |
| 116 | [./capability.md#2 | several dedicated forum-related capabilities] you |
| 117 | can grant to a user. |
| 118 | |
| 119 | By default, no Fossil user has permission to use the forums except for |
| 120 | users with Setup and Admin capabilities, which get these as part of the |
| 121 | large package of other capabilities they get. |
| 122 | |
| 123 | For public Fossil repositories that wish to accept new users without |
| 124 | involving a human, go into Admin → Access and enable the "Allow |
| 125 | users to register themselves" setting. You may also wish to give users |
| 126 | in the <tt>anonymous</tt> category the Read Forum (2) and Write Forum |
| 127 | (3) capabilities: this allows people to post without creating an account |
| 128 | simply by solving [./antibot.wiki | a simple CAPTCHA]. |
| 129 | |
| 130 | For a private repository, you probably won't want to give the |
| 131 | <tt>anonymous</tt> user any forum access, but you may wish to give the |
| 132 | Read Forum capability (2) to users in the <tt>reader</tt> category. |
| 133 | |
| 134 | For either type of repository, you are likely to want to give at least |
| 135 | the WriteTrusted capability (4) to users in the <tt>developer</tt> |
| 136 | category. If you did not give the Read Forum capability (2) to |
| 137 | <tt>anonymous</tt> above, you should give <tt>developer</tt> that |
| 138 | capability here if you choose to give it capability 3 or 4. |
| 139 | |
| 140 | If you want to use the email alert feature, by default only those |
| 141 | users in the Setup and Admin user categories can make use of it. Grant |
| 142 | the Email Alerts capability (7) to give others access to this feature. |
| 143 | Alternately, you can handle alert signups outside of Fossil, with |
| 144 | a Setup or Admin users manually signing users up via Admin → |
| 145 | Notification. You'll want to grant this capability to the |
| 146 | <tt>nobody</tt> user category if you want anyone to sign up without any |
| 147 | restrictions. Give it to <tt>anonymous</tt> instead if you want the |
| @@ -150,11 +148,11 @@ | |
| 150 | logins to have this ability. (That's assuming you give one or both of |
| 151 | these capabilities to every user on your Fossil repository.) |
| 152 | |
| 153 | By following this advice, you should not need to tediously add |
| 154 | capabilities to individual accounts except in atypical cases, such as |
| 155 | to grant the Moderate Forum capability (5) to an uncommonly |
| 156 | highly-trusted user. |
| 157 | |
| 158 | |
| 159 | <h3 id="skin">Skin Setup</h3> |
| 160 | |
| @@ -186,13 +184,13 @@ | |
| 186 | if {[anycap 23456] || [anoncap 2] || [anoncap 3]} { |
| 187 | menulink /forum Forum |
| 188 | } |
| 189 | </verbatim> |
| 190 | |
| 191 | These rules say that any logged-in user with any forum-related |
| 192 | capability (2-6 inclusive, as of this writing) or an anonymous user with |
| 193 | read or write capability on the forum (2, 3) will see the "Forum" navbar |
| 194 | link, which just takes you to <tt>/forum</tt>. |
| 195 | |
| 196 | The exact code you need here varies depending on which skin you're |
| 197 | using. Follow the style you see for the other navbar links. |
| 198 | |
| @@ -279,14 +277,11 @@ | |
| 279 | |
| 280 | Yet, what of the users who will have logins on both repositories? Some |
| 281 | users will be trusted with access to the project's main Fossil |
| 282 | repository, and these users will probably also participate in the |
| 283 | project's Fossil-hosted forum. Fossil has a feature to solve this |
| 284 | problem which is probably less well known than it should be, and which |
| 285 | has been a feature of Fossil since April of 2011: Admin → |
| 286 | Login-Group. This allows one Fossil repository to recognize users |
| 287 | authorized on a different Fossil repository. |
| 288 | |
| 289 | |
| 290 | <h3 id="alerts">Email Alerts (a.k.a. Notifications)</h3> |
| 291 | |
| 292 | Internet email service has become rather complicated since its initial |
| @@ -303,20 +298,18 @@ | |
| 303 | |
| 304 | There are many paths to a repository's Fossil forum: |
| 305 | |
| 306 | <ul> |
| 307 | <li> |
| 308 | <p>If you're using the default Fossil skin as shipped with Fossil |
| 309 | 2.7 or one updated to include the changes since 2.6 or prior, there |
| 310 | is a Forum button in the navbar which appears for users with any of |
| 311 | the forum-related user capabilities: 2 through 6 inclusive for those |
| 312 | with repository logins, or caps 2 and 3 for users without a user |
| 313 | account but who have solved the Anonymous user CAPTCHA.</p> |
| 314 | <p>This button will not appear in the default skin for such users if |
| 315 | their browser window is not greater than 1200 pixels wide. The |
| 316 | Fossil admin can adjust this limit in the skin's CSS section, down |
| 317 | near the bottom in the definition of the `wideonly` style.</p> |
| 318 | </li> |
| 319 | |
| 320 | <li>The other stock skins have this button in them as of 2.7 as well, |
| 321 | without the screen width restriction, since the navbar in those skins |
| 322 | wraps on narrow screens more gracefully than the default skin |
| @@ -344,11 +337,11 @@ | |
| 344 | |
| 345 | * create a new post |
| 346 | * reply to an existing post |
| 347 | * edit a post or reply |
| 348 | |
| 349 | When a person with the normal <b>Write Forum</b> capability (<tt>3</tt>) |
| 350 | updates the forum, Fossil saves the update in its block chain, but this |
| 351 | update is impermanent because of two other table updates made at the |
| 352 | same time: |
| 353 | |
| 354 | <ol> |
| @@ -362,14 +355,13 @@ | |
| 362 | what causes Fossil to leave out the Reply button when rendering that |
| 363 | post's HTML in the forum's web interface.</li> |
| 364 | </ol> |
| 365 | |
| 366 | When a moderator approves an update, Fossil deletes these table entries, |
| 367 | making the update semi-permanent. This changes how Fossil renders the |
| 368 | HTML for that update. It also means the artifact will now sync to |
| 369 | clones, if the sync is done by a user with <b>Check-Out</b> capability |
| 370 | (<tt>o</tt>). |
| 371 | |
| 372 | When a forum user edits a moderator-approved artifact, what actually |
| 373 | happens under the hood is that Fossil writes another artifact to the |
| 374 | repository which refers to the original version as its parent, causing |
| 375 | Fossil UI to present the new version instead of the original. The |
| @@ -379,11 +371,11 @@ | |
| 379 | |
| 380 | When you "Delete" a moderator-approved post or reply through Fossil UI, |
| 381 | it's actually an edit with blank replacement content. The only way to |
| 382 | truly delete such artifacts is through [./shunning.wiki | shunning]. |
| 383 | |
| 384 | When a user with <b>WriteTrusted Forum</b> capability (<tt>4</tt>) |
| 385 | updates the forum, it happens in the same way except that Fossil skips |
| 386 | the <tt>private</tt> and <tt>modreq</tt> table insertions. |
| 387 | |
| 388 | When a moderator rejects an update, that artifact is unceremoniously |
| 389 | removed from the tip of the block chain. This is safe because Fossil |
| @@ -398,21 +390,21 @@ | |
| 398 | Having described all of the work that Fossil performs under the hood on |
| 399 | behalf of its users, we can now give the short list of work left for the |
| 400 | repository's administrators and moderators: |
| 401 | |
| 402 | <ol> |
| 403 | <li>Add the <b>Moderate Forum</b> capability (<tt>5</tt>) to any of |
| 404 | your users who should have this ability. You don't need to do this |
| 405 | for any user with Setup (<tt>s</tt>) or Admin (<tt>a</tt>) |
| 406 | capability; it's |
| 407 | [http://fossil-scm.org/index.html/artifact/b16221ffb736caa2?ln=1246-1257 |
| 408 | | already included].</li> |
| 409 | |
| 410 | <li>When someone updates the forum, an entry will appear in the |
| 411 | timeline if the type filter is set to "Forum" or "Any Type". If that |
| 412 | user has only the <b>Write Forum</b> capability (<tt>3</tt>), any |
| 413 | other user with the <b>Moderate Forum</b> capability (<tt>5</tt>) |
| 414 | will see a conditional link appear at the top of the main forum |
| 415 | page: "Moderation Requests". Clicking this takes the moderator to |
| 416 | the <tt>/modreq</tt> page. A moderator may wish to keep the main |
| 417 | forum page open in a browser tab, reloading it occasionally to see |
| 418 | when the "Moderation Requests" link reappears.</li> |
| 419 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -74,14 +74,14 @@ | |
| 74 | third-party forum software and mailing list search engines, your |
| 75 | links are only valid until the third-party component changes its |
| 76 | URL scheme or disappears from the web. |
| 77 | |
| 78 | * <b>Role-Based Access Control:</b> The forum uses the same |
| 79 | [./caps/ | capability-based access control |
| 80 | system] that Fossil uses to control all other repository accesses. |
| 81 | The Fossil forum feature simply adds [./caps/ref.html#2 | several new fine-grained |
| 82 | capabilities] to the existing system. |
| 83 | |
| 84 | * <b>Enduring, Open File Format:</b> Since Fossil has an |
| 85 | [./fileformat.wiki | open and well-documented file format], your |
| 86 | discussion archives are truly that: <em>archives</em>. You are no |
| 87 | longer dependent on the lifetime and business model of a |
| @@ -109,39 +109,37 @@ | |
| 109 | |
| 110 | <h2 id="setup">Setting up a Fossil Forum</h2> |
| 111 | |
| 112 | <h3 id="caps">Capabilities</h3> |
| 113 | |
| 114 | By default, no Fossil user has permission to use the forums except for |
| 115 | users with Setup and Admin capabilities, which get these as part of the |
| 116 | large package of other capabilities they get. |
| 117 | |
| 118 | For public Fossil repositories that wish to accept new users without |
| 119 | involving a human, go into Admin → Access and enable the "Allow |
| 120 | users to register themselves" setting. You may also wish to give users |
| 121 | in [./caps/#ucat | the <tt>anonymous</tt> user category] the |
| 122 | <b>[./caps/ref.html#2 | RdForum]</b> and |
| 123 | <b>[./caps/ref.html#3 | WrForum]</b> |
| 124 | capabilities: this allows people to post without creating an account |
| 125 | simply by solving [./antibot.wiki | a simple CAPTCHA]. |
| 126 | |
| 127 | For a private repository, you probably won't want to give the |
| 128 | <tt>anonymous</tt> user any forum access, but you may wish to give the |
| 129 | <b>RdForum</b> capability to users in the <tt>reader</tt> category. |
| 130 | |
| 131 | For either type of repository, you are likely to want to give at least |
| 132 | the <b>[./caps/ref.html#4 | WrTForum]</b> capability to users in the <tt>developer</tt> |
| 133 | category. If you did not give the <b>RdForum</b> capability to |
| 134 | <tt>anonymous</tt> above, you should give <tt>developer</tt> that |
| 135 | capability here if you choose to give it <b>WrForum</b> or |
| 136 | <b>WrTForum</b> capability. |
| 137 | |
| 138 | If you want to use the email alert feature, by default only those |
| 139 | users in the Setup and Admin user categories can make use of it. Grant |
| 140 | the <b>[./caps/ref.html#7 | EmailAlert]</b> capability to give others access to this feature. |
| 141 | Alternately, you can handle alert signups outside of Fossil, with |
| 142 | a Setup or Admin users manually signing users up via Admin → |
| 143 | Notification. You'll want to grant this capability to the |
| 144 | <tt>nobody</tt> user category if you want anyone to sign up without any |
| 145 | restrictions. Give it to <tt>anonymous</tt> instead if you want the |
| @@ -150,11 +148,11 @@ | |
| 148 | logins to have this ability. (That's assuming you give one or both of |
| 149 | these capabilities to every user on your Fossil repository.) |
| 150 | |
| 151 | By following this advice, you should not need to tediously add |
| 152 | capabilities to individual accounts except in atypical cases, such as |
| 153 | to grant the <b>[./caps/ref.html#5 | ModForum]</b> capability to an uncommonly |
| 154 | highly-trusted user. |
| 155 | |
| 156 | |
| 157 | <h3 id="skin">Skin Setup</h3> |
| 158 | |
| @@ -186,13 +184,13 @@ | |
| 184 | if {[anycap 23456] || [anoncap 2] || [anoncap 3]} { |
| 185 | menulink /forum Forum |
| 186 | } |
| 187 | </verbatim> |
| 188 | |
| 189 | These rules say that any logged-in user with any [./caps/ref.html#2 | |
| 190 | forum-related capability] or an anonymous user <b>RdForum</b> or |
| 191 | <b>WrForum</b> capability will see the "Forum" navbar |
| 192 | link, which just takes you to <tt>/forum</tt>. |
| 193 | |
| 194 | The exact code you need here varies depending on which skin you're |
| 195 | using. Follow the style you see for the other navbar links. |
| 196 | |
| @@ -279,14 +277,11 @@ | |
| 277 | |
| 278 | Yet, what of the users who will have logins on both repositories? Some |
| 279 | users will be trusted with access to the project's main Fossil |
| 280 | repository, and these users will probably also participate in the |
| 281 | project's Fossil-hosted forum. Fossil has a feature to solve this |
| 282 | problem: [./caps/login-groups.md | login groups]. |
| 283 | |
| 284 | |
| 285 | <h3 id="alerts">Email Alerts (a.k.a. Notifications)</h3> |
| 286 | |
| 287 | Internet email service has become rather complicated since its initial |
| @@ -303,20 +298,18 @@ | |
| 298 | |
| 299 | There are many paths to a repository's Fossil forum: |
| 300 | |
| 301 | <ul> |
| 302 | <li> |
| 303 | If you're using the default Fossil skin as shipped with Fossil |
| 304 | 2.7+ or one [#skin | updated] to support it, there |
| 305 | is a Forum button in the navbar which appears for users able to |
| 306 | access the forum. With the default skin, that button will only |
| 307 | appear if the user's browser window is at least |
| 308 | 1200 pixels wide. The |
| 309 | Fossil admin can adjust this limit in the skin's CSS section, down |
| 310 | near the bottom in the definition of the `wideonly` style. |
| 311 | </li> |
| 312 | |
| 313 | <li>The other stock skins have this button in them as of 2.7 as well, |
| 314 | without the screen width restriction, since the navbar in those skins |
| 315 | wraps on narrow screens more gracefully than the default skin |
| @@ -344,11 +337,11 @@ | |
| 337 | |
| 338 | * create a new post |
| 339 | * reply to an existing post |
| 340 | * edit a post or reply |
| 341 | |
| 342 | When a person with the normal <b>WrForum</b> capability |
| 343 | updates the forum, Fossil saves the update in its block chain, but this |
| 344 | update is impermanent because of two other table updates made at the |
| 345 | same time: |
| 346 | |
| 347 | <ol> |
| @@ -362,14 +355,13 @@ | |
| 355 | what causes Fossil to leave out the Reply button when rendering that |
| 356 | post's HTML in the forum's web interface.</li> |
| 357 | </ol> |
| 358 | |
| 359 | When a moderator approves an update, Fossil deletes these table entries, |
| 360 | making the update [./shunning.wiki | semi-permanent]. This changes how Fossil renders the |
| 361 | HTML for that update. It also means the artifact will now sync to |
| 362 | users with <b>[./caps/ref.html#g | Clone]</b> capability. |
| 363 | |
| 364 | When a forum user edits a moderator-approved artifact, what actually |
| 365 | happens under the hood is that Fossil writes another artifact to the |
| 366 | repository which refers to the original version as its parent, causing |
| 367 | Fossil UI to present the new version instead of the original. The |
| @@ -379,11 +371,11 @@ | |
| 371 | |
| 372 | When you "Delete" a moderator-approved post or reply through Fossil UI, |
| 373 | it's actually an edit with blank replacement content. The only way to |
| 374 | truly delete such artifacts is through [./shunning.wiki | shunning]. |
| 375 | |
| 376 | When a user with <b>WrTForum</b> capability |
| 377 | updates the forum, it happens in the same way except that Fossil skips |
| 378 | the <tt>private</tt> and <tt>modreq</tt> table insertions. |
| 379 | |
| 380 | When a moderator rejects an update, that artifact is unceremoniously |
| 381 | removed from the tip of the block chain. This is safe because Fossil |
| @@ -398,21 +390,21 @@ | |
| 390 | Having described all of the work that Fossil performs under the hood on |
| 391 | behalf of its users, we can now give the short list of work left for the |
| 392 | repository's administrators and moderators: |
| 393 | |
| 394 | <ol> |
| 395 | <li>Add the <b>[./caps/ref.html#5 | ModForum]</b> capability to any of |
| 396 | your users who should have this ability. You don't need to do this |
| 397 | for any user with <b>[./caps/ref.html#s | Setup]</b> or |
| 398 | <b>[./caps/ref.html#a | Admin]</b> capability; it's |
| 399 | [http://fossil-scm.org/index.html/artifact/b16221ffb736caa2?ln=1246-1257 |
| 400 | | already included].</li> |
| 401 | |
| 402 | <li>When someone updates the forum, an entry will appear in the |
| 403 | timeline if the type filter is set to "Forum" or "Any Type". If that |
| 404 | user has only the <b>WrForum</b> capability, any |
| 405 | other user with the <b>ModForum</b> capability |
| 406 | will see a conditional link appear at the top of the main forum |
| 407 | page: "Moderation Requests". Clicking this takes the moderator to |
| 408 | the <tt>/modreq</tt> page. A moderator may wish to keep the main |
| 409 | forum page open in a browser tab, reloading it occasionally to see |
| 410 | when the "Moderation Requests" link reappears.</li> |
| 411 |
+1
-2
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -65,12 +65,11 @@ | ||
| 65 | 65 | [./bugtheory.wiki | ticketing & bug tracking], |
| 66 | 66 | [./embeddeddoc.wiki | embedded documentation], |
| 67 | 67 | [./event.wiki | technical notes], and a [./forum.wiki | web forum], |
| 68 | 68 | all within a single nicely-designed [./customskin.md|skinnable] web |
| 69 | 69 | [/help?cmd=ui|UI], |
| 70 | -protected by a fine-grained | |
| 71 | -[https://en.wikipedia.org/wiki/Role-based_access_control|role-based | |
| 70 | +protected by [./caps/ | a fine-grained role-based | |
| 72 | 71 | access control system]. |
| 73 | 72 | These additional capabilities are available for Git as 3rd-party |
| 74 | 73 | add-ons, but with Fossil they are integrated into |
| 75 | 74 | the design. One way to describe Fossil is that it is |
| 76 | 75 | "[https://github.com/ | GitHub]-in-a-box." |
| 77 | 76 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -65,12 +65,11 @@ | |
| 65 | [./bugtheory.wiki | ticketing & bug tracking], |
| 66 | [./embeddeddoc.wiki | embedded documentation], |
| 67 | [./event.wiki | technical notes], and a [./forum.wiki | web forum], |
| 68 | all within a single nicely-designed [./customskin.md|skinnable] web |
| 69 | [/help?cmd=ui|UI], |
| 70 | protected by a fine-grained |
| 71 | [https://en.wikipedia.org/wiki/Role-based_access_control|role-based |
| 72 | access control system]. |
| 73 | These additional capabilities are available for Git as 3rd-party |
| 74 | add-ons, but with Fossil they are integrated into |
| 75 | the design. One way to describe Fossil is that it is |
| 76 | "[https://github.com/ | GitHub]-in-a-box." |
| 77 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -65,12 +65,11 @@ | |
| 65 | [./bugtheory.wiki | ticketing & bug tracking], |
| 66 | [./embeddeddoc.wiki | embedded documentation], |
| 67 | [./event.wiki | technical notes], and a [./forum.wiki | web forum], |
| 68 | all within a single nicely-designed [./customskin.md|skinnable] web |
| 69 | [/help?cmd=ui|UI], |
| 70 | protected by [./caps/ | a fine-grained role-based |
| 71 | access control system]. |
| 72 | These additional capabilities are available for Git as 3rd-party |
| 73 | add-ons, but with Fossil they are integrated into |
| 74 | the design. One way to describe Fossil is that it is |
| 75 | "[https://github.com/ | GitHub]-in-a-box." |
| 76 |
+4
-4
| --- www/server/index.html | ||
| +++ www/server/index.html | ||
| @@ -274,14 +274,14 @@ | ||
| 274 | 274 | <p>After the server is up and running, log into it as the Setup user and |
| 275 | 275 | visit the Admin menu to finish configuring that repository for |
| 276 | 276 | service:</p> |
| 277 | 277 | |
| 278 | 278 | <ol> |
| 279 | - <li><p>Add user accounts for your other team members. Use the | |
| 280 | - pre-defined user capabilities to define access policies rather than | |
| 281 | - give out those same set of capabilities redundantly to each | |
| 282 | - user.</p></li> | |
| 279 | + <li><p>Add user accounts for your other team members. Use <a | |
| 280 | + href="../caps/index.md#ucat">categories</a> to define access policies | |
| 281 | + rather than redundantly give each new user the same <a | |
| 282 | + href="../caps/index.md#ucap">individual capabilities</a>.</p></li> | |
| 283 | 283 | |
| 284 | 284 | <li><p>Test access to the repository from each category of non-Setup |
| 285 | 285 | user that you created. You may have to give your user categories some |
| 286 | 286 | overlooked capabilities, particularly if you followed <a |
| 287 | 287 | href="#prep">our earlier advice</a> to take the repository private |
| 288 | 288 |
| --- www/server/index.html | |
| +++ www/server/index.html | |
| @@ -274,14 +274,14 @@ | |
| 274 | <p>After the server is up and running, log into it as the Setup user and |
| 275 | visit the Admin menu to finish configuring that repository for |
| 276 | service:</p> |
| 277 | |
| 278 | <ol> |
| 279 | <li><p>Add user accounts for your other team members. Use the |
| 280 | pre-defined user capabilities to define access policies rather than |
| 281 | give out those same set of capabilities redundantly to each |
| 282 | user.</p></li> |
| 283 | |
| 284 | <li><p>Test access to the repository from each category of non-Setup |
| 285 | user that you created. You may have to give your user categories some |
| 286 | overlooked capabilities, particularly if you followed <a |
| 287 | href="#prep">our earlier advice</a> to take the repository private |
| 288 |
| --- www/server/index.html | |
| +++ www/server/index.html | |
| @@ -274,14 +274,14 @@ | |
| 274 | <p>After the server is up and running, log into it as the Setup user and |
| 275 | visit the Admin menu to finish configuring that repository for |
| 276 | service:</p> |
| 277 | |
| 278 | <ol> |
| 279 | <li><p>Add user accounts for your other team members. Use <a |
| 280 | href="../caps/index.md#ucat">categories</a> to define access policies |
| 281 | rather than redundantly give each new user the same <a |
| 282 | href="../caps/index.md#ucap">individual capabilities</a>.</p></li> |
| 283 | |
| 284 | <li><p>Test access to the repository from each category of non-Setup |
| 285 | user that you created. You may have to give your user categories some |
| 286 | overlooked capabilities, particularly if you followed <a |
| 287 | href="#prep">our earlier advice</a> to take the repository private |
| 288 |
+2
-2
| --- www/serverext.wiki | ||
| +++ www/serverext.wiki | ||
| @@ -172,11 +172,11 @@ | ||
| 172 | 172 | * FOSSIL_USER |
| 173 | 173 | |
| 174 | 174 | The FOSSIL_USER string is the name of the logged-in user. This variable |
| 175 | 175 | is missing or is an empty string if the user is not logged in. The |
| 176 | 176 | FOSSIL_CAPABILITIES string is a list of |
| 177 | -[/setup_ulist_notes|Fossil capability letters] that | |
| 177 | +[./caps/ref.html|Fossil capabilities] that | |
| 178 | 178 | indicate what permissions the user has on the Fossil repository. |
| 179 | 179 | The FOSSIL_REPOSITORY environment variable gives the filename of the |
| 180 | 180 | Fossil repository that is running. The FOSSIL_URI variable shows the |
| 181 | 181 | prefix of the REQUEST_URI that is the Fossil CGI script, or is an |
| 182 | 182 | empty string if Fossil is being run by some method other than CGI. |
| @@ -289,13 +289,13 @@ | ||
| 289 | 289 | have been adjusted accordingly and that all resources needed by the |
| 290 | 290 | CGI program are available within the chroot jail. |
| 291 | 291 | |
| 292 | 292 | If anything goes wrong while trying to process an /ext page, Fossil |
| 293 | 293 | returns a 404 Not Found error with no details. However, if the requester |
| 294 | -is logged in as a user that has Debug privilege (capability letter "D") | |
| 294 | +is logged in as a user that has <b>[./caps/ref.html#D | Debug]</b> capability | |
| 295 | 295 | then additional diagnostic information may be included in the output. |
| 296 | 296 | |
| 297 | 297 | If the /ext page has a "fossil-ext-debug=1" query parameter and if |
| 298 | 298 | the requester is logged in as a user with Debug privilege, then the |
| 299 | 299 | CGI output is returned verbatim, as text/plain and with the original |
| 300 | 300 | header intact. This is useful for trying diagnosing problems with the |
| 301 | 301 | CGI script. |
| 302 | 302 |
| --- www/serverext.wiki | |
| +++ www/serverext.wiki | |
| @@ -172,11 +172,11 @@ | |
| 172 | * FOSSIL_USER |
| 173 | |
| 174 | The FOSSIL_USER string is the name of the logged-in user. This variable |
| 175 | is missing or is an empty string if the user is not logged in. The |
| 176 | FOSSIL_CAPABILITIES string is a list of |
| 177 | [/setup_ulist_notes|Fossil capability letters] that |
| 178 | indicate what permissions the user has on the Fossil repository. |
| 179 | The FOSSIL_REPOSITORY environment variable gives the filename of the |
| 180 | Fossil repository that is running. The FOSSIL_URI variable shows the |
| 181 | prefix of the REQUEST_URI that is the Fossil CGI script, or is an |
| 182 | empty string if Fossil is being run by some method other than CGI. |
| @@ -289,13 +289,13 @@ | |
| 289 | have been adjusted accordingly and that all resources needed by the |
| 290 | CGI program are available within the chroot jail. |
| 291 | |
| 292 | If anything goes wrong while trying to process an /ext page, Fossil |
| 293 | returns a 404 Not Found error with no details. However, if the requester |
| 294 | is logged in as a user that has Debug privilege (capability letter "D") |
| 295 | then additional diagnostic information may be included in the output. |
| 296 | |
| 297 | If the /ext page has a "fossil-ext-debug=1" query parameter and if |
| 298 | the requester is logged in as a user with Debug privilege, then the |
| 299 | CGI output is returned verbatim, as text/plain and with the original |
| 300 | header intact. This is useful for trying diagnosing problems with the |
| 301 | CGI script. |
| 302 |
| --- www/serverext.wiki | |
| +++ www/serverext.wiki | |
| @@ -172,11 +172,11 @@ | |
| 172 | * FOSSIL_USER |
| 173 | |
| 174 | The FOSSIL_USER string is the name of the logged-in user. This variable |
| 175 | is missing or is an empty string if the user is not logged in. The |
| 176 | FOSSIL_CAPABILITIES string is a list of |
| 177 | [./caps/ref.html|Fossil capabilities] that |
| 178 | indicate what permissions the user has on the Fossil repository. |
| 179 | The FOSSIL_REPOSITORY environment variable gives the filename of the |
| 180 | Fossil repository that is running. The FOSSIL_URI variable shows the |
| 181 | prefix of the REQUEST_URI that is the Fossil CGI script, or is an |
| 182 | empty string if Fossil is being run by some method other than CGI. |
| @@ -289,13 +289,13 @@ | |
| 289 | have been adjusted accordingly and that all resources needed by the |
| 290 | CGI program are available within the chroot jail. |
| 291 | |
| 292 | If anything goes wrong while trying to process an /ext page, Fossil |
| 293 | returns a 404 Not Found error with no details. However, if the requester |
| 294 | is logged in as a user that has <b>[./caps/ref.html#D | Debug]</b> capability |
| 295 | then additional diagnostic information may be included in the output. |
| 296 | |
| 297 | If the /ext page has a "fossil-ext-debug=1" query parameter and if |
| 298 | the requester is logged in as a user with Debug privilege, then the |
| 299 | CGI output is returned verbatim, as text/plain and with the original |
| 300 | header intact. This is useful for trying diagnosing problems with the |
| 301 | CGI script. |
| 302 |