My main issue with it

Post #229,984 by drewk 10/18/05 5:18:13 PM Reply	My main issue with it If security is implemented at that level, you have to manage security at that level. Every other piece of code has to handle permission issues bubbling up from the DB. You have no abstraction layer or API at a higher level than the tables themselves. Sure, you get theoritically finer-grained control, but at the expense of making it unmaintainable. IMO. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #229,997 by JayMehaffey 10/18/05 6:32:56 PM Reply	If that is all you have then it is a problem If the only security you are using is the low level DB security, then that is a problem. Security should be tied to the web application at a higher level, controling which parts of the application the user can access. DB level security can be a good saftey net, but it doesn't make a good system by itself. The best systems I have seen work something like this. Each user is mapped to a user class, such as user, manager, or admin. This mapping is done at the application level when the person logs is. This class is used to login to the database, where each class has a set of permissions based on what it needs to access. At the application level this class is used to determine what parts of the application the user can see and access. Overall this seems the best balance between ease, speed and utility that I have seen. Jay
Post #230,009 by static 10/18/05 8:03:15 PM Reply	That's an interesting idea. I've worked on two LAMP applications now where the security system is entirely in the web pages. The DB user has a wide, but not overly powerful level of access (it can view and modify all data but cannot alter the schema). Having a couple of role-oriented users in the DB as you describe could be interesting, though there's the maintainence aspect. Wade. "Insert crowbar. Apply force."
Post #230,010 by drewk 10/18/05 8:39:30 PM Reply	What you describe is what I favor The problem here is that there is per-user security at the DB level, and there is per-user security at the application level, and there is role-based security (via AD groups) at the application level, and there is role-based security (via AD groups) at the server level, and there is user-based security (via AD permissions) at the server level. And which combination of the above is required for a given application depends on who implemented it and when. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #230,016 by ben_tilly 10/18/05 9:22:53 PM Reply	Permission schemes can get complicated, fast The single worst-performing SQL query that I've ever written was one whose job was to propagate permission rules to figure out exactly who could do what, when. It scaled like O(n^5). I broke it into several pieces and it improved to O(n^4). It got slow again and we moved it to a better machine. It was a lot more flexible than the one you describe, was simple to use, and was very fine-grained. But the logic behind the scenes to make it work was a bear. But it did work well for a few thousand users with hundreds of permissions each. The reason that I needed a complex scheme was that I needed to grant access to a lot of people based on the kind of data they were accessing, the kind of company they were associated with, the terms of their subscription (when your term expires, so does your permission), and our decisions about when to change specific parts of our site between being premium and standard. And I had to keep it simple enough for our sales reps to be able to use the system. "Why don't I give you a 30 day free trial..." Cheers, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)

Welcome to IWETHEY!