[TransWarp] Authentication services, specialists, and rules-checking

[Phillip J. Eby]

At 08:32 AM 8/8/03 +0200, Roché Compaan wrote:
>This made me wonder how conditions in general translate to DOMlets. In
>TAL you can specify tal:condition="some condition". Probably as simple
>as having a "condition" DOMLet which replace itself and its contents
>with nothing if the condition returns false:
>
>     <li define="condition:foo">show foo</li>
>     <li define="condition:bar">show bar</li>

You could do that.  In principle, though, I'm finding it hard to think of a 
situation where you're likely to *do* that, as opposed to pushing the 
condition up into a component of some kind.  I expect that if we do have a 
conditional, it'd be more like:

<li pwt:domlet="if:foo">show foo</li>



>Very cool. How will one introspect permissions?

I don't understand what you mean.


>It's easy to say:
>
>     if "Worker" in permissions: ...
>
>but how would you do that with WorkerOrManager?

You've lost me.  What result are you trying to achieve?  Right now, code 
doesn't check permissions in such a way.  You use 'interaction.allows()' 
and never look at permissions directly.  On the other side, when you define 
security rules, you'll know if a user is a worker by whatever application 
data says they're a worker; you won't be doing it by looking at permissions 
there, either.  So, I guess I don't understand your question.


> > * permissionsNeeded should become permissionNeeded, throughout all of
> > PEAK.  Permissions like "ThisOrThat", can be implemented by rules that
> > simply return 'attempt.allows(This) or attempt.allows(That) or
> > security.Denial("You need this or that").

If your question was about how a WorkerOrManager rule would be evaluated, 
the above is an example.


> > * There needs to be some kind of "catch" DOMlet, although I don't know 
> what
> > it should be called.  Maybe "try"?
>
>"try" is good.

Yep.  I'm thinking that maybe you should be able to use 'define' blocks to 
catch specific error names, which would allow you to specify handlers for 
NotFound separately from NotAllowed.  e.g.

<table pwt:domlet="try:somedata" ...
<tr>
<td pwt:define="NotFound">No data available</td>
<td pwt:define="NotAllowed">Sorry, <span 
pwt:domlet="text.notag:denial">reason for denial goes here</span></td>
</tr>
<table>

Thing is, we then need a define for the "normal" case (not shown above), or 
else it becomes much harder to understand.  Really, the above example is 
horribly broken for what it's supposed to do.  I really need to think about 
it some more to design an effective structure.  Honestly, I don't want to 
make it a general try-except facility anyway, as that's once again putting 
coding constructs into the template.


> > There's also something of a question as to what its default handling
> > for errors should be.  I suppose we could have a
> > 'templateErrorProtocol' on the interaction, to which the error
> > instance is adapted, but then I wonder whether an individual DOMlet
> > might want specific configuration for this.  Perhaps we should just
> > make the target protocol a binding on the DOMlet, and let people with
> > custom needs subclass it.  That might be simplest.  Indeed, perhaps we
> > could just make IWebException include a method for being rendered
> > *within* a template, as opposed to *instead of* a template.  That
> > would let you specify both behaviors for an error in one place.
>
>How is it determined which is rendered when an error occurs?

If zope.publisher catches the error (i.e. it's during traversal, or not 
handled by a renderer), then the handleException() method is currently 
called.    But we will have a renderException() method that DOMlets can 
call when they catch and adapt an error, thus distinguishing the two.