Since diaspora* 0.6.0.0, diaspora* is an OpenID provider. Would it be possible to allow users to sign in discourse using their diaspora* account? I don’t know if many users are blocked by the registering but eh, that would definitely be an improvement and a nice demonstration of the feature.
2 Likes
I was investigating this feature back when we were using loomio.
The main problem with that is that diaspora uses different hosts for different pods while most of the OAuth modules suggest that you have only single domain name for the service. Github is always github.com, and diaspora* can be any domain name at all. So implementing this will likely require some hacking on OAuth/OpenID Connect modules which are available for the platform we want to integrate with. And that will require both frontend hacking (we need to ask a user about his pod’s address) and backend (there is an optional extention to OpenID Connect which we need to use and which is not normally required for single domain services, see OpenID Connect Dynamic Client Registration).
So while it is completely possible, it requires a considerable amount of work, and since we use Discourse which is written with PHP, we need to use PHP for that, which, I guess, is not a very familiar language to most of active diaspora developers.
Basically we need to extend Discourse to support “login using diaspora”. Maybe it’s even possible to get some help from the Discourse community, and maybe some other Discourse deploys would like to use this feature as well.
I have some (little) experience in PHP and I feel that I can implement it at least “somehow”, maybe in a non-perfect way, which is still better than nothing. But currently I have higher priority tasks for diaspora*, so I’m not sure I’ll be able to work on that any time soon, but I would totally love to.
Discourse is a Ruby on Rails application. The only piece of PHP we use is, in fact, the wiki, and that’s only because there is no sensible replacement for MediaWiki. 
Discourse has a plugin system, and we could create an extension handling this, but there is a lot of work involved, as @comradesenya mentioned. I agree we should have it eventually, but I am not sure I want to invest time in implementing it right now.
3 Likes
Oh, I confused it in my head for some reason! Then it makes things a little bit simpler. And I could apply some of my findings I got when I was playing with Loomio (I guess Discourse uses the same modules for OpenID connect support, because there isn’t any actual choice).
But anyway, I can’t do that right now. Maybe later at some point, if nobody does it before that 
2 Likes
It looks like a nice contribution for someone who wants to help diaspora* but don’t want to code for the software itself. Maybe we could make a call for contributors?
If that someone is willing to dive into Discourse plugin API (which basically means reading through their implementations, since there is no 100% good documentation for it), figuring out how to implement OpenID and is willing to do it, sure. Not a fun task, but a doable one for sure.
1 Like
I don’t think that it could actually help. I don’t see much difference in missing contributors for diaspora and missing contributors for diaspora plugin for discourse. If we miss people who wants to work on diaspora why there will be anyone who wants to work on the plugin.
1 Like
Many persons are reluctant to contribute to diaspora because setting up a dev env is too complicated and make a mess in their computer. The codebase is also huge. Discourse is maybe better than ourselves on those two points?
For this task you’ll likely need to set up both diaspora instance and discourse instance, so it’s harder than that.
1 Like
In addition to what senya said… The only “easy” thing is getting it running the first time, since you can use a Docker image. But as soon as you need to do actual dev work, you need a non-docker setup, and their setup is actually more complicated than ours. Also, don’t underestimate the size of Discourses code
1 Like
Maybe we can open a feature request on discourse for that just to record the fact we would like to see this implemented? Then we can promote this feature request and see if anyone wants to contribute with code or maybe some bounties for a possible developer (though I don’t know if it’s possible to do with bountysource).
1 Like
No objections. Although I wouldn’t put any hope into having their official team implementing it, since they have a lot to do. But yes, it’s a great way to promote that, and maybe have the community jump in!
2 Likes
Also as I see on this page, Discourse team actually offers to develop plugins for money. So maybe we could even run some crowdfunding and hire Discource people for that?
Personally, I’d love to implement this feature myself (I feel some interest towards it, also I did a research already). But I don’t know when I can get to it, so if we want it fast, then running a crowdfunding can make it happen faster. In this case we should contact the Discourse team first and negotiate the price.
I feel that there is no reason to hurry and that it is totally fine if we implement it ourselves after some months. But I won’t oppose anyones attempts to run any fundraisers to hire the discourse team or someone else.
1 Like
We can ask if somebody already knows the Discourse plugin API, that would be an advantage … but otherwise it probably doesn’t make much sense to ask a random person who doesn’t know discourse to do that work. (If there is a person who is able and willing to help us with this discourse plugin they could also help with diaspora, so I don’t know why they want to help us here but don’t want to code for the software itself.)
most of the OAuth modules suggest that you have only single domain name for the service. Github is always github.com, and diaspora* can be any domain name at all.
Erm but that’s not the way OpenID usually work, is it?
So maybe there is a general OpenID-Plugin, that allowes any ID-provider (not just diaspora*). Such could be used and/or relabeled as “login with diaspora”
That’s what I thought yes, an OpenID plugin should allow you to log in using any open id provider, so any diaspora* pod.
When you use “single-domain” setup, you normally register each domain manually. For example, if I want to set up “login with GitHub” at my website, then I go to GitHub, register my application and get credentials that my website will then pass to github.com each time a user of my website wants to login with their github account.
When we want the same for diaspora, there are two problems about it:
-
We don’t know every pod hostname, so we can’t get credentials for external website (Discourse in our case) in advance. Everytime person may want to log into Discourse using a pod which our Discourse deploy is not aware of, we’ll miss OpenID credentials for that pod.
-
Credentials should be crafted and passed to the external website at the time, when diaspora pod is discovered by external in automated way, we can’t ask discourse admin to register each pod manualy (like it is normally done for single-domain services).
In order to provide this usecase, OpenID Connect introduces OpenID Connect Dynamic Client Registration. It allows to register OpenID Client (Discourse) at OpenID Provider (a Diaspora pod) dynamically and pass credentials to the client.
But there are still some issues about this:
-
Ruby support for OpenID Connect Dynamic Client Registration is poor and will likely require patching existing OpenID Connect implementations.
-
We need to request pod hostname from the user, and most of OpenID Connect client frontends doesn’t provide the way to do that, so we need to patch frontend code, which is harder than just add another new provider (while adding facebook login when we have github login won’t need any additional UI handling).
-
For OID dynamic registration we need to store access credentials for all known pods in dynamic way, so we need to keep them in a database. Most of the time, for usual cases credentials are just stored in text config files, which are edited by a website admin. In order to implement the desired behavior, we need to patch backend code and database schema as well.
So comparing to adding github login, adding diaspora login would require changing in frontend and backend of the external website (Discourse in our case) and in some 3rd party gems (OID implementation). I didn’t look at Discourse code yet, but this was the case for Loomio when I checked that, and I don’t see any reasons why this should be solved somewhere, because usually “login with” are done with single domain websites and this complexity isn’t required. I think you can see that this is considerable amount of work.
Good news are, that when we solve that once for some service, it will be much easier to implement it for other services, especially RoR based (like OpenStreetMaps). And other federated projects may reuse our work afterwards. But that is the special price for the federation and nobody paid it yet (or not that I’m aware of).
1 Like
Ah okay, I didn’t know this is something “special” I thought this is how OpenID is ment: Find someone you trust (e.g. your email provider maybe your own domain) and use this as your identity dealer.
I didn’t know it’s a big deal to allow just any domain. And it’s really a pity this is such unusual, because nobody can be her own OpenID provider 
And this is nothing about [quote=“comradesenya, post:17, topic:871”]
that is the special price for the federation
[/quote]
I’d say, that is the price you pay if you want just an open web(?) with more but two companies handling identities.
But sure… I see your point here.
There is difference between OpenID and OpenID Connect. The first one may provide what you say, but it is considred obsolete these days and it is replaced with OpenID Connect. OpenID Connect provide this as well (with dynamic registration), but the issue is that it is just not implemented in some reusable way.
I looked into making it possible to login to discourse with a diaspora account. I mostly understand how to create a plugin for that.
One of the features that I wanted to support is pod auto-detection using our web+diaspora:// links. My idea was that if a web browser already knows the user’s pod as an entity registered as a link handler we could use that to “auto-detect” the pod. What I tried to do is by using some javascript create a popup window with web+diaspora:// url and read the pod address after it is loaded (as was described here in 2012). However this doesn’t seem to work in modern browsers due to security restrictions. We can read the address from a popup window only when the window has a URL from the same origin as the parent window.
So the only way I can see how we can auto-detect a pod is by implementing a redirect endpoint for our custom protocol handler. For instance if we want to discover the user’s pod by a web+diaspora:// link, we should ask browser to open something like web+diaspora://redirect/me?to=https://a.third.party.website.url/diaspora_auth?url=%h and then diaspora* will redirect the browser to https://a.third.party.website.url/diaspora_auth?url=pod.diaspora.tld where pod.diaspora.tld is the pod hostname of a currently set links handler. This way the third party website will “detect” the pod and therefore could do:
- OpenID Connect dynamic client registration
- Authorization against this pod
Of course we could just ask the users of their pod host name at the beginning of the sign in procedure, but
- Not every user knows what pod host name is
- diaspora* will be less fancy than other social networks/OIDC providers which don’t ask any questions but just authenticate.
- It’s more work to integrate an authentication strategy which requires some extra UI besides just usual things which other authentication providers have.
What does community think?