You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the only authentication mechanism is reading the Remote-User HTTP header. In order to be easier to install, the website should provide other options for authentication. Some options:
local user accounts with email/password
email magic link
configurable OAuth provider (e.g. log in with GitHub, Google, Twitter, IndieAuth, etc)
Some open questions:
Should an instance be able to support multiple providers (e.g. GitHub and Twitter) and if so, how to deal with duplicate/merging accounts?
Some instances may want to limit editing capability even for logged-in users, so there may need to be added a permissions system so that only certain users can do things like edit events or moderate responses
The text was updated successfully, but these errors were encountered:
There is now a GitHub authentication option in addition to the Remote-User header.
To keep things simple, only one authentication mechanism will be defined. This lets us keep the logic for each authenticator in a small list of classes and add new ones if needed.
I would like to define a Twitter authentication method later, but for now I'm going to call this done. Separately we will also deal with a permissions system so that there are different roles for users such as adding events vs just RSVP'ing.
Currently the only authentication mechanism is reading the
Remote-User
HTTP header. In order to be easier to install, the website should provide other options for authentication. Some options:Some open questions:
The text was updated successfully, but these errors were encountered: