aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJoey Hess <joeyh@joeyh.name>2015-05-14 10:57:56 -0400
committerJoey Hess <joeyh@joeyh.name>2015-05-14 10:57:56 -0400
commit85a529db3dfb275c86984a5231627b35ddf307e0 (patch)
treed481ee6697771d1ec93703377dfae4ee60c90451 /doc
parent804144402bd6b3b52b3e38aff7cc0812ac1ba0c8 (diff)
downloadikiwiki-85a529db3dfb275c86984a5231627b35ddf307e0.tar
ikiwiki-85a529db3dfb275c86984a5231627b35ddf307e0.tar.gz
passwordauth: Don't allow registering accounts that look like openids.
Also prohibit @ in account names, in case the file regexp was relaxed to allow it.
Diffstat (limited to 'doc')
-rw-r--r--doc/todo/separate_authentication_from_authorization.mdwn10
1 files changed, 10 insertions, 0 deletions
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]]