diff options
| -rw-r--r-- | IkiWiki/Plugin/passwordauth.pm | 6 | ||||
| -rw-r--r-- | debian/changelog | 1 | ||||
| -rw-r--r-- | doc/todo/separate_authentication_from_authorization.mdwn | 10 |
3 files changed, 17 insertions, 0 deletions
diff --git a/IkiWiki/Plugin/passwordauth.pm b/IkiWiki/Plugin/passwordauth.pm index 7c01bb3ff..3bdd9de2e 100644 --- a/IkiWiki/Plugin/passwordauth.pm +++ b/IkiWiki/Plugin/passwordauth.pm @@ -251,6 +251,12 @@ sub formbuilder_setup (@) { my $name=shift; length $name && $name=~/$config{wiki_file_regexp}/ && + # don't allow registering + # accounts that look like + # openids, or email + # addresses, even if the + # file regexp allows it + $name!~/[\/:\@]/ && ! IkiWiki::userinfo_get($name, "regdate"); }, ); diff --git a/debian/changelog b/debian/changelog index 45801567f..19f6dfbdb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -9,6 +9,7 @@ ikiwiki (3.20150330) UNRELEASED; urgency=medium they don't have an openid. * Converted openid-selector into a more generic loginselector helper plugin. + * passwordauth: Don't allow registering accounts that look like openids. -- Joey Hess <id@joeyh.name> Tue, 28 Apr 2015 12:24:08 -0400 diff --git a/doc/todo/separate_authentication_from_authorization.mdwn b/doc/todo/separate_authentication_from_authorization.mdwn index 4a602babf..de7c5b763 100644 --- a/doc/todo/separate_authentication_from_authorization.mdwn +++ b/doc/todo/separate_authentication_from_authorization.mdwn @@ -94,3 +94,13 @@ Thoughts? > I always find it a little ackward that i have two different accounts on this wiki: one for OpenID, and the other (regular account) for email notifications (because of [[bugs/notifyemail_fails_with_some_openid_providers/]]). It seems to me those accounts should just be merged as one, ie. I was expecting to be able to choose a username when i registered with openid. > > Also, when you talk about "separating authentication from authorization", i immediately thought of [[todo/ACL/]] and [[todo/Zoned_ikiwiki/]], so i thought i could mention those... having stability in the usernames would help in the design of those... --[[anarcat]] + +> I'm not against this, but I don't anticipate having resources to do any +> work on it either. --[[Joey]] + +> I have fixed passwordauth to not let urls be registered. It seems this +> was not quite a security hole; it didn't let registering a name that +> already existed, so if an openid was an admin, as long as the user logged +> in using that openid, someone else couldn't come along and passwordauth +> collide with it. (Might be exploitable if you could guess an openid that +> was going to be added as an admin though.) --[[Joey]] |