From e2c9b425415a00012b2c579c40c369da4ac7c98b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 17:46:28 -0500 Subject: thoughts --- doc/todo/Separate_OpenIDs_and_usernames.mdwn | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'doc/todo/Separate_OpenIDs_and_usernames.mdwn') diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index 2cd52e8c4..ae427d540 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -6,6 +6,25 @@ I see this being implemented in one of two possible ways. The easiest seems like A slightly more complex next step would be to request sreg from the provider and, if provided, automatically set the identity's username and email address from the provided persona. If username login to accounts with blank passwords is disabled, then you have the best of both worlds. Passwordless signin, human-friendly attribution, automatic setting of preferences. +> Given that openids are a global user identifier, that can look as pretty +> as the user cares to make it look via delegation, I am not a fan of +> having a site-local identifier that layered on top of that. Perhaps +> partly because every site that I have seen that does that has openid +> implemented as a badly-done wart on the side of their regular login +> system. +> +> Openid Simple Registration is now used to populate the userdb with the +> email address for openid users. +> +> I am considering displaying the userid or fullname, if available, +> instead of the munged openid url in recentchanges. It would be nice +> for those nasty [[google_openids|forum/google_openid_broken?]]. But, +> I first have to find a way to encode the name in the VCS commit log, +> while still keeping the openid of the committer in there too. +> Perhaps something like this (for git): --[[Joey]] +> +> Author: Joey Hess + Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat. [[!tag wishlist]] -- cgit v1.2.3 From 8f4f81cdfdcb68be5efb385dc07e4a0a04352a9d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 19:24:51 -0500 Subject: wrinkles --- doc/todo/Separate_OpenIDs_and_usernames.mdwn | 9 ++++++--- doc/todo/avatar.mdwn | 14 ++++++++++---- 2 files changed, 16 insertions(+), 7 deletions(-) (limited to 'doc/todo/Separate_OpenIDs_and_usernames.mdwn') diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index ae427d540..3fb952f96 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -13,8 +13,9 @@ A slightly more complex next step would be to request sreg from the provider and > implemented as a badly-done wart on the side of their regular login > system. > -> Openid Simple Registration is now used to populate the userdb with the -> email address for openid users. +> The openid plugin now attempts to get an email and a username, and stores +> them in the session database for later use (ie, when the user edits a +> page). > > I am considering displaying the userid or fullname, if available, > instead of the munged openid url in recentchanges. It would be nice @@ -23,7 +24,9 @@ A slightly more complex next step would be to request sreg from the provider and > while still keeping the openid of the committer in there too. > Perhaps something like this (for git): --[[Joey]] > -> Author: Joey Hess +> Author: Joey Hess <http://joey.kitenet.net/@web> +> +> Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat. diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn index 4409e7b14..3a4e64b95 100644 --- a/doc/todo/avatar.mdwn +++ b/doc/todo/avatar.mdwn @@ -15,14 +15,20 @@ included in eg, a comment post via a template. Possibly included in a recentchanges page item via that template too? The avatars are provided by various sites. For email addresses, it uses a -[gravatar](http://gravatar.com/). For openid, -[openavatar](http://www.openvatar.com/) could used, but I am not very happy -with it; probably better to just get the email via SREG (as is done now for -openid), and use that. For a wiki username, the +[gravatar](http://gravatar.com/). For a wiki username, the user's email address is looked up and the gravatar for that user is displayed. (Of course, the user has to have filled in their email address on their Preferences page for that to work.) +For openid, openavatar sucked and is now dead. So we need to use an email +address instead, I guess. Problem is that the email address of a given +openid is only known when that user is logged in and making a change. +And we don't want to leak an openid user's email into a page either. +Hmm. Suppose the gravatar hash could be calculated from the email address +and embedded instead of the openid? + +Or, for openid, could use . + An optional second parameter can be included, containing additional options to pass in the [gravatar url](http://en.gravatar.com/site/implement/url). -- cgit v1.2.3 From 702c097ac29f1b208158936a99317ebad3e4116f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 19:40:20 -0500 Subject: update --- doc/todo/Separate_OpenIDs_and_usernames.mdwn | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) (limited to 'doc/todo/Separate_OpenIDs_and_usernames.mdwn') diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index 3fb952f96..7cfe49a5a 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -18,15 +18,25 @@ A slightly more complex next step would be to request sreg from the provider and > page). > > I am considering displaying the userid or fullname, if available, -> instead of the munged openid url in recentchanges. It would be nice -> for those nasty [[google_openids|forum/google_openid_broken?]]. But, -> I first have to find a way to encode the name in the VCS commit log, +> instead of the munged openid url in recentchanges and comments. +> It would be nice for those nasty [[google_openids|forum/google_openid_broken?]]. +> But, I first have to find a way to encode the name in the VCS commit log, > while still keeping the openid of the committer in there too. > Perhaps something like this (for git): --[[Joey]] > > Author: Joey Hess <http://joey.kitenet.net/@web> > +> So, what needs to be done: > +> * Change `rcs_commit` and `rcs_commit_staged` to take a session object, +> instead of just a userid. (For back-compat, if the parameter is +> not an object, it's a userid.) Bump ikiwiki plugin interface version. +> * Modify all RCS plugins to include the session username somewhere +> in the commit, and parse it back out in `rcs_recentchanges`. +> * Modify recentchanges plugin to display the username instead of the +> `openiduser`. +> * Modify comment plugin to put the session username in the comment +> template instead of the `openiduser`. Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat. -- cgit v1.2.3 From fd43e83fcf7bf24493ecfff54111c1c5f1cab573 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 19:56:54 -0500 Subject: update --- doc/forum/google_openid_broken__63__.mdwn | 13 +++++++++++++ doc/todo/Separate_OpenIDs_and_usernames.mdwn | 7 +++++++ 2 files changed, 20 insertions(+) (limited to 'doc/todo/Separate_OpenIDs_and_usernames.mdwn') diff --git a/doc/forum/google_openid_broken__63__.mdwn b/doc/forum/google_openid_broken__63__.mdwn index 0e41d4ced..4ca5cac93 100644 --- a/doc/forum/google_openid_broken__63__.mdwn +++ b/doc/forum/google_openid_broken__63__.mdwn @@ -58,3 +58,16 @@ points to a fairly useless xml document, rather than a web page. --[[Joey]] > I've added buttons that submit the two above URLs for logging in with a Google and Yahoo OpenID, respectively, to my locally changed OpenID login plugin. > Using the Google profile page as the OpenID is really orthogonal to the above. --[[kaol]] + +>> Displaying email addresses is not really an option, because ikiwiki +>> can't leak user email addresses like that. Displaying nicknames or +>> usernames is, see [[todo/Separate_OpenIDs_and_usernames]]. +>> +>> It would probably be good if the openid plugin could be configured with +>> a list of generic openid urls, so it can add quick login buttons using +>> those urls. +>> +>> The ugly google url will still be exposed here and there where +>> a unique user id is needed. That can be avoided by not using the generic +>> , but instead your own profile +>> like . --[[Joey]] diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index 7cfe49a5a..fcdb49f6d 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -26,6 +26,13 @@ A slightly more complex next step would be to request sreg from the provider and > > Author: Joey Hess <http://joey.kitenet.net/@web> > +> Only problem with the above is that the openid will still be displayed +> by CIA. Other option is this, which solves that, but at the expense of +> having to munge the username to fit inside the email address, +> and generally seems backwards: --[[Joey]] +> +> Author: http://joey.kitenet.net/ <Joey_Hess@web> +> > So, what needs to be done: > > * Change `rcs_commit` and `rcs_commit_staged` to take a session object, -- cgit v1.2.3 From a4f381ace837a032bc202cc6b2a98e922d4b7cfc Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 23 Jun 2010 19:44:41 -0400 Subject: git: Record the username from openid in the git author email. (This avoids display of ugly google openids.) --- IkiWiki/Plugin/git.pm | 5 +++++ debian/changelog | 2 ++ doc/rcs.mdwn | 20 +++++++++++++------- doc/todo/Separate_OpenIDs_and_usernames.mdwn | 3 +++ 4 files changed, 23 insertions(+), 7 deletions(-) (limited to 'doc/todo/Separate_OpenIDs_and_usernames.mdwn') diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm index 85368606e..3e289e0c3 100644 --- a/IkiWiki/Plugin/git.pm +++ b/IkiWiki/Plugin/git.pm @@ -506,6 +506,11 @@ sub rcs_commit_staged (@) { if (defined $u) { $u=encode_utf8($u); $ENV{GIT_AUTHOR_NAME}=$u; + } + if (defined $params{session}->param("username")) { + $u=encode_utf8($params{session}->param("username")); + } + if (defined $u) { $ENV{GIT_AUTHOR_EMAIL}="$u\@web"; } } diff --git a/debian/changelog b/debian/changelog index 88ed3a90b..dfa862e5b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -5,6 +5,8 @@ ikiwiki (3.20100624) UNRELEASED; urgency=low parameters. * Fixed some confusion and bugginess about whether rcs_getctime/rcs_getmtime were passed absolute or relative filenames. + * git: Record the username from openid in the git author email. + (This avoids display of ugly google openids.) -- Joey Hess Wed, 23 Jun 2010 15:30:04 -0400 diff --git a/doc/rcs.mdwn b/doc/rcs.mdwn index 248d93024..83c6910d0 100644 --- a/doc/rcs.mdwn +++ b/doc/rcs.mdwn @@ -10,13 +10,8 @@ generic that it can be adapted to work with many systems by writing a While all supported revision control systems work well enough for basic use, some advanced or special features are not supported in all of them. -Lack of support in [[ikiwiki-makerepo]] or auto.setup can make it harder to -set up a wiki using that revision control system. The `rcs_commit_staged` -hook is needed to use [[attachments|plugins/attachment]] or -[[plugins/comments]]. `rcs_getctime` may be implemented in a fast way -(ie, one log lookup for all files), or very slowly (one lookup per file). -And so on. The table below summarises this for each revision control -system and links to more information about each. +The table below summarises this for each revision control system and +links to more information about each. [[!table data=""" feature |[[git]]|[[svn]]|[[bzr]] |[[monotone]]|[[mercurial]]|[[darcs]]|[[tla]] |[[cvs]] @@ -30,7 +25,18 @@ auto.setup |yes |yes |incomplete|yes |incomplete |yes `rcs_getmtime` |fast |slow |slow |no |no |no |no |no anonymous push |yes |no |no |no |no |no |no |no conflict handling |yes |yes |yes |buggy |yes |yes |yes |yes +openid username |yes |no |no |no |no |no |no |no """]] +Notes: + +* Lack of support in [[ikiwiki-makerepo]] or auto.setup can make it harder to + set up a wiki using that revision control system. +* The `rcs_commit_staged` hook is needed to use [[attachments|plugins/attachment]] + or [[plugins/comments]]. +* `rcs_getctime` and `rcs_getmtime` may be implemented in a fast way (ie, one log + lookup for all files), or very slowly (one lookup per file). +* Openid username support allows avoiding display of Google's ugly openids. + There is a page with [[details]] about how the different systems work with ikiwiki, for the curious. diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index fcdb49f6d..60b7b6c61 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -38,10 +38,13 @@ A slightly more complex next step would be to request sreg from the provider and > * Change `rcs_commit` and `rcs_commit_staged` to take a session object, > instead of just a userid. (For back-compat, if the parameter is > not an object, it's a userid.) Bump ikiwiki plugin interface version. +> (done) > * Modify all RCS plugins to include the session username somewhere > in the commit, and parse it back out in `rcs_recentchanges`. +> (done for git only so far) > * Modify recentchanges plugin to display the username instead of the > `openiduser`. +> (done) > * Modify comment plugin to put the session username in the comment > template instead of the `openiduser`. -- cgit v1.2.3 From 9a2c56b748ec9cd9230abada56267bde1840ca39 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 23 Jun 2010 20:21:44 -0400 Subject: openid nickname support finished; closing --- doc/todo/Separate_OpenIDs_and_usernames.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/todo/Separate_OpenIDs_and_usernames.mdwn') diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index 60b7b6c61..a4940220a 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -46,8 +46,8 @@ A slightly more complex next step would be to request sreg from the provider and > `openiduser`. > (done) > * Modify comment plugin to put the session username in the comment -> template instead of the `openiduser`. +> template instead of the `openiduser`. (done) Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat. -[[!tag wishlist]] +[[!tag wishlist done]] -- cgit v1.2.3