cmackenzie1
Joined 7 years ago
Karma
37
Submissions
8
Member since
Aug 5
Recent submissions
Comment · 1 year ago
If the library wasn't open for extension, an enum could work. With the currently model, users can write their own plugins, bring their own storage provider, or even write an email consumer that reacts to events from the EventBus - all without needing to upstream their changes to torii and torii-core.
Comment · 1 year ago
If you are looking to add another provider, one can do so here: https://github.com/cmackenzie1/torii-rs/tree/main/torii-auth...
If you want change the plugin logic completely, you can implement the Plugin trait and register the plugin with the plugin manager: https://github.com/cmackenzie1/torii-rs/blob/main/torii-core...
Doing the latter, you can also bring your own storage provider.
Comment · 1 year ago
I’ve gone back and forth on using TypeId or named plugins using a string. Mainly switched to the named variant to support each oauth provider lookup by name.
If you have any suggestions for making it better, let me know!
Comment · 1 year ago
JavaScript definitely has a few such OpenAuthJS, Better-Auth, and Next-Auth.
PHP Laravel, Ruby on Rails, Python Django, Elixir Phoenix all have some ways of doing this, but are usually baked into the framework.
Others usually end up as a standalone service like Keycloak, Authelia and more.