In response to Kevin Hunter <hunteke@xxxxxxxxxxx>: > >>> 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
