aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJoey Hess <joey@kodama.kitenet.net>2008-10-20 20:16:30 -0400
committerJoey Hess <joey@kodama.kitenet.net>2008-10-20 20:16:30 -0400
commitdbf8358d6805fd81925dde1fd9ff3f10dc99fb77 (patch)
tree08f4f1c0dddb6c70dc873657d17de7d4fce99a5b /doc
parent94797b66c4d7f807245aa4bf09dd645468079142 (diff)
downloadikiwiki-dbf8358d6805fd81925dde1fd9ff3f10dc99fb77.tar
ikiwiki-dbf8358d6805fd81925dde1fd9ff3f10dc99fb77.tar.gz
bit of a design for how a post-receive hook could work
Diffstat (limited to 'doc')
-rw-r--r--doc/todo/applydiff_plugin.mdwn37
1 files changed, 37 insertions, 0 deletions
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]]