Fossil SCM
Expanded the SSO discussion in the new forum.wiki document
Commit
dd0a2dd3d3bb84995cf62671fdc0b4189988b78d1a01f1a51bd7457634e7ffb1
Parent
76ca1f829f9b3b1…
1 file changed
+18
-16
+18
-16
| --- www/forum.wiki | ||
| +++ www/forum.wiki | ||
| @@ -121,26 +121,28 @@ | ||
| 121 | 121 | |
| 122 | 122 | |
| 123 | 123 | <h3>Single Sign-On</h3> |
| 124 | 124 | |
| 125 | 125 | If you choose to host your discussion forums within the same repository |
| 126 | -as your other Fossil-managed content, you inherently have a single | |
| 127 | -sign-on system. Contrast a mailing list or a third-party forum system, | |
| 128 | -where you either end up with two seaprate user tables and permission | |
| 129 | -sets, or you must go to significant effort to integrate the two login | |
| 130 | -systems. | |
| 131 | - | |
| 132 | -You may instead choose to host your forums in a separate repository from | |
| 133 | -your other assets, as may be done for a public project where very few of | |
| 134 | -those participating in the forum have special permissions for assets | |
| 135 | -managed by Fossil for the project itself. | |
| 136 | - | |
| 137 | -Or, you may split the difference, hosting the forum in a separate | |
| 138 | -repository from the other assets yet use Fossil's login groups feature | |
| 139 | -to get single sign-on for both repositories. You might choose to do | |
| 140 | -this to remove the forum traffic from the size of the main respository's | |
| 141 | -clones, for example. | |
| 126 | +as your project's other Fossil-managed content, you inherently have a | |
| 127 | +single sign-on system. Contrast third-party mailing list and forum | |
| 128 | +software where you either end up with two separate user tables and | |
| 129 | +permission sets, or you must go to significant effort to integrate the | |
| 130 | +two login systems. | |
| 131 | + | |
| 132 | +You may instead choose to host your forums in a separate Fossil | |
| 133 | +repository from your other assets. A good reason to do this is that you | |
| 134 | +have a public project where very few of those participating in the forum | |
| 135 | +have special permissions for assets managed by Fossil for the project | |
| 136 | +itself, so you wish to segregate the two user sets. | |
| 137 | + | |
| 138 | +Fossil offers a way to split the difference: you can host your forum in | |
| 139 | +a repository separate from your other Fossil-managed content yet still | |
| 140 | +have single sign-on for that common set of users that will have logins | |
| 141 | +on both repositories. Simply enable Fossil's login groups feature in | |
| 142 | +Admin → Login-Group, which allows one Fossil repository to | |
| 143 | +recognize users authorized on another repository. | |
| 142 | 144 | |
| 143 | 145 | |
| 144 | 146 | <h3>Email Notification</h3> |
| 145 | 147 | |
| 146 | 148 | See [./emaildesign.md | the email notification design document] for now. |
| 147 | 149 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -121,26 +121,28 @@ | |
| 121 | |
| 122 | |
| 123 | <h3>Single Sign-On</h3> |
| 124 | |
| 125 | If you choose to host your discussion forums within the same repository |
| 126 | as your other Fossil-managed content, you inherently have a single |
| 127 | sign-on system. Contrast a mailing list or a third-party forum system, |
| 128 | where you either end up with two seaprate user tables and permission |
| 129 | sets, or you must go to significant effort to integrate the two login |
| 130 | systems. |
| 131 | |
| 132 | You may instead choose to host your forums in a separate repository from |
| 133 | your other assets, as may be done for a public project where very few of |
| 134 | those participating in the forum have special permissions for assets |
| 135 | managed by Fossil for the project itself. |
| 136 | |
| 137 | Or, you may split the difference, hosting the forum in a separate |
| 138 | repository from the other assets yet use Fossil's login groups feature |
| 139 | to get single sign-on for both repositories. You might choose to do |
| 140 | this to remove the forum traffic from the size of the main respository's |
| 141 | clones, for example. |
| 142 | |
| 143 | |
| 144 | <h3>Email Notification</h3> |
| 145 | |
| 146 | See [./emaildesign.md | the email notification design document] for now. |
| 147 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -121,26 +121,28 @@ | |
| 121 | |
| 122 | |
| 123 | <h3>Single Sign-On</h3> |
| 124 | |
| 125 | If you choose to host your discussion forums within the same repository |
| 126 | as your project's other Fossil-managed content, you inherently have a |
| 127 | single sign-on system. Contrast third-party mailing list and forum |
| 128 | software where you either end up with two separate user tables and |
| 129 | permission sets, or you must go to significant effort to integrate the |
| 130 | two login systems. |
| 131 | |
| 132 | You may instead choose to host your forums in a separate Fossil |
| 133 | repository from your other assets. A good reason to do this is that you |
| 134 | have a public project where very few of those participating in the forum |
| 135 | have special permissions for assets managed by Fossil for the project |
| 136 | itself, so you wish to segregate the two user sets. |
| 137 | |
| 138 | Fossil offers a way to split the difference: you can host your forum in |
| 139 | a repository separate from your other Fossil-managed content yet still |
| 140 | have single sign-on for that common set of users that will have logins |
| 141 | on both repositories. Simply enable Fossil's login groups feature in |
| 142 | Admin → Login-Group, which allows one Fossil repository to |
| 143 | recognize users authorized on another repository. |
| 144 | |
| 145 | |
| 146 | <h3>Email Notification</h3> |
| 147 | |
| 148 | See [./emaildesign.md | the email notification design document] for now. |
| 149 |