Open chizutan5 opened 1 year ago
I don't know how to do this, but I like the idea :)
I don't know how to do this, but I like the idea :)
There is a couple mediawiki extensions that do it, although I had to have them customised since they don't support non standard oauth data. So maybe that's somewhere to have a look at to get a feel for the concept and how it was implemented over there. I'm also happy to drop a couple dollars in crypto to whoever wants to take this on, since this would be really helpful to me.
Is your feature request related to a problem? Please describe. A lot of sites that have boorus often have them as an extension to an already existing site (such as a forum or a fediverse instance), unfortunately this means that you need to have two accounts and keep track of two passwords, the convenient thing would be to use a single account on their main service and then use oauth for each other service they host, including a booru. This also allows people to control who they let into their booru easier, if it is for example a private community. Because even with an account approval type system, it needs someone to moderate it. With the current options that becomes manually generating accounts and handing them out on request. But with oauth, the admins only need to approve users on their main service, and then they can sign up to the other services that the site provides easily on their own.
Describe the solution you'd like The idea would be to have an oauth button on the login page which prompts authentication with the administrators specified site (in addition to, or replacing the standard login with username system), it would be convenient to have multiple oauth options so that a user can log in from more than one site as well, such as if a booru is shared between a few associated sites.
What would likely be the best and lowest maintainance option would be to follow the format that writefreely uses for it's "Generic Oauth" and allow the user to customise on their own each part of the oauth, so that sites using non standard names for the data that it provides back to the client can be used too (such as pleroma providing "fqn" instead of "email"). This way you're not spending the time trying to support multiple sites individually, but instead are allowing the user to customise it as they need, and solve a problem that happens with some oauth implementations where sites send back different data names than some software expects. Gitea for example will not let you generate an account unless the oauth server provides back the "email" field.
Describe alternatives you've considered There isn't really an alternative as far as I am aware, I don't know of any booru software doing something like this. Though an account approval system is the "next best" solution to the initial problem.
Additional context If more explaination or clarification is needed, I am open to giving it.