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


WITH [ QUERY ] LookupAttributesAndCheckForPermission(REQUEST) COMPUTE foo, bar, baz

where LookupAttributesAndCheckForPermission get's everything it needs out of

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... 

>>>>> "Itai" == Itai Tavor <[EMAIL PROTECTED]> 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> [EMAIL PROTECTED] - Kermit the Frog

    Itai> "If you haven't got your health, you haven't got anything"

    Itai> _______________________________________________ Zope-Dev
    Itai> maillist - [EMAIL PROTECTED]
    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 )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to