doc/bugs/anonok_vs._httpauth.mdwn



I've got a wiki where editing requires [[plugins/httpauth]] (with
cgiauthurl working nicely). I now want to let the general public
edit Discussion subpages, so I enabled [[plugins/anonok]] and set
anonok_pagespec to '*/Discussion', but HTTP auth is still being
required for those.
(Actually, what I'll really want to do is probably [[plugins/lockedit]]
and a whitelist of OpenIDs in locked_pages...)
--[[schmonz]]

The only way I can see to support this combination is for httpauth with
cgiauthurl to work more like other actual login types. Which would mean
that on editing a page that needs authentication, ikiwiki would redirect
them to the Signin page, which would then have a link they could follow
to bounce through the cgiauthurl and actually sign in. This would be
significantly different than the regular httpauth process, in which the
user signs in in passing. --[[Joey]]


My primary userbase has grown accustomed to the seamlessness of
httpauth with SPNEGO, so I'd rather not reintroduce a seam into
their web-editing experience in order to let relatively few outsiders
edit relatively few pages. When is the decision made about whether
the current page can be edited by the current user (if any)? What
if there were a way to require particular auth plugins for particular
PageSpecs? --[[schmonz]]


The decision about whether a user can edit a page is made by plugins
such as signinedit and lockedit, that also use canedit hooks to redirect
the user to a signin page if necessary.
A tweak on my earlier suggestion would be to have httpauth notice when the
Signin page is being built and immediatly redirect to the cgiauthurl
before the page can be shown to the user. This would, though, not play
well with other authentication methods like openid, since the user
would never see the Signin form. --[[Joey]]