RDBM Connections per User
Hello out there. I had following problem: In a software, using zope as appserver, we needed to have every user a single connection to the database (postgres 7.1) to have access- checks on database level. I hacked into the Connection code and found, that the interfaces are really hard to be used for this feature. The thing is, that many "people" are accessing the database connection handle directly whether I am using now a wrapper function "getConnection()" to get the current connection or open one. I am reading the current user out of the REQUEST["AUTHENTICATED_USER"] and am storing the handles in an _v_connections Dictionary, which is explicitly not stored in database, but lets every user have exactly one connection. Any comments on this? -- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
On Tue, Jun 05, 2001 at 11:47:18PM +0200, Christian Theune wrote:
Hello out there.
I had following problem:
In a software, using zope as appserver, we needed to have every user a single connection to the database (postgres 7.1) to have access- checks on database level.
I think that this is not a very good idea. Consider, you are moving from a realm where there is one object (The database adapter) that needs to be tightly controlled to one that has many objects that must be tightly controlled (the database adapters, the database user ids, their passwords and ACL's). What happens when a db is accessed by someone with insufficient authority? A Zope error is raised and (unless you have caught it), a nasty looking traceback is triggered. It is just as much work to catch the tracebacks as it is to prevent them from occurring. So, you are not saving any application development time. Given the propensity of people to reuse passwords, and the general ease of finding user level passwords, you probably have a situation with many weak passwords rather than one strong one. No, in general, I recommend that you prevent people who have insufficient authority from accessing the database in the first place, and that you log CRUD events so that you know who is responsible for database damage. [Yes, this is a classic tradeoff. There is one position stated as "defense in depth". Check the user at the Zope stage, check him again at db access time, etc. There is another that can be summarized as "put all your eggs in one basket - and watch that basket carefully". In general, I support "defense in depth", but my experience with users is that they simply do not help you with security. For the same reason, I will not give any users accounts on my firewall.] Jim Penny
I hacked into the Connection code and found, that the interfaces are really hard to be used for this feature.
The thing is, that many "people" are accessing the database connection handle directly whether I am using now a wrapper function "getConnection()" to get the current connection or open one.
I am reading the current user out of the REQUEST["AUTHENTICATED_USER"] and am storing the handles in an _v_connections Dictionary, which is explicitly not stored in database, but lets every user have exactly one connection.
Any comments on this?
-- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
In a software, using zope as appserver, we needed to have every user a single connection to the database (postgres 7.1) to have access- checks on database level.
You might want to check out DBObjects, since they are automatically implementing all the permission stuff on the Zope side! This way you also have the object safety covered as well, and you implement the security only once. More on DBObjects at: http://demo.iuveno-net.de Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management
participants (3)
-
Christian Theune -
Jim Penny -
Stephan Richter