[PATCH 1 of 1] hgweb: add support for extension provided check_perm hooks

Sune Foldager cryo at cyanite.org
Fri Nov 6 09:05:38 CST 2009


Dirkjan Ochtman wrote:
> On Fri, Nov 6, 2009 at 15:18, Sune Foldager <cryo at cyanite.org> wrote:
>> # HG changeset patch
>> # User Sune Foldager <cryo at cyanite.org>
>> # Date 1257517067 -3600
>> # Node ID 6b54bf8294aff325325e5d16b20b1f21c426ecc5
>> # Parent  732fc0e9d411e0b94e56779d4ac053ceac0349e4
>> hgweb: add support for extension provided check_perm hooks
> 
> Right. This makes sense, but is also at least somewhat pointless.

Well, since we do custom auth, it would not be pointless for us.
Currently we patch into check_perm exactly the same place as the hooks
are called here, so we could replace the patch with an extension :)

> The next step would be to segregate up the hooks used for read, pull
> and push. I think we can easily find the type for a given request
> (POST is push, cmd in protocol.__all__ is pull, else read). My
> interest is here that I'd like to accomodate something like svn's
> authz files (maybe through an extension, or something; in general, it
> should be easy for extensions to hook into this).

Yes, but note that check_perm already gets passed the operation type in
the op parameter, which is decided on depending on the operation. 'read'
for static stuff, 'pull' for changegroups and similar, and 'push' for
unbundling on the remote.

Is there a reason to separate the hooks? I suppose it would look nicer
and it could be easily done, for sure, but either all hooks 'below' in
level should be called as well, then, since there are common stuff for
all three types, or it's up to the hooks to deal with any common stuff.

> Would you be interested in that as well?

Yes, definately, as long as I am sure I understand you correctly so
we're not working in different directions here :)

I should be on IRC tonight, also.

/Sune



More information about the Mercurial-devel mailing list