From dbf8358d6805fd81925dde1fd9ff3f10dc99fb77 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 20 Oct 2008 20:16:30 -0400 Subject: [PATCH] bit of a design for how a post-receive hook could work --- doc/todo/applydiff_plugin.mdwn | 37 ++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/doc/todo/applydiff_plugin.mdwn b/doc/todo/applydiff_plugin.mdwn index fd0783c2b..b8ddcd6ce 100644 --- a/doc/todo/applydiff_plugin.mdwn +++ b/doc/todo/applydiff_plugin.mdwn @@ -56,3 +56,40 @@ Implementation ============== Also see [[joey]]'s idea on [[users/xma/discussion]], to allow (filtered) anonymous push to this wiki's repository. + +> Ideally the filtering should apply the same constraints on what's pushed +> as are applied to web edits. So locked pages can't be changed, etc. +> +> That could be accomplished by making the git pre-receive hook be a +> ikiwiki wrapper. A new `git_receive_wrapper` config setting could cause +> the wrapper to be generated, with `$config{receive}` set to true. +> +> When run that way, ikiwiki would call `rcs_receive`. In the case of git, +> that would look at the received changes as fed into the hook on stdin, +> and use `parse_diff_tree` to get a list of the files changed. Then it +> could determine if the changes were allowed. +> +> To do that, it should perhaps first look at what unix user received the +> commit. That could be mapped directly to an ikiwiki user. This would +> typically be an unprivelidged user, but you might also want to set up +> separate users who have fewer limits on what they can push. OTOH, I'm not +> sure how to get this info in an ikiwiki wrapper.. the real and effective +> gid are already trampled. So maybe leave this out and always treat it as +> an anonymous edit from a non-logged in user? +> +> Then it seems like it would want to call `check_canedit` to test if an +> edit to each changed page is allowed. Might also want to call +> `check_canattach` and `check_canremove` if the attach and remove plugins +> are enabled. All three expect to be passed a CGI and a CGI::Session +> object, which is a bit problimatic here. So dummy the objects up? (To call +> `check_canattach` the changed attachment would need to be extracted to a +> temp file for it to check..) +> +> If a change is disallowed, it would print out what was disallowed, and +> exit nonzero. I think that git then discards the pushed objects (or maybe +> they remain in the database until `git-gc` .. if so, that could be used +> to DOS by uploading junk, so need to check this point). +> +> Also, I've not verified that the objects have been recieved already when +> whe pre-receive hook is called. Although the docs seem to say that is the +> case. --[[Joey]] -- 2.44.0