]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/commitdiff
Do not directly enable emailauth by default, only indirectly via openid
authorSimon McVittie <smcv@debian.org>
Wed, 27 May 2015 07:52:01 +0000 (08:52 +0100)
committerSimon McVittie <smcv@debian.org>
Wed, 27 May 2015 07:52:01 +0000 (08:52 +0100)
This avoids nasty surprises on upgrade if a site is using httpauth,
or passwordauth with an account_creation_password, and relying on
only a select group of users being able to edit the site. We can revisit
this for ikiwiki 4.

IkiWiki.pm
IkiWiki/Plugin/openid.pm
debian/NEWS
debian/changelog
doc/plugins/emailauth.mdwn
doc/todo/emailauth.mdwn
doc/todo/separate_authentication_from_authorization.mdwn

index 8244fa99607aaf42d5dae9c76d7fe76db6018ab7..6e19d482a899073fd790baef18d44d78e389e9f0 100644 (file)
@@ -165,7 +165,7 @@ sub getsetup () {
        default_plugins => {
                type => "internal",
                default => [qw{mdwn link inline meta htmlscrubber passwordauth
-                               openid emailauth signinedit lockedit conditional
+                               openid signinedit lockedit conditional
                                recentchanges parentlinks editpage
                                templatebody}],
                description => "plugins to enable by default",
index cc4b4ba3d4949c737d0d2139729a25c971743ff1..35ef52a581e745a38d11b5d43a57d8dc4cab558e 100644 (file)
@@ -11,6 +11,7 @@ sub import {
        hook(type => "auth", id => "openid", call => \&auth);
        hook(type => "formbuilder_setup", id => "openid",
                call => \&formbuilder_setup, last => 1);
+       IkiWiki::loadplugin("emailauth");
        IkiWiki::loadplugin("loginselector");
        IkiWiki::Plugin::loginselector::register_login_plugin(
                "openid",
index d09b4d9be7c3ecb725c60466c32204484c1d284f..c1f343520fa65a970c6d3eeaf2c56ffa28bb6316 100644 (file)
@@ -1,3 +1,15 @@
+ikiwiki (3.20150330) UNRELEASED; urgency=medium
+
+  The new "emailauth" plugin allows users to authenticate using an email
+  address, without otherwise creating an account.
+
+  The openid plugin now enables emailauth by default. Please include
+  emailauth in the disable_plugins setting if this is not desired.
+  Conversely, if emailauth is required on a wiki that does not enable
+  openid, you can list it in the enable_plugins setting.
+
+ -- Simon McVittie <smcv@debian.org>  Wed, 27 May 2015 08:30:43 +0100
+
 ikiwiki (3.20150107) experimental; urgency=medium
 
   By default, this version of IkiWiki tells mobile browsers that its
index e483285fa69ace8b561c8b0a6867db579610c22a..14ef4e71bd07b9570b94c3bfb6ec73160dfad54f 100644 (file)
@@ -1,5 +1,6 @@
 ikiwiki (3.20150330) UNRELEASED; urgency=medium
 
+  [ Joey Hess ]
   * New emailauth plugin lets users log in, without any registration,
     by simply clicking on a link in an email.
   * Re-remove google from openid selector; their openid provider is
@@ -13,6 +14,11 @@ ikiwiki (3.20150330) UNRELEASED; urgency=medium
   * Make cgiurl output deterministic, not hash order. Closes: #785738
     Thanks, Daniel Kahn Gillmor
 
+  [ Simon McVittie ]
+  * Do not enable emailauth by default, to avoid surprises on httpauth-only
+    sites. Enable it by default in openid instead, since it is essentially
+    a replacement for OpenIDs.
+
  -- Joey Hess <id@joeyh.name>  Tue, 28 Apr 2015 12:24:08 -0400
 
 ikiwiki (3.20150329) experimental; urgency=high
index 74097d2cc2cebf61f1b122391005865a291eb9a6..46366653545d84ba9c0a7d0b9cf4dc0c056dfd9e 100644 (file)
@@ -5,8 +5,9 @@ This plugin lets users log into ikiwiki using any email address. To complete
 the login, a one-time-use link is emailed to the user, and they can simply
 open that link in their browser.
 
-It is enabled by default, but can be turned off if you want to only use
-some other form of authentication, such as [[passwordauth]] or [[openid]].
+It is (indirectly) enabled by default, but can be turned off if you want to
+only use some other form of authentication, such as [[passwordauth]] or
+[[openid]].
 
 Users who have logged in using emailauth will have their email address used as
 their username. In places where the username is displayed, like the
index 4683bbad29c0d5b3674ee1abfd2c902f9b6bdb85..ec7b4b96d7803fc500e2369ebf91f11acaf16482 100644 (file)
@@ -127,7 +127,7 @@ Thoughts anyone? --[[Joey]]
 >>>
 >>> Another way to do it would be to hash the email address,
 >>> so the commit appears to come from
->>> `smcv <smcv@dc84925053b18a910f4b95fb7ce1bf802eb7d80e>` instead of
+>>> `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).
index 389f014c9b1bc0e83e66d2cf45126a7dae1eda9f..1eca0dced15a672e6a6b09acd29b29d56c707c60 100644 (file)
@@ -12,6 +12,11 @@ owner (and maybe their outsourced service providers), but not available
 to random third parties. The principle of least astonishment would suggest
 that we should do the same here.
 
+> This part is now addressed by cloaking email addresses:
+> `smcv@debian.org` → `smcv@02f3eecb59311fc89970578832b63d57a071579e`
+> (that's the sha1sum of `mailto:smcv@debian.org`, as used in FOAF).
+> --[[smcv]]
+
 (The expectation of privacy for direct git commits is rather different:
 I think we can expect direct git committers to know that they
 should either set a plausible non-email-address in their git identity,