Kevin Crenshaw wrote:
> I considered that point as well, however, I still believe it
> is better not to have my user accounts handled by the db - because:
>
> 1. Fewer database user accounts means fewer vectors for entry
> into the db.
Ok, but that depends on your environment. In a corporate environment this
may prove problematic. Only one user that has all priviledges, often causes
someone to trust some user with the password and then there's trouble. And
you don't even have an audit trail, since all users use the same
username/password combo. I know, that's worst case, but the other side of
the coin. I guess it's horses for courses.
> 2. Controlling access to the data via your app gives you more
> control over what the end user can see and what they can do
> with the data.
Of course, but it's also much more work to write the app. Again depends on
what you need. I come from MS SQL server to PG and the security over there
is quite granular.
> 3. You can still use the Postgres' built in access controls
> to limit what your user can do in the db as an added layer of
> security. - When I say 'your user' I mean the user you set up to give
> your web app access to the database and not the individual
> web app users contained within the database.
Agreed
> 4. Correct me if I'm wrong, but I don't think that Postgres
> allows access control at the column or row level, just at the
> table level. Controlling access via your app will give you
> access control down to whatever level you need.
I just checked up on this, and you're right, it's not possible (yet, I
hope).
> 5. As another poster mentioned, controlling access via your
> app allows you the ability to move to other rdbms' more
> easily if you choose to do so at a later date.
That is a definite advantage.
I'll have to revert back to creating my own security and users
infrastructure, I guess.
Thanks for the comments
Roland
