From 1c614914cc7b5fe187298dad88bafa0bdf8f106c Mon Sep 17 00:00:00 2001 From: "smcv@" Date: Fri, 10 Jul 2009 18:56:47 +0100 Subject: Close bug (joeyh merged my patch), split out feature request, provide alternative patch --- .../pretty-print_OpenIDs_even_if_not_enabled.mdwn | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn (limited to 'doc/todo') diff --git a/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn new file mode 100644 index 000000000..373c120a6 --- /dev/null +++ b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn @@ -0,0 +1,24 @@ +A feature I originally requested on +[[a_related_bug|bugs/openid_no_longer_pretty-prints_OpenIDs]]: + + Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser + + On various sites I have two IkiWiki instances running from the same + repository: one accessible via http and only accepting openid logins, + and one accessible via authenticated https and only accepting httpauth. + Ideally, the https version should still pretty-print OpenIDs seen in + git history. + +--[[smcv]] + +> I wonder if an option is the best approach. Maybe it would be better to +> simply move `openiduser` into `userlink`, and thus always support openid +> usernames whether the plugin is enabled or not. --[[Joey]] + +>> OK, implemented that as 'smcv/always-openid'; if you don't think that's +>> bloating the IkiWiki core too much, please consider merging. The poll on +>> [[news/openid]] indicates fairly strong support for *only* accepting OpenID +>> logins, so I think recognising OpenIDs can reasonably be considered core +>> functionality! --[[smcv]] + +[[!tag patch]] -- cgit v1.2.3