[PEAK] peak.security: permissionFor problem

[Phillip J. Eby]

At 11:48 AM 2/11/05 +0100, Radek Kanovsky wrote:
>Hi Phillip,
>
>before I dive into the problem I currently have, I would want discuss few
>things. Problem is that function peak.web.environ.traverseAttr() raises
>unexpectedly (as for me) AmbiguousMethod exception on line:
>
>     perm = ctx.policy.permissionFor(ob,name)
>
>What confuses me is the exception argument that states "there are group
>of three ambiguous methods" for arguments (web.Context(), 'user').
>But these methods have the same signature, i.e. group contains three
>Signatures instances with the same instance id (proven).

You mean all three signature objects are the same object?


>  I was not able
>to assemble simple erroring demonstration yet. Problem is hard for
>debugging because exception raises irreguraly, typicaly when I am trying
>to show user instance via template:
>
>     <div content:replace="/user"/>
>
>I haven't found any rules that would lead to exception. 'user' attribute
>of Context instance is shown in some templates, i.e. permissionFor()
>passes without exception.
>
>So I am asking: Is the exception argument meaningful?

Yes, it's the objects it found ambiguous.



>For example:
>
>   [
>    (Signature(
>     (2, <function dispatch_by_inequalities at 
> 0xb7bdbf7c>)=Inequality(=='user'),
>     (1, <function dispatch_by_mro at 0xb7bdb95c>)=Context,  # web.Context
>     (0, <function dispatch_by_mro at 0xb7bdb95c>)=Context), # 
> security.Context
>     <function declared_permission at 0xb7a0902c>
>     ),
>    (Signature(...same signature...),
>    (Signature(...same signature...),
>   ]

I notice you're not showing the function here for the other two 
signatures.  I'm guessing they are all <function declared_permission>, but 
do they have the same addresses, or different ones?


>Workaround is in replacing the first line of traverseAttr() with:
>
>     perm = security.Context().permissionFor(ob,name)
>
>My interaction policy is subclass of original web.InteractionPolicy and
>my own permission checker:
>
>     class InteractionPolicy (UtilRules, InteractionPolicy) :
>         .....
>
>where UtilRules defines only two permission checkers:

Permission checkers aren't relevant here; it's permissions *declared* with 
binding.metadata() or by putting them on an attribute binding.  That is, 
'permissionFor()' is looking up those permissions, not your permission 
checkers.

The signatures you've shown above are of the form "self in security.Context 
and subject in web.Context and name=='user'", so it is looking up what 
permission should be used for the 'user' attribute of a 'web.Context' 
object.  It sounds as though there has been more than one declaration of 
this, though how that would happen I don't know.

If I were going to try to debug this, I would hack the 
'_declare_permission' function in peak.security.rules to drop into the 
debugger whenever attrname=='user', so I could see how many times it was 
getting called and from where, and with what 'metadata' value.

I suspect that the problem is that for some reason the metadata is being 
declared more than once, leading to a spurious apparent ambiguity.  I may 
have to switch from a generic function to a dispatcher so that multiple 
declarations of the same metadata can be ignored.

Anyway, it sounds like a problem with either peak.security or peak.binding, 
more likely that peak.binding is somehow declaring some metadata more than 
once.