Do not directly enable emailauth by default, only indirectly via openid

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.
master
Simon McVittie 2015-05-27 08:52:01 +01:00
parent 9ab3d2a6be
commit 2afb0dd663
7 changed files with 29 additions and 4 deletions

View 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",

View 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",

12
debian/NEWS vendored
View 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

6
debian/changelog vendored
View 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

View 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

View 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).

View 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,