[Zope-dev] Local roles and security of ZClass instances in Specialists

[Itai Tavor]

Hi Steve,

This is a nice idea... but I can't get it to work. it works fine when 
changing properties:

   WHEN OBJECT CHANGED CALL self.checkForPermission(REQUEST)

But is ignored for accessing properties:

   WITH self.checkForPermission(REQUEST) COMPUTE spam='eggs'

simply fails to set spam if checkForPermission raises an exception, 
because ZPatterns catches all exceptions in COMPUTE clauses (I never 
understood the point of this, BTW. It just gets in the way of 
debugging. Wouldn't catching just AttributeError and KeyError be 
enough?) and the exception gets dumped to the console. Which could 
actually be considered to work, because the method doing the access 
will fail... but that would be ugly and definitely not what I want.

Also, I want a solution that would work regardless of the storage 
method - I don't think this one won't work for ZODB storage. In a 
Rack using persistent storage and having a property 'spam', the 
SkinScript clause:

   WITH self COMPUTE spam='eggs'

will be ignored. So the SkinScript can be used to control access only 
if it's already being used to load the properties.

Which all comes down to having to do the security checks in all the 
methods that access the object :-( Unless you can show me something I 
missed?


Steve Spicklemire wrote:

>Hi Itai,
>
>    I'm sure there's something clever you could do here with
>an attribute provider for you user object that supplied
>__roles__ dynamically somehow, but I'd need to think
>about that more... one easy way to limit who can
>see different stuff is to use a wrapper around
>your access methods (e.g., SQL queries) that checks for
>security:
>
>e.g.,
>
>WITH [ QUERY ] LookupAttributesAndCheckForPermission(REQUEST) 
>COMPUTE foo, bar, baz
>
>where LookupAttributesAndCheckForPermission get's everything it needs out of
>the REQUEST.
>
>It's a crude tool.. but it's simple. When I get some time to think clearly..
>I'll try to come up with something more general. Hopefully you'll also get
>some other suggestions...
>
>-steve
>>>>>>  "Itai" == Itai Tavor <itai@optusnet.com.au> writes:
>
>     Itai> Hi,
>
>     Itai> I'm trying to work out a security strategy for data stored
>     Itai> in Specialists, where specific users need access to specific
>     Itai> data instances.
>
>     Itai> For example: A Customer object is linked to a Person and
>     Itai> Address objects. The customer needs permission to edit the
>     Itai> her - and only her - Address object. Using the Owner local
>     Itai> role won't work, because customers can be registered by site
>     Itai> managers and customer support people, in which case Owner
>     Itai> won't be the customer.
>
>     Itai> I can solve this by giving the customer a local role when
>     Itai> creating her Address object:
>
>     Itai>      Customers.addCustomer(REQUEST): ni =
>     Itai> container.addItem(some_id)
>     Itai> container.Addresses.addAddressFor(ni.id, REQUEST)
>
>     Itai>      Addresses.addAddressFor(for_id, REQUEST): ni =
>     Itai> container.addItem(some_id) ni.manage_addLocalRole(for_id,
>     Itai> 'EditMyDetails')
>
>     Itai> But this can be a lot of work - If an Address object can
>     Itai> also be created for a CreditCard object, addCreditCard will
>     Itai> have to both set its own local role, and pass the customer
>     Itai> id on to Address...
>
>     Itai> But the main problem is that I'm not sure if it will work at
>     Itai> all - can local roles be set for DataSkins that aren't
>     Itai> stored in the ZODB?  From what I can see ZPatterns doesn't
>     Itai> support this, so I'll have to do it
>     Itai> myself. __ac_local_roles__ can't be accessed in a SkinScript
>     Itai> - so will I have to override has_local_roles,
>     Itai> get_local_roles and get_local_roles_for_userid and call them
>     Itai> from the SkinScript? This is getting hairy...
>
>     Itai> Without local roles, all I can think of is explicitly
>     Itai> checking that the logged in user is the right customer in
>     Itai> all the methods that display and edit the object, which is
>     Itai> very ugly. Plus it would require Address to know a
>     Itai> customer_id even when it actually belongs to a CreditCard,
>     Itai> not a Customer... there goes Demeter. Or I can add a
>     Itai> findUserID to Address, CreditCard and Customer, all of which
>     Itai> pass the request upwards until one is reached that actually
>     Itai> knows the customer. Still ugly.
>
>     Itai> TIA for Any comments/suggestions.
>
>     Itai> Itai -- Itai Tavor "Je sautille, donc je suis."  C3Works
>     Itai> itai@c3works.com - Kermit the Frog
>
>     Itai> "If you haven't got your health, you haven't got anything"
>
>
>     Itai> _______________________________________________ Zope-Dev
>     Itai> maillist - Zope-Dev@zope.org
>     Itai> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross
>     Itai> posts or HTML encoding!  ** (Related lists -
>     Itai> http://lists.zope.org/mailman/listinfo/zope-announce
>     Itai> http://lists.zope.org/mailman/listinfo/zope )

-- 
--
Itai Tavor                      -- "Je sautille, donc je suis."    --
itai@optusnet.com.au            --               - Kermit the Frog --
-- 'Supposing a tree fell down, Pooh, when we were underneath it?' --
-- 'Supposing it didn't,' said Pooh after careful thought.         --