]> sipb.mit.edu Git - ikiwiki.git/blob - doc/bugs/anonok_vs._httpauth.mdwn
clarify my horrible idea
[ikiwiki.git] / 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]]