summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
authorJoey Hess <joey@kitenet.net>2011-02-01 21:08:32 -0400
committerJoey Hess <joey@kitenet.net>2011-02-01 21:08:32 -0400
commit9ed779b746de86b92a1c08f1b2b4196d42149e55 (patch)
treed7e93ffb8574c8c396971bda2db8b4fb28e55249 /doc/todo
parentb752e7fec4d2bdd788a70722455018245900126b (diff)
parent148d18b04276474027a8e0eb537616b55c8103dc (diff)
Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/credentials_page.mdwn12
1 files changed, 11 insertions, 1 deletions
diff --git a/doc/todo/credentials_page.mdwn b/doc/todo/credentials_page.mdwn
index 42a63ad16..6b90af144 100644
--- a/doc/todo/credentials_page.mdwn
+++ b/doc/todo/credentials_page.mdwn
@@ -1,4 +1,4 @@
-pushing [[this|todo/httpauth feature parity with passwordauth]] and [[this|todo/htpasswd mirror of the userdb]] further (although rather in the [[wishlist]] priority): would it make sense for users to have a `$USER/creditentials` page that is by default locked to the user and admins, where the user can state one or more of the below?
+pushing [[this|todo/httpauth feature parity with passwordauth]] and [[this|todo/htpasswd mirror of the userdb]] further (although rather in the [[wishlist]] priority): would it make sense for users to have a `$USER/credentials` page that is by default locked to the user and admins, where the user can state one or more of the below?
* OpenID
* ssh public key (would require an additional mechanism for writing this to a `authorized_keys` file with appropriate environment variables or prefix that makes sure the commit is checked against the right user and that the user names agree)
@@ -21,3 +21,13 @@ such a page could have a form as described in [[todo/structured page data]] and
> public keys in `authorized_keys` etc).
> -- GB
+
+>> having multiple login options leading to the same identity, and (more important to me) giving the user an easy way to review and edit them. i'm thinking a bit of foaf+ssl style "i am $USER and you can recognize me by my client certificate $CERTIFICATE" statements.
+>>
+>> the reason why i want this in a static place instead of cgi level is that it can be used, for example, for automatically creating htpasswd files for read-only (cgi-less) replicas of private wikis. furthermore, it all gets versioned and it can easily be seen where the data really is. the credentials have to be filed appropriately by plugins anyway, but that can happen as a part of the regular rebuild process.
+>>
+>> and yes, you're right about the word misusage; thanks for pointing it out and fixing it.
+>>
+>> --[[chrysn]]
+
+an issue to be considered: for ways of authentication that don't explicitly mention the user name (and that would be everything but password; especially OpenID), there has to be a way to prevent users from hijacking an admin's account. the user wouldn't get more privileges, but the admin could find himself logged in as a user instead of an admin when he logs in using his OpenID, for example. he could fix it by removing the openid from the user's ("his") page, but it has to be taken care of nevertheless. --[[chrysn]]