Based on further conversation with @ntnsndr in Matrix chat I wonder if we should experiment by bringing up a dokuwiki instance at wiki2.social.coop. I think ideally we would set it up on runko using our Ansible playbook?
This might be related to #63 (closed) since we we will want to update the nginx configuration and run dokuwiki in a Docker container?
It looks like we will want to install the oath2 plugin for dokuwiki. It's possible that the Generic Service will work with a little configuration, but we may have to implement our own since Mastodon isn't one of those listed. There do appear to be instructions so maybe it won't be too hard?
I did some work to get the dokuwiki-plugin-oauth and dokuwiki-plugin-oauthdoorkeeper plugins working with Mastodon. See this branch for the changes that were needed to get the doorkeeper code to work properly with Mastodon's usage of doorkeeper:
Unfortunately Mastodon don't make the email address for the authenticated user available, and the dokuwiki oauth plugin really relies on having one. Instead a synthetic email is created using the Mastodon username and the host of the Mastodon server supplying the credentials. This "works" for login purposes, but is not a functional email address.
After some discussion in Matrix it seems like pursuing a single-sign-on solution that is not Mastodon, e.g. similar to what Cloudron provides, might be more preferable long term.
If you want to try out the test you will need to make a directory with this docker-compose.yml in it:
Thank you for your efforts here. Sounds like building a central SSO provider is an important medium-term priority for Sc. In the long term I think it is super strategic in case we want to migrate away from Mastodon.
auth.social.coop is up and running
wiki.social.coop is up and running using the above
Remaining: set up backups and restores for both and coordinate account creation further; but these should be tracked in separate bugs in the same component.