In response to Sandro Dentella <sandro@xxxxxxxx>: > > Hi all, > > I'm starting a project in which I will use PostgreSQL in which I need to > check permissions at different levels (eg.: status of a record, hierarchy > and so on). The application needs to run with a web interface (sigh!). > > At first I thought i'd like to put as much permission logic as possible in > the database, and I was willing to evaluate veil for that. > > The reasons where mainly two: > > 1. to be sure that those permission where observed independently from the > way I was accessing the data. No way to create security 'holes' > > 2. simplicity in the code > > Some days ago I read an e-mail of somebody that strongly opposed to using > a db other than for ACID features. > > I'd like to hear from this list some thoughts on this subjects. My big argument is that database applications have a way of outgrowing their original requirements. If you write your application well, it's very likely that someone will want a desktop app version, and others will want direct access to the tables and so forth and so on. If you put all the security in the database itself, you can do these other tools rather quickly, and not duplicate the security code. In addition, you can simply say, "Hire a .NET programmer to write that, we don't have to worry about him implementing the security properly." If you have clients that have some knowledge of SQL, you can give them direct access to the db with impunity, which is a _fantastic_ thing to be able to do. Even the ones who will want to use MS Access will show you interesting stuff that you could be doing with the data. In other words, you application will become more valuable. This is the origin of the term "scale". Otherwise, _every_ time you mess with the application you risk breaking the security. And every time you need to implement and interface in a different form, you have to recreate that security code. Yuck. -- Bill Moran Collaborative Fusion Inc.
