git.oblomov.eu Git - ikiwiki/blob - doc/bugs/anonok_vs._httpauth.mdwn

   1 I've got a wiki where editing requires [[plugins/httpauth]] (with
   2 `cgiauthurl` working nicely). I now want to let the general public
   3 edit Discussion subpages, so I enabled [[plugins/anonok]] and set
   4 `anonok_pagespec` to `'*/Discussion'`, but HTTP auth is still being
   5 required for those.
   6
   7 (Actually, what I'll really want to do is probably [[plugins/lockedit]]
   8 and a whitelist of OpenIDs in `locked_pages`...)
   9
  10 --[[schmonz]]
  11
  12 > The only way I can see to support this combination is for httpauth with
  13 > cgiauthurl to work more like other actual login types. Which would mean
  14 > that on editing a page that needs authentication, ikiwiki would redirect
  15 > them to the Signin page, which would then have a link they could follow
  16 > to bounce through the cgiauthurl and actually sign in. This would be
  17 > significantly different than the regular httpauth process, in which the
  18 > user signs in in passing. --[[Joey]]
  19
  20 >> My primary userbase has grown accustomed to the seamlessness of
  21 >> httpauth with SPNEGO, so I'd rather not reintroduce a seam into
  22 >> their web-editing experience in order to let relatively few outsiders
  23 >> edit relatively few pages. When is the decision made about whether
  24 >> the current page can be edited by the current user (if any)? What
  25 >> if there were a way to require particular auth plugins for particular
  26 >> PageSpecs? --[[schmonz]]
  27
  28 >>> The decision about whether a user can edit a page is made by plugins
  29 >>> such as signinedit and lockedit, that also use canedit hooks to redirect
  30 >>> the user to a signin page if necessary.
  31 >>>
  32 >>> A tweak on my earlier suggestion would be to have httpauth notice when the
  33 >>> Signin page is being built and immediatly redirect to the cgiauthurl
  34 >>> before the page can be shown to the user. This would, though, not play
  35 >>> well with other authentication methods like openid, since the user
  36 >>> would never see the Signin form. --[[Joey]]
  37
  38 >>>> Would I be able to do what I want with a local plugin that
  39 >>>> abuses canedit (and auth) to reach in and call the appropriate
  40 >>>> plugin's auth method -- e.g., if the page matches */Discussion,
  41 >>>> call `openid:auth()`, else `httpauth:auth()`? --[[schmonz]]
  42
  43 >>>>> That seems it would be
  44 >>>>> annoying for httpauth users (who were not currently authed),
  45 >>>>> as they would then see the openid signin form when going to edit a
  46 >>>>> Discussion page.
  47 >>>>> --[[Joey]]
  48
  49 >>>>>> I finally see the problem, I think. When you initially
  50 >>>>>> suggested "a link they could follow to bounce through the
  51 >>>>>> cgiauthurl", presumably this could _be_ the Edit link for
  52 >>>>>> non-Discussion pages, so that the typical case of an httpauth
  53 >>>>>> user editing an editable-only-by-httpauth page doesn't visibly
  54 >>>>>> change. And then the Edit link for Discussion subpages could do
  55 >>>>>> as you suggest, adding one click for the httpauth user, who won't
  56 >>>>>> often need to edit those subpages. --[[schmonz]]
  57
  58 >> On reflection, I've stopped being bothered by the
  59 >> redirect-to-signin-page approach. (It only needs to happen once per
  60 >> browser session, anyway.) Can we try that? --[[schmonz]]
  61
  62 Here is an attempt. With this httpauth will only redirect to the
  63 `cgiauth_url` when a page is edited, and it will defer to other plugins
  64 like anonok first. I have not tested this. --[[Joey]]
  65
  66 <pre>
  67 diff --git a/IkiWiki/Plugin/httpauth.pm b/IkiWiki/Plugin/httpauth.pm
  68 index 127c321..a18f8ca 100644
  69 --- a/IkiWiki/Plugin/httpauth.pm
  70 +++ b/IkiWiki/Plugin/httpauth.pm
  71 @@ -9,6 +9,8 @@ use IkiWiki 3.00;
  72  sub import {
  73         hook(type => "getsetup", id => "httpauth", call => \&getsetup);
  74         hook(type => "auth", id => "httpauth", call => \&auth);
  75 +       hook(type => "canedit", id => "httpauth", call => \&canedit,
  76 +               last => 1);
  77  }
  78
  79  sub getsetup () {
  80 @@ -33,9 +35,21 @@ sub auth ($$) {
  81         if (defined $cgi->remote_user()) {
  82                 $session->param("name", $cgi->remote_user());
  83         }
  84 -       elsif (defined $config{cgiauthurl}) {
  85 -               IkiWiki::redirect($cgi, $config{cgiauthurl}.'?'.$cgi->query_string());
  86 -               exit;
  87 +}
  88 +
  89 +sub canedit ($$$) {
  90 +       my $page=shift;
  91 +       my $cgi=shift;
  92 +       my $session=shift;
  93 +
  94 +       if (! defined $cgi->remote_user() && defined $config{cgiauthurl}) {
  95 +               return sub {
  96 +                       IkiWiki::redirect($cgi, $config{cgiauthurl}.'?'.$cgi->query_string());
  97 +                       exit;
  98 +               };
  99 +       }
 100 +       else {
 101 +               return undef;
 102         }
 103  }
 104
 105 </pre>
 106
 107 > With `anonok` enabled, this works for anonymous editing of an
 108 > existing Discussion page. auth is still needed to create one. --[[schmonz]]
 109
 110 >> Refreshed above patch to fix that. --[[Joey]]
 111
 112 >> Remaining issue: This patch will work with anonok, but not openid or
 113 >> passwordauth, both of which want to display a login page at the same
 114 >> time that httpauth is redirecting to the cgiauthurl. As mentioned above,
 115 >> the only way to deal with that would be to add a link to the signin page
 116 >> that does the httpauth signin. --[[Joey]]
 117
 118 >>> That's dealt with in final version. [[done]] --[[Joey]]