Fossil SCM
More SSO discussion improvements in forum.wiki
Commit
bc303c0ec006ab3109261788dcf99d71dc8b671df8dbfea68ac74b2922d0182f
Parent
5d75504af03e045…
1 file changed
+15
-12
+15
-12
| --- www/forum.wiki | ||
| +++ www/forum.wiki | ||
| @@ -156,22 +156,25 @@ | ||
| 156 | 156 | single sign-on system. Contrast third-party mailing list and forum |
| 157 | 157 | software where you either end up with two separate user tables and |
| 158 | 158 | permission sets, or you must go to significant effort to integrate the |
| 159 | 159 | two login systems. |
| 160 | 160 | |
| 161 | -You may instead choose to host your forums in a separate Fossil | |
| 162 | -repository from your other assets. A good reason to do this is that you | |
| 163 | -have a public project where very few of those participating in the forum | |
| 164 | -have special capability bits for assets managed by Fossil for the | |
| 165 | -project itself, so you wish to segregate the two user sets. | |
| 166 | - | |
| 167 | -Fossil offers a way to split the difference: you can host your forum in | |
| 168 | -a repository separate from your other Fossil-managed content yet still | |
| 169 | -have single sign-on for that common set of users that will have logins | |
| 170 | -on both repositories. Simply enable Fossil's login groups feature in | |
| 171 | -Admin → Login-Group, which allows one Fossil repository to | |
| 172 | -recognize users authorized on another repository. | |
| 161 | +You may instead choose to host your forums in a Fossil repository | |
| 162 | +separate from your project's main Fossil repository. A good reason to do | |
| 163 | +this is that you have a public project where very few of those | |
| 164 | +participating in the forum have special capability bits for project | |
| 165 | +assets managed by Fossil, so you wish to segregate the two user sets. | |
| 166 | + | |
| 167 | +Yet, what of the users who will have logins on both repositories? Some | |
| 168 | +users will be trusted with access to the project's main Fossil | |
| 169 | +repository, and these users will probably also participate in the | |
| 170 | +project's Fossil-hosted forum. | |
| 171 | + | |
| 172 | +Fossil has a feature to solve this problem that is probably less well | |
| 173 | +known than it should be, which has been in the software since April of | |
| 174 | +2011: Admin → Login-Group, which allows one Fossil repository to | |
| 175 | +recognize users authorized on another Fossil repository. | |
| 173 | 176 | |
| 174 | 177 | |
| 175 | 178 | <h3>Email Notification</h3> |
| 176 | 179 | |
| 177 | 180 | See [./emaildesign.md | the email notification design document] for now. |
| 178 | 181 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -156,22 +156,25 @@ | |
| 156 | single sign-on system. Contrast third-party mailing list and forum |
| 157 | software where you either end up with two separate user tables and |
| 158 | permission sets, or you must go to significant effort to integrate the |
| 159 | two login systems. |
| 160 | |
| 161 | You may instead choose to host your forums in a separate Fossil |
| 162 | repository from your other assets. A good reason to do this is that you |
| 163 | have a public project where very few of those participating in the forum |
| 164 | have special capability bits for assets managed by Fossil for the |
| 165 | project itself, so you wish to segregate the two user sets. |
| 166 | |
| 167 | Fossil offers a way to split the difference: you can host your forum in |
| 168 | a repository separate from your other Fossil-managed content yet still |
| 169 | have single sign-on for that common set of users that will have logins |
| 170 | on both repositories. Simply enable Fossil's login groups feature in |
| 171 | Admin → Login-Group, which allows one Fossil repository to |
| 172 | recognize users authorized on another repository. |
| 173 | |
| 174 | |
| 175 | <h3>Email Notification</h3> |
| 176 | |
| 177 | See [./emaildesign.md | the email notification design document] for now. |
| 178 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -156,22 +156,25 @@ | |
| 156 | single sign-on system. Contrast third-party mailing list and forum |
| 157 | software where you either end up with two separate user tables and |
| 158 | permission sets, or you must go to significant effort to integrate the |
| 159 | two login systems. |
| 160 | |
| 161 | You may instead choose to host your forums in a Fossil repository |
| 162 | separate from your project's main Fossil repository. A good reason to do |
| 163 | this is that you have a public project where very few of those |
| 164 | participating in the forum have special capability bits for project |
| 165 | assets managed by Fossil, so you wish to segregate the two user sets. |
| 166 | |
| 167 | Yet, what of the users who will have logins on both repositories? Some |
| 168 | users will be trusted with access to the project's main Fossil |
| 169 | repository, and these users will probably also participate in the |
| 170 | project's Fossil-hosted forum. |
| 171 | |
| 172 | Fossil has a feature to solve this problem that is probably less well |
| 173 | known than it should be, which has been in the software since April of |
| 174 | 2011: Admin → Login-Group, which allows one Fossil repository to |
| 175 | recognize users authorized on another Fossil repository. |
| 176 | |
| 177 | |
| 178 | <h3>Email Notification</h3> |
| 179 | |
| 180 | See [./emaildesign.md | the email notification design document] for now. |
| 181 |