On Fri, Oct 22, 2010 at 12:21:17AM +0400, Dmitriy Igrishin wrote: > Hey Tony, > > 2010/10/21 Tony Cebzanov <tonyceb@xxxxxxxxxxxxxx> > > > I have a web application with a Postgres backend. In my initial > > prototype, I decided not to have a Postgres database user created for > > each application user, opting instead to use my own users table. > > > IMO, you are trying to reinvent the wheel. Although, you may do it just for > fun. :-) This is an interesting statement and I've wondered about this a couple of times before. It seems very common practice (at least with web applications) to access a database from one user and do all authentication and authorization checking in the application. Is this a bad idea? At first glance, it would indeed seem very logical to make an application user match a database user, but how do you do row-level permission checking? For instance, very often I've had the situation where a web app stores users, companies and <whatever>s. The whatevers can be accessed only to either the user who created them, or when they are either company-wide assets or the user has company-wide privileges, can be accessed only when the whatever was made by a user from the same company. As far as I can see, this would imply either creating views on the <whatever> for every user (or company?), or manually crafting queries to do the same. The latter is of course what most webapps do, and it is a frequent cause of errors and, hence, vulnerabilities. I'd love to hear some good advice on what has worked well for others. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
