First, security is defined directly in terms of tables, it is not
arbitrated by code. The "public" group has SELECT access to the
articles table and the schedules tables, that's it. If a person
figures out how our links work and tries to access the "claims" table
it will simply come up blank (and we get an email).
If a user has not logged in, that is, if they are an anonymous visitor,
the web framework will connect to the database as the default "public"
user. Our system is deny-by-default, so this user cannot actually read
from any table unless specifically granted permission. In the case
being discussed, the public user is given SELECT permission on some
columns of the insurance carriers table, and on the schedules table.
Huh. Does that imply that the web framework still holds a number of
different DB credentials? Or does each user need to supply their
specific DB credentials as their authentication so the web framework is
merely a proxy to the DB?
(Having recently discovered a major security oversight in one of my
employer's webapps, my mind's hot on this kind of thing.)
Kevin
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
