How signinview handles the goto leak

1 files changed, 6 insertions, 9 deletions

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