Am 23.05.2010, 17:53 Uhr, schrieb Jim Fulton <j...@zope.com>: >> Does it make sense at all or is it still >> better to restrict access on the application level? > > I would do it at the storage level, not in the application nor in ZEO. > > It is probably possible with some sort of wrapper storage. There are > lots of details to be worked out. This is a project I've been looking > forward to working on for some time, but it is still prettty far down > on my list.
Thanks for Hanno's and your answer. They are quite different :-) I've thought a lot more about both approaches. Yet reaching a conclusion is quite hard. I'll present you some of my reasoning below. I'll elaborate a bit more on the current design of my application: In the context of my application "security" does not mean 100% secure against any kind of attacker, it's more a simple method to prevent some people from seeing other people's things. And to prevent accidental changes. The people are all more or less trusted. My system consists of a server (zodb + twisted) and various desktop clients. The zodb part of the server is used for storing the data, the twisted part is used for event sending and various other communications between clients. All the major work on the data happens on the clients, the server is pretty dumb. Until I thought about security I was assuming the desktop clients could directly access the zodb via ZEO. This would have made many things easy. Clients could access the database directly, manipulate the data model and send events accordingly. Other clients receive the events and can update their views by pulling the changed data from the database. With security in mind, the design has to change. Let's consider a simple example of a Folder object with a few sub-folders. The client will send a request to the server "get all children of folder X". The server will check if the user has access to folder X and will then return all the sub-folders to which the client has access to. With the previous model this would've been as easy as doing "print folder.subfolders", ZEO would take care of returning subfolders. Of course ZEO will not filter the subfolders list by security permissions. Taking this example a step further, if the client wants to add a new folder, he will have to perform an action "add folder" which takes the oid of folder X and the name of the new folder (+ other parameters). The server receives the command, checks if the user may add the new folder and finally adds it. If the transaction succeeded the server then sends an event "folder X subfolders changed". The client receives this event and then issues the "get all children of folder X" event again to update its view with the new folder. Another complication: the client side needs a cache. When it receives an answer to "get all children of folder X" the result should be remembered until the client receives an event that the children of folder X have changed. The cache should also be persistent between different runs of the clients, because building the cache from 0 means the client possibly has to download gigabytes of data (over a broadband internet connection, not LAN speed style). It's also a bit unclear to me how to maintain inter-references between objects if the server never returns objects directly. The client's "cache" is more like a local database which should be in sync with the server's db. There can be differences between server and client db, because of the differing security permissions. Synced db between client and server, notifications when objects change, client side cache. Does all of this sound familiar? ZEO provides all of this. Except the security part. To summarize, if I'd go the application level security route (Hanno's way, implementation as I proposed above): - Check permissions on the server in all relevant places (e.g. each time a folder is accessed by someone) - Client cannot access db directly, has to use indirect commands which the server executes on the client's behalf - Layer to serialize and transport objects from server to client and vice-versa - Custom client cache implementation - Unclear how the db as a whole (intra-references) is represented on the client Integrating into ZEO: - Clients could access db directly - Unclear how this can be implemented. ZEO client sees only proxies of real server objects? Proxies/views would restrict the access on the client side (e.g. a folder proxy would provide only a filtered view on all the subfolders). This is a bit similar to OO RPC calls. E.g. http://pyro.sourceforge.net/ and twisted's perspective broker provide something along these lines. I'd be willing to spend time on implementing something like this if we can work out a proposal together of how to do things exactly. -Matthias _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
