[Seaside] [ENH] HandyComponent

Andreas Raab andreas.raab at gmx.de
Mon Mar 29 02:45:27 CEST 2004


> Right, I would tend to lean towards having multiple classes
> (ReservationViewer vs. ReservationEditor) rather than one class that
> filled both roles.  You still have to have conditional logic somewhere
> that chooses which class to use, of course.
>
> The capabilities guys might have some interesting patterns to use here.
>   I haven't read too much of the UI-related capabilities work.

Not really. The "object capability guys" (there are others as well ;-) start
out with the assumption that you get a capability by being handed one from
someone who has that capability. Only then you are able to invoke the
appropriate methods. This clearly says "don't overload roles" since bugs are
the major cause of security leaks so if you have (say) a read-only file
capability the best way to ensure you can't write is to simply have no
methods to write!

Much of what is being done in these areas uses delegation heavily - for
example you may have a read/write object but if you hand out a read-only
capability you wrap it into an object that only has the read methods on it
(with the added advantages that you can remember the reference and revoke
the capability later if you have to).

BTW, if you haven't read too much about UI-related work, you should
definitely step by at erights.org and have a look about the Darpa-Browser
review. The idea was to build a capability-secure environment *without*
having users to go through endless hoops. The results are pretty convincing
and there are a number of other interesting papers in this area.

Cheers,
  - Andreas



More information about the Seaside mailing list