Not only that, but fine-grained data access allows a user to simply "select * from some_table" and get the data to which they are allowed access. E.g. each sales person can see the data for their region while an administrator or manager can see all of the regions.
You can also build 6 apps that work with the same data and they will all have the same permissions when you log in as jthomerson. Scott On Tue, Dec 21, 2010 at 9:22 PM, Jeremy Thomerson <jer...@wickettraining.com> wrote: > On Tue, Dec 21, 2010 at 6:12 PM, Eelco Hillenius > <eelco.hillen...@gmail.com>wrote: > >> > - using database roles to restrict access to data, and not relying wholly >> on application enforced security >> >> So if you want to determine whether user X can see button Y, you have >> to query the database for particular role membership? > > > Since he says "wholly", I'm assuming he means that the DB stands as the > "last resort" security. Ideally your application rules will apply the > security constraints correctly. But, if someone finds a way to punch a hole > in that security (i.e. change a primary key in the URL, which shouldn't be > there anyway without security around it, but sometimes people do this, which > leaves an app-level security vulnerability), the DB rules should kick in and > disallow what you were trying (hacking) to do. > > -- > Jeremy Thomerson > http://wickettraining.com > *Need a CMS for Wicket? Use Brix! http://brixcms.org* > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
