Fossil SCM
Merged caps-doc branch down to trunk, improving documentation of user capabilities in Fossil.
Commit
779ddefa190931fd55d5df2d2467632aa0df69bef74294e9b322e1c950f98c45
Parent
c5561039e1fffe3…
21 files changed
+1
-1
+1
-1
-6
+15
-9
+21
-24
+8
-5
+9
+64
+39
+6
+35
+5
-5
+1
-1
+1
-1
+1
-1
+34
-66
+4
-5
+4
-1
+16
-7
+5
-5
+2
-2
~
src/capabilities.c
~
src/main.c
-
www/admin-v-setup.md
~
www/alerts.md
~
www/antibot.wiki
~
www/caps/admin-v-setup.md
+
www/caps/admin-v-setup.md
~
www/caps/impl.md
~
www/caps/index.md
~
www/caps/login-groups.md
~
www/caps/ref.html
~
www/cgi.wiki
~
www/custom_ticket.wiki
~
www/defcsp.md
~
www/defcsp.md
~
www/forum.wiki
~
www/fossil-v-git.wiki
~
www/mkindex.tcl
~
www/permutedindex.html
~
www/server/index.html
~
www/serverext.wiki
+1
-1
| --- src/capabilities.c | ||
| +++ src/capabilities.c | ||
| @@ -297,11 +297,11 @@ | ||
| 297 | 297 | { '4', CAPCLASS_FORUM, 0, |
| 298 | 298 | "Forum-Trusted", "Create forum messages that bypass moderation" }, |
| 299 | 299 | { '5', CAPCLASS_FORUM|CAPCLASS_SUPER, 0, |
| 300 | 300 | "Forum-Mod", "Moderator for forum messages" }, |
| 301 | 301 | { '6', CAPCLASS_FORUM|CAPCLASS_SUPER, 0, |
| 302 | - "Forum-Admin", "Set or remove capability '4' from other users" }, | |
| 302 | + "Forum-Admin", "Grant capability '4' to other users" }, | |
| 303 | 303 | { '7', CAPCLASS_ALERT, 0, |
| 304 | 304 | "Alerts", "Sign up for email alerts" }, |
| 305 | 305 | { 'A', CAPCLASS_ALERT|CAPCLASS_SUPER, 0, |
| 306 | 306 | "Announce", "Send announcements to all subscribers" }, |
| 307 | 307 | { 'D', CAPCLASS_OTHER, 0, |
| 308 | 308 |
| --- src/capabilities.c | |
| +++ src/capabilities.c | |
| @@ -297,11 +297,11 @@ | |
| 297 | { '4', CAPCLASS_FORUM, 0, |
| 298 | "Forum-Trusted", "Create forum messages that bypass moderation" }, |
| 299 | { '5', CAPCLASS_FORUM|CAPCLASS_SUPER, 0, |
| 300 | "Forum-Mod", "Moderator for forum messages" }, |
| 301 | { '6', CAPCLASS_FORUM|CAPCLASS_SUPER, 0, |
| 302 | "Forum-Admin", "Set or remove capability '4' from other users" }, |
| 303 | { '7', CAPCLASS_ALERT, 0, |
| 304 | "Alerts", "Sign up for email alerts" }, |
| 305 | { 'A', CAPCLASS_ALERT|CAPCLASS_SUPER, 0, |
| 306 | "Announce", "Send announcements to all subscribers" }, |
| 307 | { 'D', CAPCLASS_OTHER, 0, |
| 308 |
| --- src/capabilities.c | |
| +++ src/capabilities.c | |
| @@ -297,11 +297,11 @@ | |
| 297 | { '4', CAPCLASS_FORUM, 0, |
| 298 | "Forum-Trusted", "Create forum messages that bypass moderation" }, |
| 299 | { '5', CAPCLASS_FORUM|CAPCLASS_SUPER, 0, |
| 300 | "Forum-Mod", "Moderator for forum messages" }, |
| 301 | { '6', CAPCLASS_FORUM|CAPCLASS_SUPER, 0, |
| 302 | "Forum-Admin", "Grant capability '4' to other users" }, |
| 303 | { '7', CAPCLASS_ALERT, 0, |
| 304 | "Alerts", "Sign up for email alerts" }, |
| 305 | { 'A', CAPCLASS_ALERT|CAPCLASS_SUPER, 0, |
| 306 | "Announce", "Send announcements to all subscribers" }, |
| 307 | { 'D', CAPCLASS_OTHER, 0, |
| 308 |
+1
-1
| --- src/main.c | ||
| +++ src/main.c | ||
| @@ -105,11 +105,11 @@ | ||
| 105 | 105 | char WrUnver; /* y: can push unversioned content */ |
| 106 | 106 | char RdForum; /* 2: Read forum posts */ |
| 107 | 107 | char WrForum; /* 3: Create new forum posts */ |
| 108 | 108 | char WrTForum; /* 4: Post to forums not subject to moderation */ |
| 109 | 109 | char ModForum; /* 5: Moderate (approve or reject) forum posts */ |
| 110 | - char AdminForum; /* 6: Set or remove capability 4 on other users */ | |
| 110 | + char AdminForum; /* 6: Grant capability 4 to other users */ | |
| 111 | 111 | char EmailAlert; /* 7: Sign up for email notifications */ |
| 112 | 112 | char Announce; /* A: Send announcements */ |
| 113 | 113 | char Debug; /* D: show extra Fossil debugging features */ |
| 114 | 114 | /* These last two are included to block infinite recursion */ |
| 115 | 115 | char XReader; /* u: Inherit all privileges of "reader" */ |
| 116 | 116 | |
| 117 | 117 | DELETED www/admin-v-setup.md |
| --- src/main.c | |
| +++ src/main.c | |
| @@ -105,11 +105,11 @@ | |
| 105 | char WrUnver; /* y: can push unversioned content */ |
| 106 | char RdForum; /* 2: Read forum posts */ |
| 107 | char WrForum; /* 3: Create new forum posts */ |
| 108 | char WrTForum; /* 4: Post to forums not subject to moderation */ |
| 109 | char ModForum; /* 5: Moderate (approve or reject) forum posts */ |
| 110 | char AdminForum; /* 6: Set or remove capability 4 on other users */ |
| 111 | char EmailAlert; /* 7: Sign up for email notifications */ |
| 112 | char Announce; /* A: Send announcements */ |
| 113 | char Debug; /* D: show extra Fossil debugging features */ |
| 114 | /* These last two are included to block infinite recursion */ |
| 115 | char XReader; /* u: Inherit all privileges of "reader" */ |
| 116 | |
| 117 | ELETED www/admin-v-setup.md |
| --- src/main.c | |
| +++ src/main.c | |
| @@ -105,11 +105,11 @@ | |
| 105 | char WrUnver; /* y: can push unversioned content */ |
| 106 | char RdForum; /* 2: Read forum posts */ |
| 107 | char WrForum; /* 3: Create new forum posts */ |
| 108 | char WrTForum; /* 4: Post to forums not subject to moderation */ |
| 109 | char ModForum; /* 5: Moderate (approve or reject) forum posts */ |
| 110 | char AdminForum; /* 6: Grant capability 4 to other users */ |
| 111 | char EmailAlert; /* 7: Sign up for email notifications */ |
| 112 | char Announce; /* A: Send announcements */ |
| 113 | char Debug; /* D: show extra Fossil debugging features */ |
| 114 | /* These last two are included to block infinite recursion */ |
| 115 | char XReader; /* u: Inherit all privileges of "reader" */ |
| 116 | |
| 117 | ELETED www/admin-v-setup.md |
D
www/admin-v-setup.md
-6
| --- a/www/admin-v-setup.md | ||
| +++ b/www/admin-v-setup.md | ||
| @@ -1,6 +0,0 @@ | ||
| 1 | -# The Differences Between theilitiestween Sthe power hierarcKeep Several of the Fossil user capabilities form a clear power hierarchy. | |
| 2 | -Mathematically speaking: | |
| 3 | - | |
| 4 | -> *Setup > Admin > Moderator > User > Subsc# The Differences Betw | |
| 5 | -o@3x,g@4j,j@5O,rE@6z,2rO@yg,7:[ucap]:W@3ln,G:setup_ucap_list | |
| 6 | -12p~Gn; |
| --- a/www/admin-v-setup.md | |
| +++ b/www/admin-v-setup.md | |
| @@ -1,6 +0,0 @@ | |
| 1 | # The Differences Between theilitiestween Sthe power hierarcKeep Several of the Fossil user capabilities form a clear power hierarchy. |
| 2 | Mathematically speaking: |
| 3 | |
| 4 | > *Setup > Admin > Moderator > User > Subsc# The Differences Betw |
| 5 | o@3x,g@4j,j@5O,rE@6z,2rO@yg,7:[ucap]:W@3ln,G:setup_ucap_list |
| 6 | 12p~Gn; |
| --- a/www/admin-v-setup.md | |
| +++ b/www/admin-v-setup.md | |
| @@ -1,6 +0,0 @@ | |
+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 | |
| 146 | 143 | ADDED www/caps/admin-v-setup.md |
| 147 | 144 | ADDED www/caps/impl.md |
| 148 | 145 | ADDED www/caps/index.md |
| 149 | 146 | ADDED www/caps/login-groups.md |
| 150 | 147 | ADDED www/caps/ref.html |
| --- 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 | |
| 146 | DDED www/caps/admin-v-setup.md |
| 147 | DDED www/caps/impl.md |
| 148 | DDED www/caps/index.md |
| 149 | DDED www/caps/login-groups.md |
| 150 | DDED www/caps/ref.html |
| --- 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 | |
| 143 | DDED www/caps/admin-v-setup.md |
| 144 | DDED www/caps/impl.md |
| 145 | DDED www/caps/index.md |
| 146 | DDED www/caps/login-groups.md |
| 147 | DDED www/caps/ref.html |
+8
-5
| --- a/www/caps/admin-v-setup.md | ||
| +++ b/www/caps/admin-v-setup.md | ||
| @@ -1,6 +1,9 @@ | ||
| 1 | -# The Differences Between theilitiestween Sthe power hierarcKeep Several of the Fossil user capabilities form a clear power hierarchy. | |
| 2 | -Mathematically speaking: | |
| 1 | +# Differences Btween Sthe power hierarcKeep in mind that | |
| 2 | +which means that a usuknown tomight haveevauThe exception to this is when the clone is done as a Setup user, since | |
| 3 | +this also copiesthe `user` table on theies. In this way, /antibot.wiki) | |
| 3 | 4 | |
| 4 | -> *Setup > Admin > Moderator > User > Subsc# The Differences Betw | |
| 5 | -o@3x,g@4j,j@5O,rE@6z,2rO@yg,7:[ucap]:W@3ln,G:setup_ucap_list | |
| 6 | -12p~Gn; | |
| 5 | +[au]: geable clones. This is useful not o, it is a useful element of a load balancing and | |
| 6 | +failover system# Differences Between Sthe power hierarchy laid out at tblock | |
| 7 | +chain][bc], blockchainblockchainblockchainTH [`fossil | |
| 8 | + (“y”) | |
| 9 | + ’s discretion“y” capthis powerful capability(./shunning.wiki)(./blockchain.md)./alerts.md**WrUnver**](./ref.html#y). (That lone hold-out is [by design][snoy].) |
| --- a/www/caps/admin-v-setup.md | |
| +++ b/www/caps/admin-v-setup.md | |
| @@ -1,6 +1,9 @@ | |
| 1 | # The Differences Between theilitiestween Sthe power hierarcKeep Several of the Fossil user capabilities form a clear power hierarchy. |
| 2 | Mathematically speaking: |
| 3 | |
| 4 | > *Setup > Admin > Moderator > User > Subsc# The Differences Betw |
| 5 | o@3x,g@4j,j@5O,rE@6z,2rO@yg,7:[ucap]:W@3ln,G:setup_ucap_list |
| 6 | 12p~Gn; |
| --- a/www/caps/admin-v-setup.md | |
| +++ b/www/caps/admin-v-setup.md | |
| @@ -1,6 +1,9 @@ | |
| 1 | # Differences Btween Sthe power hierarcKeep in mind that |
| 2 | which means that a usuknown tomight haveevauThe exception to this is when the clone is done as a Setup user, since |
| 3 | this also copiesthe `user` table on theies. In this way, /antibot.wiki) |
| 4 | |
| 5 | [au]: geable clones. This is useful not o, it is a useful element of a load balancing and |
| 6 | failover system# Differences Between Sthe power hierarchy laid out at tblock |
| 7 | chain][bc], blockchainblockchainblockchainTH [`fossil |
| 8 | (“y”) |
| 9 | ’s discretion“y” capthis powerful capability(./shunning.wiki)(./blockchain.md)./alerts.md**WrUnver**](./ref.html#y). (That lone hold-out is [by design][snoy].) |
| --- a/www/caps/admin-v-setup.md | ||
| +++ b/www/caps/admin-v-setup.md | ||
| @@ -0,0 +1,9 @@ | ||
| 1 | +# Differences Btween Sthe power hierarcKeep in mind that | |
| 2 | +which means that a usuknown tomight haveevauThe exception to this is when the clone is done as a Setup user, since | |
| 3 | +this also copiesthe `user` table on theies. In this way, /antibot.wiki) | |
| 4 | + | |
| 5 | +[au]: geable clones. This is useful not o, it is a useful element of a load balancing and | |
| 6 | +failover system# Differences Between Sthe power hierarchy laid out at tblock | |
| 7 | +chain][bc], blockchainblockchainblockchainTH [`fossil | |
| 8 | + (“y”) | |
| 9 | + ’s discretion“y” capthis powerful capability(./shunning.wiki)(./blockchain.md)./alerts.md**WrUnver**](./ref.html#y). (That lone hold-out is [by design][snoy].) |
| --- a/www/caps/admin-v-setup.md | |
| +++ b/www/caps/admin-v-setup.md | |
| @@ -0,0 +1,9 @@ | |
| --- a/www/caps/admin-v-setup.md | |
| +++ b/www/caps/admin-v-setup.md | |
| @@ -0,0 +1,9 @@ | |
| 1 | # Differences Btween Sthe power hierarcKeep in mind that |
| 2 | which means that a usuknown tomight haveevauThe exception to this is when the clone is done as a Setup user, since |
| 3 | this also copiesthe `user` table on theies. In this way, /antibot.wiki) |
| 4 | |
| 5 | [au]: geable clones. This is useful not o, it is a useful element of a load balancing and |
| 6 | failover system# Differences Between Sthe power hierarchy laid out at tblock |
| 7 | chain][bc], blockchainblockchainblockchainTH [`fossil |
| 8 | (“y”) |
| 9 | ’s discretion“y” capthis powerful capability(./shunning.wiki)(./blockchain.md)./alerts.md**WrUnver**](./ref.html#y). (That lone hold-out is [by design][snoy].) |
+64
| --- a/www/caps/impl.md | ||
| +++ b/www/caps/impl.md | ||
| @@ -0,0 +1,64 @@ | ||
| 1 | +# Implementation Details onameUser Capabilities | |
| 2 | + | |
| 3 | +## <a id="choices"></a>Capability Letter Choices | |
| 4 | + | |
| 5 | +We [assigned][ref] user capability characters using only lowercase ASCII | |
| 6 | +letters at first, so those are the most important within Fossil: they | |
| 7 | +control the functions most core to Fossil’s operation. Once we used up | |
| 8 | +most of the lowercase letters, we started using uppercase, and then | |
| 9 | +during the development of the [forum feature][for] we assigned most of | |
| 10 | +the decimal numerals. All of the lowercase ASCII letters are now | |
| 11 | +assigned. Eventually, we might have to start using ASCII | |
| 12 | +punctuation and symbols. We expect to run out of reasons to define new caps before | |
| 13 | +we’re forced to switch to Unicode, though the possibilities for [mnemonic][mn] | |
| 14 | +assignments with emoji are intriguing. <span style="vertical-align: | |
| 15 | +bottom">😉</span> | |
| 16 | + | |
| 17 | +The existing caps are usually mnemonic, especially among the | |
| 18 | +earliest and therefore most central assignments, made when we still had | |
| 19 | +lots of letters to choose from. There is still hope for good future | |
| 20 | +mnemonic assignments among the uppename="bitfield"></a>Why Not Bitfields? | |
| 21 | + | |
| 22 | +Some may question the use of ASCII character strings for [capability | |
| 23 | +sets][ucap] instead of bitfields, which are more efficient, both in | |
| 24 | +terms of storage and processing time. | |
| 25 | + | |
| 26 | +Fossil handles these character strings in one of two ways. For most HTTP | |
| 27 | +hitsblock chain[expands][sexp] the string into a [`struct` full of | |
| 28 | +flags][sff] so that later code can just do simple Boolean tests. In a | |
| 29 | +minority of cases, where Fossil only needs to check for the presence of | |
| 30 | +a single flag, it just does a [`strchr()` call][sc] on the string | |
| 31 | +instead. | |
| 32 | + | |
| 33 | +Both methods are slower than bit testing in a bitfield, but keep the | |
| 34 | +execution context in mind: at the front end of an HTTP request handler, | |
| 35 | +where the nanosecond differences in such implementation details are | |
| 36 | +completely swamped by the millisecond scale ping time of that repo’s | |
| 37 | +network connection, followed by the required I/O to satisfy the request. | |
| 38 | +Either method is plenty fast in that context. | |
| 39 | + | |
| 40 | +In exchange for this immeasurable cost per hit, we get human-readablname="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync? | |
| 41 | + | |
| 42 | +Fossil is more trusting about the content it receives from a remote | |
| 43 | +clone during sync than you might expect. Common manifestations of this | |
| 44 | +design choice are: | |
| 45 | + | |
| 46 | +1. A user may be able to impersonate other users. This can be | |
| 47 | + [accidental](./index.md#defuser) as well as purposeful. | |
| 48 | + | |
| 49 | +2. If your local system clock is out-of-sync with absolute time, | |
| 50 | + artifacts committed to that repo will appear with the “wrong” time | |
| 51 | + when sync’d. If the time sync error is big enough, it can make | |
| 52 | + check-ins appear to go back in time and other bad effects. | |
| 53 | + | |
| 54 | +3. You can purposely overwrite good timestamps with bad ones and push | |
| 55 | + those changes up to the remote with no interference, even though | |
| 56 | + Fossil tries to make that a Setup-only operation. | |
| 57 | + | |
| 58 | +All of this falls out of two of Fossil’s design choices: sync is | |
| 59 | +all-or-nothing, and [the Fossil hash tree][bc] is immutable. Fossil | |
| 60 | +would have to violate one or both of these principles to filter such | |
| 61 | +problems out of incoming syncs. | |
| 62 | + | |
| 63 | +We have considered auto-[shunning][shun] “bad” content on sync, but this | |
| 64 | +is [difficult][asd] due to [the design of th |
| --- a/www/caps/impl.md | |
| +++ b/www/caps/impl.md | |
| @@ -0,0 +1,64 @@ | |
| --- a/www/caps/impl.md | |
| +++ b/www/caps/impl.md | |
| @@ -0,0 +1,64 @@ | |
| 1 | # Implementation Details onameUser Capabilities |
| 2 | |
| 3 | ## <a id="choices"></a>Capability Letter Choices |
| 4 | |
| 5 | We [assigned][ref] user capability characters using only lowercase ASCII |
| 6 | letters at first, so those are the most important within Fossil: they |
| 7 | control the functions most core to Fossil’s operation. Once we used up |
| 8 | most of the lowercase letters, we started using uppercase, and then |
| 9 | during the development of the [forum feature][for] we assigned most of |
| 10 | the decimal numerals. All of the lowercase ASCII letters are now |
| 11 | assigned. Eventually, we might have to start using ASCII |
| 12 | punctuation and symbols. We expect to run out of reasons to define new caps before |
| 13 | we’re forced to switch to Unicode, though the possibilities for [mnemonic][mn] |
| 14 | assignments with emoji are intriguing. <span style="vertical-align: |
| 15 | bottom">😉</span> |
| 16 | |
| 17 | The existing caps are usually mnemonic, especially among the |
| 18 | earliest and therefore most central assignments, made when we still had |
| 19 | lots of letters to choose from. There is still hope for good future |
| 20 | mnemonic assignments among the uppename="bitfield"></a>Why Not Bitfields? |
| 21 | |
| 22 | Some may question the use of ASCII character strings for [capability |
| 23 | sets][ucap] instead of bitfields, which are more efficient, both in |
| 24 | terms of storage and processing time. |
| 25 | |
| 26 | Fossil handles these character strings in one of two ways. For most HTTP |
| 27 | hitsblock chain[expands][sexp] the string into a [`struct` full of |
| 28 | flags][sff] so that later code can just do simple Boolean tests. In a |
| 29 | minority of cases, where Fossil only needs to check for the presence of |
| 30 | a single flag, it just does a [`strchr()` call][sc] on the string |
| 31 | instead. |
| 32 | |
| 33 | Both methods are slower than bit testing in a bitfield, but keep the |
| 34 | execution context in mind: at the front end of an HTTP request handler, |
| 35 | where the nanosecond differences in such implementation details are |
| 36 | completely swamped by the millisecond scale ping time of that repo’s |
| 37 | network connection, followed by the required I/O to satisfy the request. |
| 38 | Either method is plenty fast in that context. |
| 39 | |
| 40 | In exchange for this immeasurable cost per hit, we get human-readablname="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync? |
| 41 | |
| 42 | Fossil is more trusting about the content it receives from a remote |
| 43 | clone during sync than you might expect. Common manifestations of this |
| 44 | design choice are: |
| 45 | |
| 46 | 1. A user may be able to impersonate other users. This can be |
| 47 | [accidental](./index.md#defuser) as well as purposeful. |
| 48 | |
| 49 | 2. If your local system clock is out-of-sync with absolute time, |
| 50 | artifacts committed to that repo will appear with the “wrong” time |
| 51 | when sync’d. If the time sync error is big enough, it can make |
| 52 | check-ins appear to go back in time and other bad effects. |
| 53 | |
| 54 | 3. You can purposely overwrite good timestamps with bad ones and push |
| 55 | those changes up to the remote with no interference, even though |
| 56 | Fossil tries to make that a Setup-only operation. |
| 57 | |
| 58 | All of this falls out of two of Fossil’s design choices: sync is |
| 59 | all-or-nothing, and [the Fossil hash tree][bc] is immutable. Fossil |
| 60 | would have to violate one or both of these principles to filter such |
| 61 | problems out of incoming syncs. |
| 62 | |
| 63 | We have considered auto-[shunning][shun] “bad” content on sync, but this |
| 64 | is [difficult][asd] due to [the design of th |
+39
| --- a/www/caps/index.md | ||
| +++ b/www/caps/index.md | ||
| @@ -0,0 +1,39 @@ | ||
| 1 | +local fileadding a | |
| 2 | +[**Se capability | |
| 3 | +namenamenamenamenamenamenamenamenamenamecap]. | |
| 4 | + | |
| 5 | + The SSH client command defaults to “`ssh -e none -T`” on most | |
| 6 | + platforms except Windows where it defaults to “`plink -ssh -T`”. | |
| 7 | + Yssh-command` | |
| 8 | + setticap]: https://fossil-scm.org/home/file?ci=8813ae91a699ac73&name=src%2Fmain.c&ln=2632-2637User caps only affect Fossil’s [UI pages][wp], remote operations over | |
| 9 | +`http[s]://` URLs, and [the JSON API][japi]. | |
| 10 | + | |
| 11 | +User caps *do not* affect operations done on a local repo opened via a | |
| 12 | +`file://` URL or a file system path. as sensible: | |
| 13 | +only localmatter when operating on a local SQLite DB | |
| 14 | +file. The same is true when working on a clone done over such a path, | |
| 15 | +except thAsat there are | |
| 16 | + | |
| 17 | +[sync][sync] with | |
| 18 | +effectively | |
| 19 | +both sides of the sync. | |
| 20 | + | |
| 21 | +What may surprise you is that user caps *also do not affect SSH!* When | |
| 22 | + | |
| 23 | +local clone, | |
| 24 | + | |
| 25 | +is on the local file system. If you can log into the remote system over | |
| 26 | + on that | |
| 27 | +, it isfor `file://` URLs. | |
| 28 | + | |
| 29 | +All��. | |
| 30 | + Yssh-command` | |
| 31 | + selocal fileadd | |
| 32 | +ie without cap checks. The SSH client defaults to “`ssh | |
| 33 | + -e none -T`” on most platforms, except on Windows where it defaults | |
| 34 | + ,n’t do this | |
| 35 | + withBecause both mechanisms work on local repos, the checks for capabilities | |
| 36 | +for | |
| 37 | +such URLs can never return “false,” because you are the [**Setup**][s] | |
| 38 | +user on both sides of the conversation. Such check | |
| 39 | +effect ddd][d][e][e][i][i]**: delete, |
| --- a/www/caps/index.md | |
| +++ b/www/caps/index.md | |
| @@ -0,0 +1,39 @@ | |
| --- a/www/caps/index.md | |
| +++ b/www/caps/index.md | |
| @@ -0,0 +1,39 @@ | |
| 1 | local fileadding a |
| 2 | [**Se capability |
| 3 | namenamenamenamenamenamenamenamenamenamecap]. |
| 4 | |
| 5 | The SSH client command defaults to “`ssh -e none -T`” on most |
| 6 | platforms except Windows where it defaults to “`plink -ssh -T`”. |
| 7 | Yssh-command` |
| 8 | setticap]: https://fossil-scm.org/home/file?ci=8813ae91a699ac73&name=src%2Fmain.c&ln=2632-2637User caps only affect Fossil’s [UI pages][wp], remote operations over |
| 9 | `http[s]://` URLs, and [the JSON API][japi]. |
| 10 | |
| 11 | User caps *do not* affect operations done on a local repo opened via a |
| 12 | `file://` URL or a file system path. as sensible: |
| 13 | only localmatter when operating on a local SQLite DB |
| 14 | file. The same is true when working on a clone done over such a path, |
| 15 | except thAsat there are |
| 16 | |
| 17 | [sync][sync] with |
| 18 | effectively |
| 19 | both sides of the sync. |
| 20 | |
| 21 | What may surprise you is that user caps *also do not affect SSH!* When |
| 22 | |
| 23 | local clone, |
| 24 | |
| 25 | is on the local file system. If you can log into the remote system over |
| 26 | on that |
| 27 | , it isfor `file://` URLs. |
| 28 | |
| 29 | All��. |
| 30 | Yssh-command` |
| 31 | selocal fileadd |
| 32 | ie without cap checks. The SSH client defaults to “`ssh |
| 33 | -e none -T`” on most platforms, except on Windows where it defaults |
| 34 | ,n’t do this |
| 35 | withBecause both mechanisms work on local repos, the checks for capabilities |
| 36 | for |
| 37 | such URLs can never return “false,” because you are the [**Setup**][s] |
| 38 | user on both sides of the conversation. Such check |
| 39 | effect ddd][d][e][e][i][i]**: delete, |
| --- a/www/caps/login-groups.md | ||
| +++ b/www/caps/login-groups.md | ||
| @@ -0,0 +1,6 @@ | ||
| 1 | +# Login Groups | |
| 2 | + | |
| 3 | +The Admin → Login-Groups UI feature and its corresponding [`login-groet of users all need access to, those users all | |
| 4 | +have the same access level on all oconfigure the us. With this configureIf repo C | |
| 5 | +joined repo B and repo B joined A, changes in C’s user table affect both | |
| 6 | +A and B, if you tell Fossil that the change applilogin group |
| --- a/www/caps/login-groups.md | |
| +++ b/www/caps/login-groups.md | |
| @@ -0,0 +1,6 @@ | |
| --- a/www/caps/login-groups.md | |
| +++ b/www/caps/login-groups.md | |
| @@ -0,0 +1,6 @@ | |
| 1 | # Login Groups |
| 2 | |
| 3 | The Admin → Login-Groups UI feature and its corresponding [`login-groet of users all need access to, those users all |
| 4 | have the same access level on all oconfigure the us. With this configureIf repo C |
| 5 | joined repo B and repo B joined A, changes in C’s user table affect both |
| 6 | A and B, if you tell Fossil that the change applilogin group |
+35
| --- a/www/caps/ref.html | ||
| +++ b/www/caps/ref.html | ||
| @@ -0,0 +1,35 @@ | ||
| 1 | +<div class='fossil This | |
| 2 | + letter was assigned by default to Developer in repos created with | |
| 3 | + Fossil 2.10 or earlier, but it has no effect in current or past | |
| 4 | +. Mnemonic: | |
| 5 | + repository contentits durable blockchain nature“key� page</a>’Dele<div class='fossil This<div cMnemonic: <b>d</b>ele“nobody�’<div class='fossil This | |
| 6 | + letter was assigned by default to Developer in repos created with | |
| 7 | + Fossil 2.10 or earlier, but it has no effect in current or past | |
| 8 | +. Mnemonic: | |
| 9 | + repository contentits durable blockchain natureis | |
| 10 | + letter was assigned“key”’ated with | |
| 11 | + Fossil 2.10 or earlier, but it has no effect in current or past | |
| 12 | +. Mnemonic: | |
| 13 | + repository contentits durable bl<div class='fossil This | |
| 14 | + letter was assigned by default to Developer in repos created with | |
| 15 | + Fossil 2.10 or earlier, but it has no effect in current or p’’“anonymous�“reader�“developer�“x�div class='fossil This | |
| 16 | + letter was assigned by default to Developer in repos created wit='fossil“hand over.�’“�iv class='fossil This | |
| 17 | + letter was assigned by default to Developer in repos created with | |
| 18 | + Fossil 2.10 or earlier, but it has no effect in curre letter�“Approve�’“I’�’ urrent or past | |
| 19 | +. Mnemonic: | |
| 20 | + repositorytter was assigned by default to Developer in repos created with | |
| 21 | + Fossil 2.10 or earlier, but it has no effect in current or p’’“anonymous�“reader�“developer�“x�div class='fossil This | |
| 22 | + letter was assigned by default to Developer in repos created wit='fossil“hand over.�’“�iv cl er was assigned by default to Developer in repos created with | |
| 23 | + Fossil 2.10 or earlier, but it has no effect in curre letterâ€�“Approveâ€�’“I’â€�’“nobody”’ <div class='fossil This | |
| 24 | + letter was assigned by default to Developer in repos created with | |
| 25 | + Fossil 2.10 or earlier, but it has no effect in current or past | |
| 26 | +. Mnemonic: | |
| 27 | + repository c | |
| 28 | + ’ os created with | |
| 29 | + Fossil 2.10 or earlier, but it has no effect in current or past | |
| 30 | +. Mnemonic: | |
| 31 | + repository contentits durable blockchain nature“keyâ€� page</a>’Dele<div class='fossil This<div cMnemonic: <b>d</b>ele“nobodyâ€�’<’ ’“anonymous”div class='fossil This | |
| 32 | + letter was assigned by default to Developer in repos created with | |
| 33 | + Fossil 2.10 or earlier, but it has no effect in current or past | |
| 34 | +. Mnemonic: | |
| 35 | + repository contentits durable blockchain nature“keyâ€� page</a>’Dele<div class='fossil This<div cMnemonic: <b>d</b>ele“nobodyâ€�’i“reader” “developer” “x”�om� “hand over.” ’ “” “”“Approve”’“I’” ’ |
| --- a/www/caps/ref.html | |
| +++ b/www/caps/ref.html | |
| @@ -0,0 +1,35 @@ | |
| --- a/www/caps/ref.html | |
| +++ b/www/caps/ref.html | |
| @@ -0,0 +1,35 @@ | |
| 1 | <div class='fossil This |
| 2 | letter was assigned by default to Developer in repos created with |
| 3 | Fossil 2.10 or earlier, but it has no effect in current or past |
| 4 | . Mnemonic: |
| 5 | repository contentits durable blockchain nature“key� page</a>’Dele<div class='fossil This<div cMnemonic: <b>d</b>ele“nobody�’<div class='fossil This |
| 6 | letter was assigned by default to Developer in repos created with |
| 7 | Fossil 2.10 or earlier, but it has no effect in current or past |
| 8 | . Mnemonic: |
| 9 | repository contentits durable blockchain natureis |
| 10 | letter was assigned“key”’ated with |
| 11 | Fossil 2.10 or earlier, but it has no effect in current or past |
| 12 | . Mnemonic: |
| 13 | repository contentits durable bl<div class='fossil This |
| 14 | letter was assigned by default to Developer in repos created with |
| 15 | Fossil 2.10 or earlier, but it has no effect in current or p’’“anonymous�“reader�“developer�“x�div class='fossil This |
| 16 | letter was assigned by default to Developer in repos created wit='fossil“hand over.�’“�iv class='fossil This |
| 17 | letter was assigned by default to Developer in repos created with |
| 18 | Fossil 2.10 or earlier, but it has no effect in curre letter�“Approve�’“I’�’ urrent or past |
| 19 | . Mnemonic: |
| 20 | repositorytter was assigned by default to Developer in repos created with |
| 21 | Fossil 2.10 or earlier, but it has no effect in current or p’’“anonymous�“reader�“developer�“x�div class='fossil This |
| 22 | letter was assigned by default to Developer in repos created wit='fossil“hand over.�’“�iv cl er was assigned by default to Developer in repos created with |
| 23 | Fossil 2.10 or earlier, but it has no effect in curre letterâ€�“Approveâ€�’“I’â€�’“nobody”’ <div class='fossil This |
| 24 | letter was assigned by default to Developer in repos created with |
| 25 | Fossil 2.10 or earlier, but it has no effect in current or past |
| 26 | . Mnemonic: |
| 27 | repository c |
| 28 | ’ os created with |
| 29 | Fossil 2.10 or earlier, but it has no effect in current or past |
| 30 | . Mnemonic: |
| 31 | repository contentits durable blockchain nature“keyâ€� page</a>’Dele<div class='fossil This<div cMnemonic: <b>d</b>ele“nobodyâ€�’<’ ’“anonymous”div class='fossil This |
| 32 | letter was assigned by default to Developer in repos created with |
| 33 | Fossil 2.10 or earlier, but it has no effect in current or past |
| 34 | . Mnemonic: |
| 35 | repository contentits durable blockchain nature“keyâ€� page</a>’Dele<div class='fossil This<div cMnemonic: <b>d</b>ele“nobodyâ€�’i“reader” “developer” “x”�om� “hand over.” ’ “” “”“Approve”’“I’” ’ |
+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 |
+1
-1
| --- www/defcsp.md | ||
| +++ www/defcsp.md | ||
| @@ -146,12 +146,12 @@ | ||
| 146 | 146 | CGI in the `FOSSIL_NONCE` environment variable, which it can then |
| 147 | 147 | use in `<script>` elements it generates. Because these extensions |
| 148 | 148 | can only be installed by the Fossil server’s system administrator, |
| 149 | 149 | this path is also considered safe. |
| 150 | 150 | |
| 151 | -[su]: ./admin-v-setup.md | |
| 152 | 151 | [ext]: ./serverext.wiki |
| 152 | +[su]: ./caps/admin-v-setup.md#apsu | |
| 153 | 153 | |
| 154 | 154 | |
| 155 | 155 | #### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities |
| 156 | 156 | |
| 157 | 157 | We’re so restrictive about how we treat JavaScript because it can lead |
| 158 | 158 |
| --- www/defcsp.md | |
| +++ www/defcsp.md | |
| @@ -146,12 +146,12 @@ | |
| 146 | CGI in the `FOSSIL_NONCE` environment variable, which it can then |
| 147 | use in `<script>` elements it generates. Because these extensions |
| 148 | can only be installed by the Fossil server’s system administrator, |
| 149 | this path is also considered safe. |
| 150 | |
| 151 | [su]: ./admin-v-setup.md |
| 152 | [ext]: ./serverext.wiki |
| 153 | |
| 154 | |
| 155 | #### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities |
| 156 | |
| 157 | We’re so restrictive about how we treat JavaScript because it can lead |
| 158 |
| --- www/defcsp.md | |
| +++ www/defcsp.md | |
| @@ -146,12 +146,12 @@ | |
| 146 | CGI in the `FOSSIL_NONCE` environment variable, which it can then |
| 147 | use in `<script>` elements it generates. Because these extensions |
| 148 | can only be installed by the Fossil server’s system administrator, |
| 149 | this path is also considered safe. |
| 150 | |
| 151 | [ext]: ./serverext.wiki |
| 152 | [su]: ./caps/admin-v-setup.md#apsu |
| 153 | |
| 154 | |
| 155 | #### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities |
| 156 | |
| 157 | We’re so restrictive about how we treat JavaScript because it can lead |
| 158 |
+1
-1
| --- www/defcsp.md | ||
| +++ www/defcsp.md | ||
| @@ -146,12 +146,12 @@ | ||
| 146 | 146 | CGI in the `FOSSIL_NONCE` environment variable, which it can then |
| 147 | 147 | use in `<script>` elements it generates. Because these extensions |
| 148 | 148 | can only be installed by the Fossil server’s system administrator, |
| 149 | 149 | this path is also considered safe. |
| 150 | 150 | |
| 151 | -[su]: ./admin-v-setup.md | |
| 152 | 151 | [ext]: ./serverext.wiki |
| 152 | +[su]: ./caps/admin-v-setup.md#apsu | |
| 153 | 153 | |
| 154 | 154 | |
| 155 | 155 | #### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities |
| 156 | 156 | |
| 157 | 157 | We’re so restrictive about how we treat JavaScript because it can lead |
| 158 | 158 |
| --- www/defcsp.md | |
| +++ www/defcsp.md | |
| @@ -146,12 +146,12 @@ | |
| 146 | CGI in the `FOSSIL_NONCE` environment variable, which it can then |
| 147 | use in `<script>` elements it generates. Because these extensions |
| 148 | can only be installed by the Fossil server’s system administrator, |
| 149 | this path is also considered safe. |
| 150 | |
| 151 | [su]: ./admin-v-setup.md |
| 152 | [ext]: ./serverext.wiki |
| 153 | |
| 154 | |
| 155 | #### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities |
| 156 | |
| 157 | We’re so restrictive about how we treat JavaScript because it can lead |
| 158 |
| --- www/defcsp.md | |
| +++ www/defcsp.md | |
| @@ -146,12 +146,12 @@ | |
| 146 | CGI in the `FOSSIL_NONCE` environment variable, which it can then |
| 147 | use in `<script>` elements it generates. Because these extensions |
| 148 | can only be installed by the Fossil server’s system administrator, |
| 149 | this path is also considered safe. |
| 150 | |
| 151 | [ext]: ./serverext.wiki |
| 152 | [su]: ./caps/admin-v-setup.md#apsu |
| 153 | |
| 154 | |
| 155 | #### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities |
| 156 | |
| 157 | We’re so restrictive about how we treat JavaScript because it can lead |
| 158 |
+34
-66
| --- 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,63 +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 role-based access control mechanism as | |
| 115 | -for normal Fossil repository logins. | |
| 116 | - | |
| 117 | -There are several dedicated forum-related capability bits you can grant | |
| 118 | -a user: | |
| 119 | - | |
| 120 | - * <b>Read Forum</b> (<tt>2</tt>): The user may read forum posts. | |
| 121 | - | |
| 122 | - * <b>Write Forum</b> (<tt>3</tt>): The user may create new forum | |
| 123 | - threads, reply to existing threads, and edit their own posts. New | |
| 124 | - posts are held for moderation, and they are marked to prevent them | |
| 125 | - from being included in clone and sync operations. | |
| 126 | - | |
| 127 | - * <b>WriteTrusted Forum</b> (<tt>4</tt>): Same as <b>Write Forum</b> | |
| 128 | - except that forum updates bypass the [#moderation | moderation and | |
| 129 | - private artifact restrictions]. | |
| 130 | - | |
| 131 | - * <b>Moderate Forum</b> (<tt>5</tt>): User gets buttons on posts | |
| 132 | - which allow them to either reject or approve posts held for | |
| 133 | - moderation. User also gets access to a page (<tt>/modreq</tt>) | |
| 134 | - showing the list of pending moderation tasks. | |
| 135 | - | |
| 136 | - * <b>Supervise Forum</b> (<tt>6</tt>): User can grant or revoke | |
| 137 | - <b>WriteTrusted</b> capability for other users. (Currently | |
| 138 | - unimplemented.) | |
| 139 | - | |
| 140 | - * <b>Email Alerts</b> (<tt>7</tt>): User can sign themselves up for | |
| 141 | - email alerts, a.k.a. notifications. | |
| 142 | - | |
| 143 | 114 | By default, no Fossil user has permission to use the forums except for |
| 144 | 115 | users with Setup and Admin capabilities, which get these as part of the |
| 145 | 116 | large package of other capabilities they get. |
| 146 | 117 | |
| 147 | 118 | For public Fossil repositories that wish to accept new users without |
| 148 | 119 | involving a human, go into Admin → Access and enable the "Allow |
| 149 | 120 | users to register themselves" setting. You may also wish to give users |
| 150 | -in the <tt>anonymous</tt> category the Read Forum (2) and Write Forum | |
| 151 | -(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 | |
| 152 | 125 | simply by solving [./antibot.wiki | a simple CAPTCHA]. |
| 153 | 126 | |
| 154 | 127 | For a private repository, you probably won't want to give the |
| 155 | 128 | <tt>anonymous</tt> user any forum access, but you may wish to give the |
| 156 | -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. | |
| 157 | 130 | |
| 158 | 131 | For either type of repository, you are likely to want to give at least |
| 159 | -the WriteTrusted capability (4) to users in the <tt>developer</tt> | |
| 160 | -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 | |
| 161 | 134 | <tt>anonymous</tt> above, you should give <tt>developer</tt> that |
| 162 | -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. | |
| 163 | 137 | |
| 164 | 138 | If you want to use the email alert feature, by default only those |
| 165 | 139 | users in the Setup and Admin user categories can make use of it. Grant |
| 166 | -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. | |
| 167 | 141 | Alternately, you can handle alert signups outside of Fossil, with |
| 168 | 142 | a Setup or Admin users manually signing users up via Admin → |
| 169 | 143 | Notification. You'll want to grant this capability to the |
| 170 | 144 | <tt>nobody</tt> user category if you want anyone to sign up without any |
| 171 | 145 | restrictions. Give it to <tt>anonymous</tt> instead if you want the |
| @@ -174,11 +148,11 @@ | ||
| 174 | 148 | logins to have this ability. (That's assuming you give one or both of |
| 175 | 149 | these capabilities to every user on your Fossil repository.) |
| 176 | 150 | |
| 177 | 151 | By following this advice, you should not need to tediously add |
| 178 | 152 | capabilities to individual accounts except in atypical cases, such as |
| 179 | -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 | |
| 180 | 154 | highly-trusted user. |
| 181 | 155 | |
| 182 | 156 | |
| 183 | 157 | <h3 id="skin">Skin Setup</h3> |
| 184 | 158 | |
| @@ -210,13 +184,13 @@ | ||
| 210 | 184 | if {[anycap 23456] || [anoncap 2] || [anoncap 3]} { |
| 211 | 185 | menulink /forum Forum |
| 212 | 186 | } |
| 213 | 187 | </verbatim> |
| 214 | 188 | |
| 215 | -These rules say that any logged-in user with any forum-related | |
| 216 | -capability (2-6 inclusive, as of this writing) or an anonymous user with | |
| 217 | -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 | |
| 218 | 192 | link, which just takes you to <tt>/forum</tt>. |
| 219 | 193 | |
| 220 | 194 | The exact code you need here varies depending on which skin you're |
| 221 | 195 | using. Follow the style you see for the other navbar links. |
| 222 | 196 | |
| @@ -303,14 +277,11 @@ | ||
| 303 | 277 | |
| 304 | 278 | Yet, what of the users who will have logins on both repositories? Some |
| 305 | 279 | users will be trusted with access to the project's main Fossil |
| 306 | 280 | repository, and these users will probably also participate in the |
| 307 | 281 | project's Fossil-hosted forum. Fossil has a feature to solve this |
| 308 | -problem which is probably less well known than it should be, and which | |
| 309 | -has been a feature of Fossil since April of 2011: Admin → | |
| 310 | -Login-Group. This allows one Fossil repository to recognize users | |
| 311 | -authorized on a different Fossil repository. | |
| 282 | +problem: [./caps/login-groups.md | login groups]. | |
| 312 | 283 | |
| 313 | 284 | |
| 314 | 285 | <h3 id="alerts">Email Alerts (a.k.a. Notifications)</h3> |
| 315 | 286 | |
| 316 | 287 | Internet email service has become rather complicated since its initial |
| @@ -327,20 +298,18 @@ | ||
| 327 | 298 | |
| 328 | 299 | There are many paths to a repository's Fossil forum: |
| 329 | 300 | |
| 330 | 301 | <ul> |
| 331 | 302 | <li> |
| 332 | - <p>If you're using the default Fossil skin as shipped with Fossil | |
| 333 | - 2.7 or one updated to include the changes since 2.6 or prior, there | |
| 334 | - is a Forum button in the navbar which appears for users with any of | |
| 335 | - the forum-related user capabilities: 2 through 6 inclusive for those | |
| 336 | - with repository logins, or caps 2 and 3 for users without a user | |
| 337 | - account but who have solved the Anonymous user CAPTCHA.</p> | |
| 338 | - <p>This button will not appear in the default skin for such users if | |
| 339 | - 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 | |
| 340 | 309 | Fossil admin can adjust this limit in the skin's CSS section, down |
| 341 | - near the bottom in the definition of the `wideonly` style.</p> | |
| 310 | + near the bottom in the definition of the `wideonly` style. | |
| 342 | 311 | </li> |
| 343 | 312 | |
| 344 | 313 | <li>The other stock skins have this button in them as of 2.7 as well, |
| 345 | 314 | without the screen width restriction, since the navbar in those skins |
| 346 | 315 | wraps on narrow screens more gracefully than the default skin |
| @@ -368,11 +337,11 @@ | ||
| 368 | 337 | |
| 369 | 338 | * create a new post |
| 370 | 339 | * reply to an existing post |
| 371 | 340 | * edit a post or reply |
| 372 | 341 | |
| 373 | -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 | |
| 374 | 343 | updates the forum, Fossil saves the update in its block chain, but this |
| 375 | 344 | update is impermanent because of two other table updates made at the |
| 376 | 345 | same time: |
| 377 | 346 | |
| 378 | 347 | <ol> |
| @@ -386,14 +355,13 @@ | ||
| 386 | 355 | what causes Fossil to leave out the Reply button when rendering that |
| 387 | 356 | post's HTML in the forum's web interface.</li> |
| 388 | 357 | </ol> |
| 389 | 358 | |
| 390 | 359 | When a moderator approves an update, Fossil deletes these table entries, |
| 391 | -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 | |
| 392 | 361 | HTML for that update. It also means the artifact will now sync to |
| 393 | -clones, if the sync is done by a user with <b>Check-Out</b> capability | |
| 394 | -(<tt>o</tt>). | |
| 362 | +users with <b>[./caps/ref.html#g | Clone]</b> capability. | |
| 395 | 363 | |
| 396 | 364 | When a forum user edits a moderator-approved artifact, what actually |
| 397 | 365 | happens under the hood is that Fossil writes another artifact to the |
| 398 | 366 | repository which refers to the original version as its parent, causing |
| 399 | 367 | Fossil UI to present the new version instead of the original. The |
| @@ -403,11 +371,11 @@ | ||
| 403 | 371 | |
| 404 | 372 | When you "Delete" a moderator-approved post or reply through Fossil UI, |
| 405 | 373 | it's actually an edit with blank replacement content. The only way to |
| 406 | 374 | truly delete such artifacts is through [./shunning.wiki | shunning]. |
| 407 | 375 | |
| 408 | -When a user with <b>WriteTrusted Forum</b> capability (<tt>4</tt>) | |
| 376 | +When a user with <b>WrTForum</b> capability | |
| 409 | 377 | updates the forum, it happens in the same way except that Fossil skips |
| 410 | 378 | the <tt>private</tt> and <tt>modreq</tt> table insertions. |
| 411 | 379 | |
| 412 | 380 | When a moderator rejects an update, that artifact is unceremoniously |
| 413 | 381 | removed from the tip of the block chain. This is safe because Fossil |
| @@ -422,21 +390,21 @@ | ||
| 422 | 390 | Having described all of the work that Fossil performs under the hood on |
| 423 | 391 | behalf of its users, we can now give the short list of work left for the |
| 424 | 392 | repository's administrators and moderators: |
| 425 | 393 | |
| 426 | 394 | <ol> |
| 427 | - <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 | |
| 428 | 396 | your users who should have this ability. You don't need to do this |
| 429 | - for any user with Setup (<tt>s</tt>) or Admin (<tt>a</tt>) | |
| 430 | - 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 | |
| 431 | 399 | [http://fossil-scm.org/index.html/artifact/b16221ffb736caa2?ln=1246-1257 |
| 432 | 400 | | already included].</li> |
| 433 | 401 | |
| 434 | 402 | <li>When someone updates the forum, an entry will appear in the |
| 435 | 403 | timeline if the type filter is set to "Forum" or "Any Type". If that |
| 436 | - user has only the <b>Write Forum</b> capability (<tt>3</tt>), any | |
| 437 | - 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 | |
| 438 | 406 | will see a conditional link appear at the top of the main forum |
| 439 | 407 | page: "Moderation Requests". Clicking this takes the moderator to |
| 440 | 408 | the <tt>/modreq</tt> page. A moderator may wish to keep the main |
| 441 | 409 | forum page open in a browser tab, reloading it occasionally to see |
| 442 | 410 | when the "Moderation Requests" link reappears.</li> |
| 443 | 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,63 +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 role-based access control mechanism as |
| 115 | for normal Fossil repository logins. |
| 116 | |
| 117 | There are several dedicated forum-related capability bits you can grant |
| 118 | a user: |
| 119 | |
| 120 | * <b>Read Forum</b> (<tt>2</tt>): The user may read forum posts. |
| 121 | |
| 122 | * <b>Write Forum</b> (<tt>3</tt>): The user may create new forum |
| 123 | threads, reply to existing threads, and edit their own posts. New |
| 124 | posts are held for moderation, and they are marked to prevent them |
| 125 | from being included in clone and sync operations. |
| 126 | |
| 127 | * <b>WriteTrusted Forum</b> (<tt>4</tt>): Same as <b>Write Forum</b> |
| 128 | except that forum updates bypass the [#moderation | moderation and |
| 129 | private artifact restrictions]. |
| 130 | |
| 131 | * <b>Moderate Forum</b> (<tt>5</tt>): User gets buttons on posts |
| 132 | which allow them to either reject or approve posts held for |
| 133 | moderation. User also gets access to a page (<tt>/modreq</tt>) |
| 134 | showing the list of pending moderation tasks. |
| 135 | |
| 136 | * <b>Supervise Forum</b> (<tt>6</tt>): User can grant or revoke |
| 137 | <b>WriteTrusted</b> capability for other users. (Currently |
| 138 | unimplemented.) |
| 139 | |
| 140 | * <b>Email Alerts</b> (<tt>7</tt>): User can sign themselves up for |
| 141 | email alerts, a.k.a. notifications. |
| 142 | |
| 143 | By default, no Fossil user has permission to use the forums except for |
| 144 | users with Setup and Admin capabilities, which get these as part of the |
| 145 | large package of other capabilities they get. |
| 146 | |
| 147 | For public Fossil repositories that wish to accept new users without |
| 148 | involving a human, go into Admin → Access and enable the "Allow |
| 149 | users to register themselves" setting. You may also wish to give users |
| 150 | in the <tt>anonymous</tt> category the Read Forum (2) and Write Forum |
| 151 | (3) capabilities: this allows people to post without creating an account |
| 152 | simply by solving [./antibot.wiki | a simple CAPTCHA]. |
| 153 | |
| 154 | For a private repository, you probably won't want to give the |
| 155 | <tt>anonymous</tt> user any forum access, but you may wish to give the |
| 156 | Read Forum capability (2) to users in the <tt>reader</tt> category. |
| 157 | |
| 158 | For either type of repository, you are likely to want to give at least |
| 159 | the WriteTrusted capability (4) to users in the <tt>developer</tt> |
| 160 | category. If you did not give the Read Forum capability (2) to |
| 161 | <tt>anonymous</tt> above, you should give <tt>developer</tt> that |
| 162 | capability here if you choose to give it capability 3 or 4. |
| 163 | |
| 164 | If you want to use the email alert feature, by default only those |
| 165 | users in the Setup and Admin user categories can make use of it. Grant |
| 166 | the Email Alerts capability (7) to give others access to this feature. |
| 167 | Alternately, you can handle alert signups outside of Fossil, with |
| 168 | a Setup or Admin users manually signing users up via Admin → |
| 169 | Notification. You'll want to grant this capability to the |
| 170 | <tt>nobody</tt> user category if you want anyone to sign up without any |
| 171 | restrictions. Give it to <tt>anonymous</tt> instead if you want the |
| @@ -174,11 +148,11 @@ | |
| 174 | logins to have this ability. (That's assuming you give one or both of |
| 175 | these capabilities to every user on your Fossil repository.) |
| 176 | |
| 177 | By following this advice, you should not need to tediously add |
| 178 | capabilities to individual accounts except in atypical cases, such as |
| 179 | to grant the Moderate Forum capability (5) to an uncommonly |
| 180 | highly-trusted user. |
| 181 | |
| 182 | |
| 183 | <h3 id="skin">Skin Setup</h3> |
| 184 | |
| @@ -210,13 +184,13 @@ | |
| 210 | if {[anycap 23456] || [anoncap 2] || [anoncap 3]} { |
| 211 | menulink /forum Forum |
| 212 | } |
| 213 | </verbatim> |
| 214 | |
| 215 | These rules say that any logged-in user with any forum-related |
| 216 | capability (2-6 inclusive, as of this writing) or an anonymous user with |
| 217 | read or write capability on the forum (2, 3) will see the "Forum" navbar |
| 218 | link, which just takes you to <tt>/forum</tt>. |
| 219 | |
| 220 | The exact code you need here varies depending on which skin you're |
| 221 | using. Follow the style you see for the other navbar links. |
| 222 | |
| @@ -303,14 +277,11 @@ | |
| 303 | |
| 304 | Yet, what of the users who will have logins on both repositories? Some |
| 305 | users will be trusted with access to the project's main Fossil |
| 306 | repository, and these users will probably also participate in the |
| 307 | project's Fossil-hosted forum. Fossil has a feature to solve this |
| 308 | problem which is probably less well known than it should be, and which |
| 309 | has been a feature of Fossil since April of 2011: Admin → |
| 310 | Login-Group. This allows one Fossil repository to recognize users |
| 311 | authorized on a different Fossil repository. |
| 312 | |
| 313 | |
| 314 | <h3 id="alerts">Email Alerts (a.k.a. Notifications)</h3> |
| 315 | |
| 316 | Internet email service has become rather complicated since its initial |
| @@ -327,20 +298,18 @@ | |
| 327 | |
| 328 | There are many paths to a repository's Fossil forum: |
| 329 | |
| 330 | <ul> |
| 331 | <li> |
| 332 | <p>If you're using the default Fossil skin as shipped with Fossil |
| 333 | 2.7 or one updated to include the changes since 2.6 or prior, there |
| 334 | is a Forum button in the navbar which appears for users with any of |
| 335 | the forum-related user capabilities: 2 through 6 inclusive for those |
| 336 | with repository logins, or caps 2 and 3 for users without a user |
| 337 | account but who have solved the Anonymous user CAPTCHA.</p> |
| 338 | <p>This button will not appear in the default skin for such users if |
| 339 | their browser window is not greater than 1200 pixels wide. The |
| 340 | Fossil admin can adjust this limit in the skin's CSS section, down |
| 341 | near the bottom in the definition of the `wideonly` style.</p> |
| 342 | </li> |
| 343 | |
| 344 | <li>The other stock skins have this button in them as of 2.7 as well, |
| 345 | without the screen width restriction, since the navbar in those skins |
| 346 | wraps on narrow screens more gracefully than the default skin |
| @@ -368,11 +337,11 @@ | |
| 368 | |
| 369 | * create a new post |
| 370 | * reply to an existing post |
| 371 | * edit a post or reply |
| 372 | |
| 373 | When a person with the normal <b>Write Forum</b> capability (<tt>3</tt>) |
| 374 | updates the forum, Fossil saves the update in its block chain, but this |
| 375 | update is impermanent because of two other table updates made at the |
| 376 | same time: |
| 377 | |
| 378 | <ol> |
| @@ -386,14 +355,13 @@ | |
| 386 | what causes Fossil to leave out the Reply button when rendering that |
| 387 | post's HTML in the forum's web interface.</li> |
| 388 | </ol> |
| 389 | |
| 390 | When a moderator approves an update, Fossil deletes these table entries, |
| 391 | making the update semi-permanent. This changes how Fossil renders the |
| 392 | HTML for that update. It also means the artifact will now sync to |
| 393 | clones, if the sync is done by a user with <b>Check-Out</b> capability |
| 394 | (<tt>o</tt>). |
| 395 | |
| 396 | When a forum user edits a moderator-approved artifact, what actually |
| 397 | happens under the hood is that Fossil writes another artifact to the |
| 398 | repository which refers to the original version as its parent, causing |
| 399 | Fossil UI to present the new version instead of the original. The |
| @@ -403,11 +371,11 @@ | |
| 403 | |
| 404 | When you "Delete" a moderator-approved post or reply through Fossil UI, |
| 405 | it's actually an edit with blank replacement content. The only way to |
| 406 | truly delete such artifacts is through [./shunning.wiki | shunning]. |
| 407 | |
| 408 | When a user with <b>WriteTrusted Forum</b> capability (<tt>4</tt>) |
| 409 | updates the forum, it happens in the same way except that Fossil skips |
| 410 | the <tt>private</tt> and <tt>modreq</tt> table insertions. |
| 411 | |
| 412 | When a moderator rejects an update, that artifact is unceremoniously |
| 413 | removed from the tip of the block chain. This is safe because Fossil |
| @@ -422,21 +390,21 @@ | |
| 422 | Having described all of the work that Fossil performs under the hood on |
| 423 | behalf of its users, we can now give the short list of work left for the |
| 424 | repository's administrators and moderators: |
| 425 | |
| 426 | <ol> |
| 427 | <li>Add the <b>Moderate Forum</b> capability (<tt>5</tt>) to any of |
| 428 | your users who should have this ability. You don't need to do this |
| 429 | for any user with Setup (<tt>s</tt>) or Admin (<tt>a</tt>) |
| 430 | capability; it's |
| 431 | [http://fossil-scm.org/index.html/artifact/b16221ffb736caa2?ln=1246-1257 |
| 432 | | already included].</li> |
| 433 | |
| 434 | <li>When someone updates the forum, an entry will appear in the |
| 435 | timeline if the type filter is set to "Forum" or "Any Type". If that |
| 436 | user has only the <b>Write Forum</b> capability (<tt>3</tt>), any |
| 437 | other user with the <b>Moderate Forum</b> capability (<tt>5</tt>) |
| 438 | will see a conditional link appear at the top of the main forum |
| 439 | page: "Moderation Requests". Clicking this takes the moderator to |
| 440 | the <tt>/modreq</tt> page. A moderator may wish to keep the main |
| 441 | forum page open in a browser tab, reloading it occasionally to see |
| 442 | when the "Moderation Requests" link reappears.</li> |
| 443 |
| --- 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,63 +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 |
| @@ -174,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 | |
| @@ -210,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 | |
| @@ -303,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 |
| @@ -327,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 |
| @@ -368,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> |
| @@ -386,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 |
| @@ -403,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 |
| @@ -422,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 |
+4
-5
| --- 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." |
| @@ -325,13 +324,13 @@ | ||
| 325 | 324 | automatically synchronized up to the central repository; there is no |
| 326 | 325 | "[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow|dictator |
| 327 | 326 | and lieutenants]" hierarchy as with Linux kernel contributions. D. |
| 328 | 327 | Richard Hipp rarely overrides decisions made by those he has trusted |
| 329 | 328 | with commit access on his repositories. Fossil allows you to give |
| 330 | - [/doc/trunk/www/admin-v-setup.md|some users] more power over what | |
| 331 | - they can do with the repository, but Fossil does not otherwise | |
| 332 | - directly support the enforcement of a development organization's | |
| 329 | + [./caps/admin-v-setup.md|some users] more power over what | |
| 330 | + they can do with the repository, but Fossil [./caps/index.md#ucap | | |
| 331 | + only loosely supports] the enforcement of a development organization's | |
| 333 | 332 | social and power hierarchies. Fossil is a great fit for |
| 334 | 333 | [https://en.wikipedia.org/wiki/Flat_organization|flat |
| 335 | 334 | organizations].</p></li> |
| 336 | 335 | |
| 337 | 336 | <li><p><b>No easy drive-by contributions:</b> Git |
| 338 | 337 |
| --- 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." |
| @@ -325,13 +324,13 @@ | |
| 325 | automatically synchronized up to the central repository; there is no |
| 326 | "[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow|dictator |
| 327 | and lieutenants]" hierarchy as with Linux kernel contributions. D. |
| 328 | Richard Hipp rarely overrides decisions made by those he has trusted |
| 329 | with commit access on his repositories. Fossil allows you to give |
| 330 | [/doc/trunk/www/admin-v-setup.md|some users] more power over what |
| 331 | they can do with the repository, but Fossil does not otherwise |
| 332 | directly support the enforcement of a development organization's |
| 333 | social and power hierarchies. Fossil is a great fit for |
| 334 | [https://en.wikipedia.org/wiki/Flat_organization|flat |
| 335 | organizations].</p></li> |
| 336 | |
| 337 | <li><p><b>No easy drive-by contributions:</b> Git |
| 338 |
| --- 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." |
| @@ -325,13 +324,13 @@ | |
| 324 | automatically synchronized up to the central repository; there is no |
| 325 | "[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow|dictator |
| 326 | and lieutenants]" hierarchy as with Linux kernel contributions. D. |
| 327 | Richard Hipp rarely overrides decisions made by those he has trusted |
| 328 | with commit access on his repositories. Fossil allows you to give |
| 329 | [./caps/admin-v-setup.md|some users] more power over what |
| 330 | they can do with the repository, but Fossil [./caps/index.md#ucap | |
| 331 | only loosely supports] the enforcement of a development organization's |
| 332 | social and power hierarchies. Fossil is a great fit for |
| 333 | [https://en.wikipedia.org/wiki/Flat_organization|flat |
| 334 | organizations].</p></li> |
| 335 | |
| 336 | <li><p><b>No easy drive-by contributions:</b> Git |
| 337 |
+4
-1
| --- www/mkindex.tcl | ||
| +++ www/mkindex.tcl | ||
| @@ -9,19 +9,22 @@ | ||
| 9 | 9 | set doclist { |
| 10 | 10 | aboutcgi.wiki {How CGI Works In Fossil} |
| 11 | 11 | aboutdownload.wiki {How The Download Page Works} |
| 12 | 12 | adding_code.wiki {Adding New Features To Fossil} |
| 13 | 13 | adding_code.wiki {Hacking Fossil} |
| 14 | - admin-v-setup.md {The Differences Between the Setup and Admin User Capabilities} | |
| 15 | 14 | alerts.md {Email Alerts And Notifications} |
| 16 | 15 | antibot.wiki {Defense against Spiders and Bots} |
| 17 | 16 | backoffice.md {The "Backoffice" mechanism of Fossil} |
| 18 | 17 | blame.wiki {The Annotate/Blame Algorithm Of Fossil} |
| 19 | 18 | blockchain.md {Fossil As Blockchain} |
| 20 | 19 | branching.wiki {Branching, Forking, Merging, and Tagging} |
| 21 | 20 | bugtheory.wiki {Bug Tracking In Fossil} |
| 22 | 21 | build.wiki {Compiling and Installing Fossil} |
| 22 | + caps/ {Administering User Capabilities} | |
| 23 | + caps/admin-v-setup.md {Differences Between Setup and Admin Users} | |
| 24 | + caps/login-groups.md {Differences Between Setup and Admin Users} | |
| 25 | + caps/ref.html {User Capability Reference} | |
| 23 | 26 | cgi.wiki {CGI Script Configuration Options} |
| 24 | 27 | changes.wiki {Fossil Changelog} |
| 25 | 28 | checkin_names.wiki {Check-in And Version Names} |
| 26 | 29 | checkin.wiki {Check-in Checklist} |
| 27 | 30 | childprojects.wiki {Child Projects} |
| 28 | 31 |
| --- www/mkindex.tcl | |
| +++ www/mkindex.tcl | |
| @@ -9,19 +9,22 @@ | |
| 9 | set doclist { |
| 10 | aboutcgi.wiki {How CGI Works In Fossil} |
| 11 | aboutdownload.wiki {How The Download Page Works} |
| 12 | adding_code.wiki {Adding New Features To Fossil} |
| 13 | adding_code.wiki {Hacking Fossil} |
| 14 | admin-v-setup.md {The Differences Between the Setup and Admin User Capabilities} |
| 15 | alerts.md {Email Alerts And Notifications} |
| 16 | antibot.wiki {Defense against Spiders and Bots} |
| 17 | backoffice.md {The "Backoffice" mechanism of Fossil} |
| 18 | blame.wiki {The Annotate/Blame Algorithm Of Fossil} |
| 19 | blockchain.md {Fossil As Blockchain} |
| 20 | branching.wiki {Branching, Forking, Merging, and Tagging} |
| 21 | bugtheory.wiki {Bug Tracking In Fossil} |
| 22 | build.wiki {Compiling and Installing Fossil} |
| 23 | cgi.wiki {CGI Script Configuration Options} |
| 24 | changes.wiki {Fossil Changelog} |
| 25 | checkin_names.wiki {Check-in And Version Names} |
| 26 | checkin.wiki {Check-in Checklist} |
| 27 | childprojects.wiki {Child Projects} |
| 28 |
| --- www/mkindex.tcl | |
| +++ www/mkindex.tcl | |
| @@ -9,19 +9,22 @@ | |
| 9 | set doclist { |
| 10 | aboutcgi.wiki {How CGI Works In Fossil} |
| 11 | aboutdownload.wiki {How The Download Page Works} |
| 12 | adding_code.wiki {Adding New Features To Fossil} |
| 13 | adding_code.wiki {Hacking Fossil} |
| 14 | alerts.md {Email Alerts And Notifications} |
| 15 | antibot.wiki {Defense against Spiders and Bots} |
| 16 | backoffice.md {The "Backoffice" mechanism of Fossil} |
| 17 | blame.wiki {The Annotate/Blame Algorithm Of Fossil} |
| 18 | blockchain.md {Fossil As Blockchain} |
| 19 | branching.wiki {Branching, Forking, Merging, and Tagging} |
| 20 | bugtheory.wiki {Bug Tracking In Fossil} |
| 21 | build.wiki {Compiling and Installing Fossil} |
| 22 | caps/ {Administering User Capabilities} |
| 23 | caps/admin-v-setup.md {Differences Between Setup and Admin Users} |
| 24 | caps/login-groups.md {Differences Between Setup and Admin Users} |
| 25 | caps/ref.html {User Capability Reference} |
| 26 | cgi.wiki {CGI Script Configuration Options} |
| 27 | changes.wiki {Fossil Changelog} |
| 28 | checkin_names.wiki {Check-in And Version Names} |
| 29 | checkin.wiki {Check-in Checklist} |
| 30 | childprojects.wiki {Child Projects} |
| 31 |
+16
-7
| --- www/permutedindex.html | ||
| +++ www/permutedindex.html | ||
| @@ -23,11 +23,13 @@ | ||
| 23 | 23 | <li><a href="fiveminutes.wiki">5 Minutes as a Single User — Up and Running in</a></li> |
| 24 | 24 | <li><a href="fossil-from-msvc.wiki">2010 IDE — Integrating Fossil in the Microsoft Express</a></li> |
| 25 | 25 | <li><a href="tech_overview.wiki"><b>A Technical Overview Of The Design And Implementation Of Fossil</b></a></li> |
| 26 | 26 | <li><a href="serverext.wiki"><b>Adding Extensions To A Fossil Server Using CGI Scripts</b></a></li> |
| 27 | 27 | <li><a href="adding_code.wiki"><b>Adding New Features To Fossil</b></a></li> |
| 28 | -<li><a href="admin-v-setup.md">Admin User Capabilities — The Differences Between the Setup and</a></li> | |
| 28 | +<li><a href="caps/admin-v-setup.md">Admin Users — Differences Between Setup and</a></li> | |
| 29 | +<li><a href="caps/login-groups.md">Admin Users — Differences Between Setup and</a></li> | |
| 30 | +<li><a href="caps/"><b>Administering User Capabilities</b></a></li> | |
| 29 | 31 | <li><a href="copyright-release.html">Agreement — Contributor License</a></li> |
| 30 | 32 | <li><a href="alerts.md">Alerts And Notifications — Email</a></li> |
| 31 | 33 | <li><a href="delta_encoder_algorithm.wiki">Algorithm — Fossil Delta Encoding</a></li> |
| 32 | 34 | <li><a href="blame.wiki">Algorithm Of Fossil — The Annotate/Blame</a></li> |
| 33 | 35 | <li><a href="blame.wiki">Annotate/Blame Algorithm Of Fossil — The</a></li> |
| @@ -35,19 +37,21 @@ | ||
| 35 | 37 | <li><a href="faq.wiki">Asked Questions — Frequently</a></li> |
| 36 | 38 | <li><a href="password.wiki">Authentication — Password Management And</a></li> |
| 37 | 39 | <li><a href="backoffice.md">Backoffice mechanism of Fossil — The</a></li> |
| 38 | 40 | <li><a href="fossil_prompt.wiki">Bash Prompt — Fossilized</a></li> |
| 39 | 41 | <li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li> |
| 42 | +<li><a href="caps/admin-v-setup.md">Between Setup and Admin Users — Differences</a></li> | |
| 43 | +<li><a href="caps/login-groups.md">Between Setup and Admin Users — Differences</a></li> | |
| 40 | 44 | <li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 — Hash Policy: Choosing</a></li> |
| 41 | -<li><a href="admin-v-setup.md">Between the Setup and Admin User Capabilities — The Differences</a></li> | |
| 42 | 45 | <li><a href="blockchain.md">Blockchain — Fossil As</a></li> |
| 43 | 46 | <li><a href="antibot.wiki">Bots — Defense against Spiders and</a></li> |
| 44 | 47 | <li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li> |
| 45 | 48 | <li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li> |
| 46 | 49 | <li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li> |
| 47 | 50 | <li><a href="makefile.wiki">Build Process — The Fossil</a></li> |
| 48 | -<li><a href="admin-v-setup.md">Capabilities — The Differences Between the Setup and Admin User</a></li> | |
| 51 | +<li><a href="caps/">Capabilities — Administering User</a></li> | |
| 52 | +<li><a href="caps/ref.html">Capability Reference — User</a></li> | |
| 49 | 53 | <li><a href="cgi.wiki"><b>CGI Script Configuration Options</b></a></li> |
| 50 | 54 | <li><a href="serverext.wiki">CGI Scripts — Adding Extensions To A Fossil Server Using</a></li> |
| 51 | 55 | <li><a href="serverext.wiki"><b>CGI Server Extensions</b></a></li> |
| 52 | 56 | <li><a href="aboutcgi.wiki">CGI Works In Fossil — How</a></li> |
| 53 | 57 | <li><a href="changes.wiki">Changelog — Fossil</a></li> |
| @@ -86,11 +90,12 @@ | ||
| 86 | 90 | <li><a href="private.wiki">Deleting Private Branches — Creating, Syncing, and</a></li> |
| 87 | 91 | <li><a href="delta_encoder_algorithm.wiki">Delta Encoding Algorithm — Fossil</a></li> |
| 88 | 92 | <li><a href="delta_format.wiki">Delta Format — Fossil</a></li> |
| 89 | 93 | <li><a href="tech_overview.wiki">Design And Implementation Of Fossil — A Technical Overview Of The</a></li> |
| 90 | 94 | <li><a href="theory1.wiki">Design Of The Fossil DVCS — Thoughts On The</a></li> |
| 91 | -<li><a href="admin-v-setup.md">Differences Between the Setup and Admin User Capabilities — The</a></li> | |
| 95 | +<li><a href="caps/admin-v-setup.md"><b>Differences Between Setup and Admin Users</b></a></li> | |
| 96 | +<li><a href="caps/login-groups.md"><b>Differences Between Setup and Admin Users</b></a></li> | |
| 92 | 97 | <li><a href="embeddeddoc.wiki">Documentation — Embedded Project</a></li> |
| 93 | 98 | <li><a href="contribute.wiki">Documentation To The Fossil Project — Contributing Code or</a></li> |
| 94 | 99 | <li><a href="aboutdownload.wiki">Download Page Works — How The</a></li> |
| 95 | 100 | <li><a href="theory1.wiki">DVCS — Thoughts On The Design Of The Fossil</a></li> |
| 96 | 101 | <li><a href="quotes.wiki">DVCSes in General — Quotes: What People Are Saying About Fossil, Git, and</a></li> |
| @@ -215,10 +220,11 @@ | ||
| 215 | 220 | <li><a href="tls-nginx.md"><b>Proxying Fossil via HTTPS with nginx</b></a></li> |
| 216 | 221 | <li><a href="faq.wiki">Questions — Frequently Asked</a></li> |
| 217 | 222 | <li><a href="qandc.wiki"><b>Questions And Criticisms</b></a></li> |
| 218 | 223 | <li><a href="quickstart.wiki">Quick Start Guide — Fossil</a></li> |
| 219 | 224 | <li><a href="quotes.wiki"><b>Quotes: What People Are Saying About Fossil, Git, and DVCSes in General</b></a></li> |
| 225 | +<li><a href="caps/ref.html">Reference — User Capability</a></li> | |
| 220 | 226 | <li><a href="image-format-vs-repo-size.md">Repo Size — Image Format vs Fossil</a></li> |
| 221 | 227 | <li><a href="selfhost.wiki">Repositories — Fossil Self Hosting</a></li> |
| 222 | 228 | <li><a href="encryptedrepos.wiki">Repositories — How To Use Encrypted</a></li> |
| 223 | 229 | <li><a href="newrepo.wiki">Repository — How To Create A New Fossil</a></li> |
| 224 | 230 | <li><a href="selfcheck.wiki">Repository Integrity Self Checks — Fossil</a></li> |
| @@ -236,11 +242,12 @@ | ||
| 236 | 242 | <li><a href="selfhost.wiki">Self Hosting Repositories — Fossil</a></li> |
| 237 | 243 | <li><a href="server/">Server — How To Configure A Fossil</a></li> |
| 238 | 244 | <li><a href="serverext.wiki">Server Extensions — CGI</a></li> |
| 239 | 245 | <li><a href="serverext.wiki">Server Using CGI Scripts — Adding Extensions To A Fossil</a></li> |
| 240 | 246 | <li><a href="settings.wiki">Settings — Fossil</a></li> |
| 241 | -<li><a href="admin-v-setup.md">Setup and Admin User Capabilities — The Differences Between the</a></li> | |
| 247 | +<li><a href="caps/admin-v-setup.md">Setup and Admin Users — Differences Between</a></li> | |
| 248 | +<li><a href="caps/login-groups.md">Setup and Admin Users — Differences Between</a></li> | |
| 242 | 249 | <li><a href="hashpolicy.wiki">SHA1 and SHA3-256 — Hash Policy: Choosing Between</a></li> |
| 243 | 250 | <li><a href="hashpolicy.wiki">SHA3-256 — Hash Policy: Choosing Between SHA1 and</a></li> |
| 244 | 251 | <li><a href="shunning.wiki"><b>Shunning: Deleting Content From Fossil</b></a></li> |
| 245 | 252 | <li><a href="fiveminutes.wiki">Single User — Up and Running in 5 Minutes as a</a></li> |
| 246 | 253 | <li><a href="../../../sitemap"><b>Site Map</b></a></li> |
| @@ -263,11 +270,10 @@ | ||
| 263 | 270 | <li><a href="../test/release-checklist.wiki">Testing Checklist — Pre-Release</a></li> |
| 264 | 271 | <li><a href="th1.md">TH1 Scripting Language — The</a></li> |
| 265 | 272 | <li><a href="backoffice.md"><b>The "Backoffice" mechanism of Fossil</b></a></li> |
| 266 | 273 | <li><a href="blame.wiki"><b>The Annotate/Blame Algorithm Of Fossil</b></a></li> |
| 267 | 274 | <li><a href="defcsp.md"><b>The Default Content Security Policy</b></a></li> |
| 268 | -<li><a href="admin-v-setup.md"><b>The Differences Between the Setup and Admin User Capabilities</b></a></li> | |
| 269 | 275 | <li><a href="makefile.wiki"><b>The Fossil Build Process</b></a></li> |
| 270 | 276 | <li><a href="sync.wiki"><b>The Fossil Sync Protocol</b></a></li> |
| 271 | 277 | <li><a href="tickets.wiki"><b>The Fossil Ticket System</b></a></li> |
| 272 | 278 | <li><a href="webui.wiki"><b>The Fossil Web Interface</b></a></li> |
| 273 | 279 | <li><a href="th1.md"><b>The TH1 Scripting Language</b></a></li> |
| @@ -281,11 +287,14 @@ | ||
| 281 | 287 | <li><a href="bugtheory.wiki">Tracking In Fossil — Bug</a></li> |
| 282 | 288 | <li><a href="unvers.wiki"><b>Unversioned Files</b></a></li> |
| 283 | 289 | <li><a href="fiveminutes.wiki"><b>Up and Running in 5 Minutes as a Single User</b></a></li> |
| 284 | 290 | <li><a href="hints.wiki">Usage Hints — Fossil Tips And</a></li> |
| 285 | 291 | <li><a href="fiveminutes.wiki">User — Up and Running in 5 Minutes as a Single</a></li> |
| 286 | -<li><a href="admin-v-setup.md">User Capabilities — The Differences Between the Setup and Admin</a></li> | |
| 292 | +<li><a href="caps/">User Capabilities — Administering</a></li> | |
| 293 | +<li><a href="caps/ref.html"><b>User Capability Reference</b></a></li> | |
| 294 | +<li><a href="caps/admin-v-setup.md">Users — Differences Between Setup and Admin</a></li> | |
| 295 | +<li><a href="caps/login-groups.md">Users — Differences Between Setup and Admin</a></li> | |
| 287 | 296 | <li><a href="serverext.wiki">Using CGI Scripts — Adding Extensions To A Fossil Server</a></li> |
| 288 | 297 | <li><a href="ssl.wiki"><b>Using SSL with Fossil</b></a></li> |
| 289 | 298 | <li><a href="env-opts.md">Variables and Global Options — Environment</a></li> |
| 290 | 299 | <li><a href="whyusefossil.wiki">Version Control — Benefits Of</a></li> |
| 291 | 300 | <li><a href="checkin_names.wiki">Version Names — Check-in And</a></li> |
| 292 | 301 |
| --- www/permutedindex.html | |
| +++ www/permutedindex.html | |
| @@ -23,11 +23,13 @@ | |
| 23 | <li><a href="fiveminutes.wiki">5 Minutes as a Single User — Up and Running in</a></li> |
| 24 | <li><a href="fossil-from-msvc.wiki">2010 IDE — Integrating Fossil in the Microsoft Express</a></li> |
| 25 | <li><a href="tech_overview.wiki"><b>A Technical Overview Of The Design And Implementation Of Fossil</b></a></li> |
| 26 | <li><a href="serverext.wiki"><b>Adding Extensions To A Fossil Server Using CGI Scripts</b></a></li> |
| 27 | <li><a href="adding_code.wiki"><b>Adding New Features To Fossil</b></a></li> |
| 28 | <li><a href="admin-v-setup.md">Admin User Capabilities — The Differences Between the Setup and</a></li> |
| 29 | <li><a href="copyright-release.html">Agreement — Contributor License</a></li> |
| 30 | <li><a href="alerts.md">Alerts And Notifications — Email</a></li> |
| 31 | <li><a href="delta_encoder_algorithm.wiki">Algorithm — Fossil Delta Encoding</a></li> |
| 32 | <li><a href="blame.wiki">Algorithm Of Fossil — The Annotate/Blame</a></li> |
| 33 | <li><a href="blame.wiki">Annotate/Blame Algorithm Of Fossil — The</a></li> |
| @@ -35,19 +37,21 @@ | |
| 35 | <li><a href="faq.wiki">Asked Questions — Frequently</a></li> |
| 36 | <li><a href="password.wiki">Authentication — Password Management And</a></li> |
| 37 | <li><a href="backoffice.md">Backoffice mechanism of Fossil — The</a></li> |
| 38 | <li><a href="fossil_prompt.wiki">Bash Prompt — Fossilized</a></li> |
| 39 | <li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li> |
| 40 | <li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 — Hash Policy: Choosing</a></li> |
| 41 | <li><a href="admin-v-setup.md">Between the Setup and Admin User Capabilities — The Differences</a></li> |
| 42 | <li><a href="blockchain.md">Blockchain — Fossil As</a></li> |
| 43 | <li><a href="antibot.wiki">Bots — Defense against Spiders and</a></li> |
| 44 | <li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li> |
| 45 | <li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li> |
| 46 | <li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li> |
| 47 | <li><a href="makefile.wiki">Build Process — The Fossil</a></li> |
| 48 | <li><a href="admin-v-setup.md">Capabilities — The Differences Between the Setup and Admin User</a></li> |
| 49 | <li><a href="cgi.wiki"><b>CGI Script Configuration Options</b></a></li> |
| 50 | <li><a href="serverext.wiki">CGI Scripts — Adding Extensions To A Fossil Server Using</a></li> |
| 51 | <li><a href="serverext.wiki"><b>CGI Server Extensions</b></a></li> |
| 52 | <li><a href="aboutcgi.wiki">CGI Works In Fossil — How</a></li> |
| 53 | <li><a href="changes.wiki">Changelog — Fossil</a></li> |
| @@ -86,11 +90,12 @@ | |
| 86 | <li><a href="private.wiki">Deleting Private Branches — Creating, Syncing, and</a></li> |
| 87 | <li><a href="delta_encoder_algorithm.wiki">Delta Encoding Algorithm — Fossil</a></li> |
| 88 | <li><a href="delta_format.wiki">Delta Format — Fossil</a></li> |
| 89 | <li><a href="tech_overview.wiki">Design And Implementation Of Fossil — A Technical Overview Of The</a></li> |
| 90 | <li><a href="theory1.wiki">Design Of The Fossil DVCS — Thoughts On The</a></li> |
| 91 | <li><a href="admin-v-setup.md">Differences Between the Setup and Admin User Capabilities — The</a></li> |
| 92 | <li><a href="embeddeddoc.wiki">Documentation — Embedded Project</a></li> |
| 93 | <li><a href="contribute.wiki">Documentation To The Fossil Project — Contributing Code or</a></li> |
| 94 | <li><a href="aboutdownload.wiki">Download Page Works — How The</a></li> |
| 95 | <li><a href="theory1.wiki">DVCS — Thoughts On The Design Of The Fossil</a></li> |
| 96 | <li><a href="quotes.wiki">DVCSes in General — Quotes: What People Are Saying About Fossil, Git, and</a></li> |
| @@ -215,10 +220,11 @@ | |
| 215 | <li><a href="tls-nginx.md"><b>Proxying Fossil via HTTPS with nginx</b></a></li> |
| 216 | <li><a href="faq.wiki">Questions — Frequently Asked</a></li> |
| 217 | <li><a href="qandc.wiki"><b>Questions And Criticisms</b></a></li> |
| 218 | <li><a href="quickstart.wiki">Quick Start Guide — Fossil</a></li> |
| 219 | <li><a href="quotes.wiki"><b>Quotes: What People Are Saying About Fossil, Git, and DVCSes in General</b></a></li> |
| 220 | <li><a href="image-format-vs-repo-size.md">Repo Size — Image Format vs Fossil</a></li> |
| 221 | <li><a href="selfhost.wiki">Repositories — Fossil Self Hosting</a></li> |
| 222 | <li><a href="encryptedrepos.wiki">Repositories — How To Use Encrypted</a></li> |
| 223 | <li><a href="newrepo.wiki">Repository — How To Create A New Fossil</a></li> |
| 224 | <li><a href="selfcheck.wiki">Repository Integrity Self Checks — Fossil</a></li> |
| @@ -236,11 +242,12 @@ | |
| 236 | <li><a href="selfhost.wiki">Self Hosting Repositories — Fossil</a></li> |
| 237 | <li><a href="server/">Server — How To Configure A Fossil</a></li> |
| 238 | <li><a href="serverext.wiki">Server Extensions — CGI</a></li> |
| 239 | <li><a href="serverext.wiki">Server Using CGI Scripts — Adding Extensions To A Fossil</a></li> |
| 240 | <li><a href="settings.wiki">Settings — Fossil</a></li> |
| 241 | <li><a href="admin-v-setup.md">Setup and Admin User Capabilities — The Differences Between the</a></li> |
| 242 | <li><a href="hashpolicy.wiki">SHA1 and SHA3-256 — Hash Policy: Choosing Between</a></li> |
| 243 | <li><a href="hashpolicy.wiki">SHA3-256 — Hash Policy: Choosing Between SHA1 and</a></li> |
| 244 | <li><a href="shunning.wiki"><b>Shunning: Deleting Content From Fossil</b></a></li> |
| 245 | <li><a href="fiveminutes.wiki">Single User — Up and Running in 5 Minutes as a</a></li> |
| 246 | <li><a href="../../../sitemap"><b>Site Map</b></a></li> |
| @@ -263,11 +270,10 @@ | |
| 263 | <li><a href="../test/release-checklist.wiki">Testing Checklist — Pre-Release</a></li> |
| 264 | <li><a href="th1.md">TH1 Scripting Language — The</a></li> |
| 265 | <li><a href="backoffice.md"><b>The "Backoffice" mechanism of Fossil</b></a></li> |
| 266 | <li><a href="blame.wiki"><b>The Annotate/Blame Algorithm Of Fossil</b></a></li> |
| 267 | <li><a href="defcsp.md"><b>The Default Content Security Policy</b></a></li> |
| 268 | <li><a href="admin-v-setup.md"><b>The Differences Between the Setup and Admin User Capabilities</b></a></li> |
| 269 | <li><a href="makefile.wiki"><b>The Fossil Build Process</b></a></li> |
| 270 | <li><a href="sync.wiki"><b>The Fossil Sync Protocol</b></a></li> |
| 271 | <li><a href="tickets.wiki"><b>The Fossil Ticket System</b></a></li> |
| 272 | <li><a href="webui.wiki"><b>The Fossil Web Interface</b></a></li> |
| 273 | <li><a href="th1.md"><b>The TH1 Scripting Language</b></a></li> |
| @@ -281,11 +287,14 @@ | |
| 281 | <li><a href="bugtheory.wiki">Tracking In Fossil — Bug</a></li> |
| 282 | <li><a href="unvers.wiki"><b>Unversioned Files</b></a></li> |
| 283 | <li><a href="fiveminutes.wiki"><b>Up and Running in 5 Minutes as a Single User</b></a></li> |
| 284 | <li><a href="hints.wiki">Usage Hints — Fossil Tips And</a></li> |
| 285 | <li><a href="fiveminutes.wiki">User — Up and Running in 5 Minutes as a Single</a></li> |
| 286 | <li><a href="admin-v-setup.md">User Capabilities — The Differences Between the Setup and Admin</a></li> |
| 287 | <li><a href="serverext.wiki">Using CGI Scripts — Adding Extensions To A Fossil Server</a></li> |
| 288 | <li><a href="ssl.wiki"><b>Using SSL with Fossil</b></a></li> |
| 289 | <li><a href="env-opts.md">Variables and Global Options — Environment</a></li> |
| 290 | <li><a href="whyusefossil.wiki">Version Control — Benefits Of</a></li> |
| 291 | <li><a href="checkin_names.wiki">Version Names — Check-in And</a></li> |
| 292 |
| --- www/permutedindex.html | |
| +++ www/permutedindex.html | |
| @@ -23,11 +23,13 @@ | |
| 23 | <li><a href="fiveminutes.wiki">5 Minutes as a Single User — Up and Running in</a></li> |
| 24 | <li><a href="fossil-from-msvc.wiki">2010 IDE — Integrating Fossil in the Microsoft Express</a></li> |
| 25 | <li><a href="tech_overview.wiki"><b>A Technical Overview Of The Design And Implementation Of Fossil</b></a></li> |
| 26 | <li><a href="serverext.wiki"><b>Adding Extensions To A Fossil Server Using CGI Scripts</b></a></li> |
| 27 | <li><a href="adding_code.wiki"><b>Adding New Features To Fossil</b></a></li> |
| 28 | <li><a href="caps/admin-v-setup.md">Admin Users — Differences Between Setup and</a></li> |
| 29 | <li><a href="caps/login-groups.md">Admin Users — Differences Between Setup and</a></li> |
| 30 | <li><a href="caps/"><b>Administering User Capabilities</b></a></li> |
| 31 | <li><a href="copyright-release.html">Agreement — Contributor License</a></li> |
| 32 | <li><a href="alerts.md">Alerts And Notifications — Email</a></li> |
| 33 | <li><a href="delta_encoder_algorithm.wiki">Algorithm — Fossil Delta Encoding</a></li> |
| 34 | <li><a href="blame.wiki">Algorithm Of Fossil — The Annotate/Blame</a></li> |
| 35 | <li><a href="blame.wiki">Annotate/Blame Algorithm Of Fossil — The</a></li> |
| @@ -35,19 +37,21 @@ | |
| 37 | <li><a href="faq.wiki">Asked Questions — Frequently</a></li> |
| 38 | <li><a href="password.wiki">Authentication — Password Management And</a></li> |
| 39 | <li><a href="backoffice.md">Backoffice mechanism of Fossil — The</a></li> |
| 40 | <li><a href="fossil_prompt.wiki">Bash Prompt — Fossilized</a></li> |
| 41 | <li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li> |
| 42 | <li><a href="caps/admin-v-setup.md">Between Setup and Admin Users — Differences</a></li> |
| 43 | <li><a href="caps/login-groups.md">Between Setup and Admin Users — Differences</a></li> |
| 44 | <li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 — Hash Policy: Choosing</a></li> |
| 45 | <li><a href="blockchain.md">Blockchain — Fossil As</a></li> |
| 46 | <li><a href="antibot.wiki">Bots — Defense against Spiders and</a></li> |
| 47 | <li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li> |
| 48 | <li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li> |
| 49 | <li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li> |
| 50 | <li><a href="makefile.wiki">Build Process — The Fossil</a></li> |
| 51 | <li><a href="caps/">Capabilities — Administering User</a></li> |
| 52 | <li><a href="caps/ref.html">Capability Reference — User</a></li> |
| 53 | <li><a href="cgi.wiki"><b>CGI Script Configuration Options</b></a></li> |
| 54 | <li><a href="serverext.wiki">CGI Scripts — Adding Extensions To A Fossil Server Using</a></li> |
| 55 | <li><a href="serverext.wiki"><b>CGI Server Extensions</b></a></li> |
| 56 | <li><a href="aboutcgi.wiki">CGI Works In Fossil — How</a></li> |
| 57 | <li><a href="changes.wiki">Changelog — Fossil</a></li> |
| @@ -86,11 +90,12 @@ | |
| 90 | <li><a href="private.wiki">Deleting Private Branches — Creating, Syncing, and</a></li> |
| 91 | <li><a href="delta_encoder_algorithm.wiki">Delta Encoding Algorithm — Fossil</a></li> |
| 92 | <li><a href="delta_format.wiki">Delta Format — Fossil</a></li> |
| 93 | <li><a href="tech_overview.wiki">Design And Implementation Of Fossil — A Technical Overview Of The</a></li> |
| 94 | <li><a href="theory1.wiki">Design Of The Fossil DVCS — Thoughts On The</a></li> |
| 95 | <li><a href="caps/admin-v-setup.md"><b>Differences Between Setup and Admin Users</b></a></li> |
| 96 | <li><a href="caps/login-groups.md"><b>Differences Between Setup and Admin Users</b></a></li> |
| 97 | <li><a href="embeddeddoc.wiki">Documentation — Embedded Project</a></li> |
| 98 | <li><a href="contribute.wiki">Documentation To The Fossil Project — Contributing Code or</a></li> |
| 99 | <li><a href="aboutdownload.wiki">Download Page Works — How The</a></li> |
| 100 | <li><a href="theory1.wiki">DVCS — Thoughts On The Design Of The Fossil</a></li> |
| 101 | <li><a href="quotes.wiki">DVCSes in General — Quotes: What People Are Saying About Fossil, Git, and</a></li> |
| @@ -215,10 +220,11 @@ | |
| 220 | <li><a href="tls-nginx.md"><b>Proxying Fossil via HTTPS with nginx</b></a></li> |
| 221 | <li><a href="faq.wiki">Questions — Frequently Asked</a></li> |
| 222 | <li><a href="qandc.wiki"><b>Questions And Criticisms</b></a></li> |
| 223 | <li><a href="quickstart.wiki">Quick Start Guide — Fossil</a></li> |
| 224 | <li><a href="quotes.wiki"><b>Quotes: What People Are Saying About Fossil, Git, and DVCSes in General</b></a></li> |
| 225 | <li><a href="caps/ref.html">Reference — User Capability</a></li> |
| 226 | <li><a href="image-format-vs-repo-size.md">Repo Size — Image Format vs Fossil</a></li> |
| 227 | <li><a href="selfhost.wiki">Repositories — Fossil Self Hosting</a></li> |
| 228 | <li><a href="encryptedrepos.wiki">Repositories — How To Use Encrypted</a></li> |
| 229 | <li><a href="newrepo.wiki">Repository — How To Create A New Fossil</a></li> |
| 230 | <li><a href="selfcheck.wiki">Repository Integrity Self Checks — Fossil</a></li> |
| @@ -236,11 +242,12 @@ | |
| 242 | <li><a href="selfhost.wiki">Self Hosting Repositories — Fossil</a></li> |
| 243 | <li><a href="server/">Server — How To Configure A Fossil</a></li> |
| 244 | <li><a href="serverext.wiki">Server Extensions — CGI</a></li> |
| 245 | <li><a href="serverext.wiki">Server Using CGI Scripts — Adding Extensions To A Fossil</a></li> |
| 246 | <li><a href="settings.wiki">Settings — Fossil</a></li> |
| 247 | <li><a href="caps/admin-v-setup.md">Setup and Admin Users — Differences Between</a></li> |
| 248 | <li><a href="caps/login-groups.md">Setup and Admin Users — Differences Between</a></li> |
| 249 | <li><a href="hashpolicy.wiki">SHA1 and SHA3-256 — Hash Policy: Choosing Between</a></li> |
| 250 | <li><a href="hashpolicy.wiki">SHA3-256 — Hash Policy: Choosing Between SHA1 and</a></li> |
| 251 | <li><a href="shunning.wiki"><b>Shunning: Deleting Content From Fossil</b></a></li> |
| 252 | <li><a href="fiveminutes.wiki">Single User — Up and Running in 5 Minutes as a</a></li> |
| 253 | <li><a href="../../../sitemap"><b>Site Map</b></a></li> |
| @@ -263,11 +270,10 @@ | |
| 270 | <li><a href="../test/release-checklist.wiki">Testing Checklist — Pre-Release</a></li> |
| 271 | <li><a href="th1.md">TH1 Scripting Language — The</a></li> |
| 272 | <li><a href="backoffice.md"><b>The "Backoffice" mechanism of Fossil</b></a></li> |
| 273 | <li><a href="blame.wiki"><b>The Annotate/Blame Algorithm Of Fossil</b></a></li> |
| 274 | <li><a href="defcsp.md"><b>The Default Content Security Policy</b></a></li> |
| 275 | <li><a href="makefile.wiki"><b>The Fossil Build Process</b></a></li> |
| 276 | <li><a href="sync.wiki"><b>The Fossil Sync Protocol</b></a></li> |
| 277 | <li><a href="tickets.wiki"><b>The Fossil Ticket System</b></a></li> |
| 278 | <li><a href="webui.wiki"><b>The Fossil Web Interface</b></a></li> |
| 279 | <li><a href="th1.md"><b>The TH1 Scripting Language</b></a></li> |
| @@ -281,11 +287,14 @@ | |
| 287 | <li><a href="bugtheory.wiki">Tracking In Fossil — Bug</a></li> |
| 288 | <li><a href="unvers.wiki"><b>Unversioned Files</b></a></li> |
| 289 | <li><a href="fiveminutes.wiki"><b>Up and Running in 5 Minutes as a Single User</b></a></li> |
| 290 | <li><a href="hints.wiki">Usage Hints — Fossil Tips And</a></li> |
| 291 | <li><a href="fiveminutes.wiki">User — Up and Running in 5 Minutes as a Single</a></li> |
| 292 | <li><a href="caps/">User Capabilities — Administering</a></li> |
| 293 | <li><a href="caps/ref.html"><b>User Capability Reference</b></a></li> |
| 294 | <li><a href="caps/admin-v-setup.md">Users — Differences Between Setup and Admin</a></li> |
| 295 | <li><a href="caps/login-groups.md">Users — Differences Between Setup and Admin</a></li> |
| 296 | <li><a href="serverext.wiki">Using CGI Scripts — Adding Extensions To A Fossil Server</a></li> |
| 297 | <li><a href="ssl.wiki"><b>Using SSL with Fossil</b></a></li> |
| 298 | <li><a href="env-opts.md">Variables and Global Options — Environment</a></li> |
| 299 | <li><a href="whyusefossil.wiki">Version Control — Benefits Of</a></li> |
| 300 | <li><a href="checkin_names.wiki">Version Names — Check-in And</a></li> |
| 301 |
+5
-5
| --- www/server/index.html | ||
| +++ www/server/index.html | ||
| @@ -77,11 +77,11 @@ | ||
| 77 | 77 | minimum recommended preparation steps:</p> |
| 78 | 78 | |
| 79 | 79 | <ol> |
| 80 | 80 | <li><p>Fossil creates only one user in a <a |
| 81 | 81 | href="$ROOT/help?cmd=new">new repository</a> and gives it the <a |
| 82 | - href="../admin-v-setup.md">all-powerful Setup capability</a>. (“s”) | |
| 82 | + href="../caps/admin-v-setup.md#apsu">all-powerful Setup capability</a>. | |
| 83 | 83 | The 10-digit random password generated for that user is fairly strong |
| 84 | 84 | against remote attack, even without explicit password guess rate |
| 85 | 85 | limiting, but because that user has so much power, you may want to |
| 86 | 86 | give it a much stronger password under Admin → Users.</a></li> |
| 87 | 87 | |
| @@ -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 | |
| @@ -77,11 +77,11 @@ | |
| 77 | minimum recommended preparation steps:</p> |
| 78 | |
| 79 | <ol> |
| 80 | <li><p>Fossil creates only one user in a <a |
| 81 | href="$ROOT/help?cmd=new">new repository</a> and gives it the <a |
| 82 | href="../admin-v-setup.md">all-powerful Setup capability</a>. (“s”) |
| 83 | The 10-digit random password generated for that user is fairly strong |
| 84 | against remote attack, even without explicit password guess rate |
| 85 | limiting, but because that user has so much power, you may want to |
| 86 | give it a much stronger password under Admin → Users.</a></li> |
| 87 | |
| @@ -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 | |
| @@ -77,11 +77,11 @@ | |
| 77 | minimum recommended preparation steps:</p> |
| 78 | |
| 79 | <ol> |
| 80 | <li><p>Fossil creates only one user in a <a |
| 81 | href="$ROOT/help?cmd=new">new repository</a> and gives it the <a |
| 82 | href="../caps/admin-v-setup.md#apsu">all-powerful Setup capability</a>. |
| 83 | The 10-digit random password generated for that user is fairly strong |
| 84 | against remote attack, even without explicit password guess rate |
| 85 | limiting, but because that user has so much power, you may want to |
| 86 | give it a much stronger password under Admin → Users.</a></li> |
| 87 | |
| @@ -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 |