Most of the context is in the title.
We are in the process of making some changes to the SSO login. The result is that a user can login without a redirecting away from the discourse site.
This is achieved by opening an iframe to the sso provider. And then only redirecting to the sso_login url once that frame has returned a token.
Why wouldn’t you make modifications using the plugin architecture? Then the issue falls away.
I’m still looking through the source so maybe it will work. but getting more convinced the plugin architecture doesn’t give me quite enough control to achieve what I need.
I think you have to consider the architecture and not get too insistent on having an embedded iframe, for example.
Pop-up login windows and callbacks are standard practice, for example, and very straightfoward with a plugin.
Managing a fork of Discourse would be an utterly inefficient approach and an ongoing nightmare. In contrast, if built right, plugins can be very robust to change and require much less maintenance.
Those who tried to maintain a forked version of Discourse are very sorry. You’ll either need to have a full time developer or integrate changes or never upgrade. And in the end you’ll move to a plugin.
I suspect that you can do what you need in a plugin, or could make it do whet you need through a PR. You should either explain why you think you can’t solve your problem in a plugin or post in #marketplace for help.
I manage discourse as a part of my business (Discourse Server Maintenance — Literate Computing, LLC) and have a few clients who need custom configuration but cannot afford enterprise level hosting. I would love your business, but wouldn’t consider supporting a fork.
A plug in would be better, if possible.
I will keep investigating, it is useful to see how separate our protocol is from OAuth anyway.
I can also confirm that at Discourse.org we would not host a fork of Discourse either, even on our Enterprise Plan. You must create plugins/theme components for your changes