From 5397cca7350747805cf47df05e63f18ac6746bf2 Mon Sep 17 00:00:00 2001 From: "http://anastigmatix.net/" Date: Sat, 25 Oct 2014 12:55:46 -0400 Subject: How signinview handles the goto leak --- doc/todo/Zoned_ikiwiki.mdwn | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) (limited to 'doc/todo/Zoned_ikiwiki.mdwn') diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn index c2dfb7a24..76b2b69c7 100644 --- a/doc/todo/Zoned_ikiwiki.mdwn +++ b/doc/todo/Zoned_ikiwiki.mdwn @@ -128,15 +128,12 @@ Note that not all of these issues will be problems for all **zoned ikiwiki use c An unauthorized client can use a `do=goto` request to find out whether a page exists (will be forbidden to view it) or not (will be forbidden to create it). -My first idea was to fix this all within [[plugins/contrib/signinview]] by hooking -`cgi` first and checking for `goto` and an unauthorized page. But checking authorization -requires session info, not loaded at `cgi` hook time. Next idea was to somehow skip the rest of -the chain of `cgi` hooks, preventing `goto` from handling the request, and handling -it again in `sessioncgi`. But 'skip the rest of this chain' doesn't seem to be something -a hook can return. - -Hmm, maybe change the `do` parameter to something other than `goto` before the `goto` hook -can see it, _then_ handle it later in `sessioncgi`? +In [[plugins/contrib/signinview]] this is handled by hooking +`cgi` first and checking for `goto` and a non-public page. If the requested page +(existing or not) matches the `public_pages` PageSpec, it is handed off for the `goto` +plugin to handle normally. Otherwise, the `do` parameter is changed to `signingoto` +so the `goto` plugin's `cgi` hook will _not_ handle it, and the `sessioncgi` hook +takes care of it when the user's identity is available. ### Backlinks -- cgit v1.2.3