In response to Kevin Hunter <hunteke@earlham.edu>:
> >>> 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.)
What's hot in my mind is "how do you securely maintain the database connection
information between page loads?"
--
Bill Moran
http://www.potentialtech.com
