tag properly

[git.ikiwiki.info.git] / doc / todo / emailauth.mdwn

diff --git a/doc/todo/emailauth.mdwn b/doc/todo/emailauth.mdwn
index 05b7f1177d22914bb45feb90ce922ef0c078d998..de5d2b1195060d9487b34b2842e1891c98976f25 100644 (file)
--- a/doc/todo/emailauth.mdwn
+++ b/doc/todo/emailauth.mdwn
@@ -62,14 +62,79 @@ Implementation notes:
   Otherwise, someone could use passwordauth to register as a username that
   looks like an email address, which would be confusing to possibly a
   security hole. Probably best to keep passwordauth and emailauth accounts
   Otherwise, someone could use passwordauth to register as a username that
   looks like an email address, which would be confusing to possibly a
   security hole. Probably best to keep passwordauth and emailauth accounts

-  entirely distinct.
+  entirely distinct. Update: passwordauth never allowed `@` in usernames.

 * Currently, subscription to comments w/o registering is handled by
   passwordauth, by creating a passwordless account (making up a username,
   not using the email address as the username thankfully). That account can be
   upgraded to a passworded account if the user follows a link in comment
 * Currently, subscription to comments w/o registering is handled by
   passwordauth, by creating a passwordless account (making up a username,
   not using the email address as the username thankfully). That account can be
   upgraded to a passworded account if the user follows a link in comment

-  mails to login. So there is considerable overhead between that and
+  mails to login. So there is considerable overlap between that and

   emailauth.
 * Adapting the passwordauth reset code is probably the simplest way to
   implement emailauth. That uses a CGI::Session id as the entropy.
 
   emailauth.
 * Adapting the passwordauth reset code is probably the simplest way to
   implement emailauth. That uses a CGI::Session id as the entropy.
 

+----
+
+So this all seems doable. What I'm unsure about is this: Is emailauth going
+to be sufficiently easier than passwordauth that it will let users
+contribute to wikis who otherwise wouldn't?
+
+Using passwordauth, the user can register by just picking a password, and
+username, and entering email. That's 2 more things that need to be entered,
+but then there is no need to wait for an email link to arrive. Which can
+take a while, or be an unreliable, opaque process for users.
+
+OTOH, maybe some users don't want to have to make up a username and
+password, or pchycologically don't want to register. emailauth would then
+let them contiribute.
+
+I also have a motivation for ikiwiki-hosting/branchable. That needs the
+user to be able to log into the site, create their own wiki, and then log
+into their own wiki. Currently, openid is the only way to do that;
+emailauth would be another way.
+
+Another motivation from ikiwiki-hosting/branchable is that with google
+openid going away, many sites can have only google openids as adminusers, and
+that has to be manually dealt with. But if emailauth is added, those
+adminusers can be converted, perhaps automatically, to use the email
+addresses on record.
+

 Thoughts anyone? --[[Joey]]
 Thoughts anyone? --[[Joey]]

+
+> I had looked at something like this before, through [[todo/indyauth_support]] - which basically turned out to outsource their own auth to http://intridea.github.io/omniauth/ and http://indiewebcamp.com/RelMeAuth...
+> 
+> But it seems to me that your proposal is basic "email opt-in".. the one impact this has on (drupal) sites i know is that spammers use even those forms to send random emails to users. it's weird, but it seems that some bots simply try to shove victim's emails into forms with the spam data as they can and hope for the best... it seems this could be vulnerable as well... - [[anarcat]]
+
+>> Implemented now. [[done]]
+>> 
+>> Only thing that we might want to revisit sometime is that the email address
+>> is used in git commits. While it won't be displayed on any static wiki 
+>> pages (AFAICS), spammers could find it in the git commit log.
+>>
+>> Of course, spammers can troll git repos for emails anyway, so maybe
+>> this is fine. --[[Joey]]
+
+>>> I'm not so sure this is OK: user expectations for "a random wiki/blog"
+>>> are not the same as for direct git contributions. Common practice for
+>>> websites is for email addresses to be only available to the site owner
+>>> and/or outsourced services - if ikiwiki doesn't work like this,
+>>> I think wiki contributors/blog commenters are going to blame ikiwiki,
+>>> not themselves.
+>>>
+>>> One way to avoid this would be to
+>>> [[separate authentication from authorization]], so our account names
+>>> would be smcv and joey even on a purely emailauth wiki, with the
+>>> fact that we authenticate via email being an implementation detail.
+>>>
+>>> Another way to do it would be to hash the email address,
+>>> so the commit appears to come from
+>>> `smcv <smcv@02f3eecb59311fc89970578832b63d57a071579e>` instead of
+>>> from `smcv <smcv@debian.org>` - if the hash is of `mailto:whatever`
+>>> (like my example one) then it's compatible with
+>>> [FOAF](http://xmlns.com/foaf/spec/#term_mbox_sha1sum).
+>>> --[[smcv]]a
+
+>>> Email addresses are now cloaked in commits, using foaf:mbox_sha1sum. --[[Joey]]
+
+Note that the implementation of this lives in [[plugins/emailauth]].
+
+Also, I have found a similar system called [Portier](https://portier.github.io) that enables email-based auth but enhances it with [[plugins/openid]] connect... Maybe ikiwiki's authentication system could follow the standards set by Portier? OpenID connect discovery is particularly interesting, as it could mean that using your GMail address to login to ikiwiki would mean that you go straight to the more secure OpenID / Oauth authentication instead of relying on the slow "send email and click link" system... --[[anarcat]]