> I see the point.... but I'm not sure if I agree with the implementation. > > What you talking about here is metadata: information about the file. By > putting all of this in the data base you're adding a level of complexity > that I just wouldn't be comfortable with.
Well, it adds flexibility at the price of complexity. It's not *that* hard to implement it. My first implementation was actually quite easy to code. And yes, while it is a database lookup, it's a very small lookup at that so I don't think it should take that much time. I'll have to research how bad the performance degredation will really be... > The cf_Security tag has to be used (it doesn't have to be used in every > file, by the way, just a common include that's run for every request). So > you already have a requirement to put something in every file (or in some > common place) but let's say it's included on every page. Well, yes, it does need to be included on any template that needs to be secured (every template in my case). At the time of coding a template, I will identify what actions are to be performed in that template. I will then update the cf_security tag to read like this: <cf_security permissions=read,write,delete> What happens is when the cf_security tag runs, it will update the database with those permissions (if it hasn't already been done) and then I can go into the GUI and find that file and assign groups to each of those permissions. Then, when a user requests the template, cf_security runs and spits out a structure or some variables set to TRUE for whatever permissions that the user's group has access to. This is how I am abstracting any group/user references from the template. The cf_security tag does the lookup and spits out variables that the calling template can use for its processing. > But you're also inheriting a need to make every file uniquely named (or else > moving files would be a nightmare) and this doesn't mesh with most web sites > (which use the same root for every directory). Ahh, yes, I've thought this out. Obviously it's a problem if every file on my site is called index.cfm ;) So, instead, the cf_security tag will include a unique file security identifier that is automatically placed in every file that the cf_security tag is place: <cf_security permissinos="read,write,delete" FileSID="jasjdj32j42kj3"> The way that the SID is inserted is also handled by the cf_security tag. If the tag notices that it wasn't called with a FileSID, it will generate a unique ID, register that ID in the database, then rewrite the calling template with that ID. This will obviously only be performed once. As of now, I know of no other way to uniquely identify other than giving it a unique identifier. > You're also using a database which has no real connection to the file to > store important information about the file. > > New files must be added the filesystem and then registered in the security > system. All changes will require a trip to this UI (and when you're talking > about doing this on the file level I'm not sure if that's any easier than > just changing something in the file). Again, this is handled by cf_security automatically. I just didn't include that in my previous post because it was somewhat unrelated to the overall concept.. and to keep the discussion simple. > The parallel of the Windows permission system (well... at least NTFS) is a > good one: the file permissions are maintained in the file or directory. > Move a file and it still has the same permissions. Yeah, that was exactly what I was going for. The problem is that there is no GUI for editing a file and dropping in the correct name. For example, you edit a file in NTFS and add a group or user to that file. It looks that up the group's name in a database and then stores that SID in the file or wherever it stores it. If I were to completely parallel that concept, I'd open up dreamweaver and I'd (me, mike) be the database lookup mechanism as I open up my app and look what groups I've created. So, I kinda have to shift the storage of file-level permissions into the database so that association can happen automatically. > There is no centralized database of file-level permissions. > > In a, let's say "average" system, you might put your security groups in the > file: > > isEntitled(User, "admin,member") > > Which returns true if the user is an admin or a member. > > This isn't a bad thing in and of itself, I think. The security information > is where I think it should be: in the file. You know, no, it's not that bad. Where it gets annoying is if you rename a group. Now you've got a big uh oh. Suppose Admin is now called Support Staff and I've added a new group called System Administrators. Now I'd have to edit every file that makes a reference to each of those groups and could possibly compromise my security by a stupid editing mistake. While I think I could try really hard to plan out my application pretty well in the beginning to avoid any group name changes, I am making the assumption that I will ultimately want to change things around. Heck, I've made *tons* of group name changes like the one in the above paragraph on my Windows Domain when we had to migrate to a new domain. One thing someone told me is be very careful about building limitations into your system. On our campus, they are having big problems with a vendor's application. Apparently the vendor didn't use very good coding practices and now they're having trouble updating their systems. Yes, I'm doing a lot of work up-front, but I think it will pay off when I decide I want to change things around down the road. > (Someday all files and directories will have the ability to store arbitrary > metadata similar to the ID3 tagging system for MP3.... then these kind of > things become easier.) This would be very handy ;) > The think I think you're really troubled about it maintenance, right? The > issue of adding a group and needing to change the files and such? > > Off the top of my head I could see two possibilities that would make me more > comfortable with the idea (and we all want that, right?) ;^) > > One idea is to keep the information in the files, but centralize the > management of it. This is most like the Windows File System model. You know, I'd love to do this, but there are two problems. 1) There is no inherently built in system to uniquely identify a file and 2) storing the group information in the file has to be done manually through a text editor. If as part of my app, I built a file editor that would actually open up the file and assign the permissions and save those permissions into the file, that would be sweet. However, it's just easier to store it in the database instead. You know, I'm curious where NTFS stores all its permissions information. Does it really keep the permissions for a file in the file itself, or does it actually store the information in a database and then just keep track of the file in a central database. You know, I'd guess the latter. > <cf_Security roles="" /> > > Or even this: > > <!--- Inserted by the Security Manager ---> > <cfset SecurityRoles = ""> > <!--- Inserted by the Security Manager ---> > <cf_Security /> > > (I'd prefer the former since it doesn't contaminate the page as much.) > > But "roles" (or whatever you want to call it) could be managed centrally > (using the exact same interface you envisioned for the DB solution - only it > would be writing to the file system instead) OR at the file level if you so > desired. This is not a bad idea, but then I would need to build an app that would handle all the updating. Also, if I decided to rename a group, it would have to be smart enough to know which files have that group reference and update them. I could also use find/replace, but that just gets kludgy again. > The second thought is what to do about directories. I could feel a lot more > comfortable with your described model if I didn't have to manage things > strictly on a per-file basis. Instead I would much rather manage things at > mask level. Yeah, could do that, but for my app I don't have much need for directory level permissions. Granted, I could build it in, though... >>So, in the user template, I need to edit/modify/delete users, and in the >>message template, I need to edit/post/delete messages. I wanted to take >>those permissions and bring control of each of them into the security >>system and allow myself to assign groups to *each* of those permissions >>on a per-template basis to really granularize the system. > > > My issue with this is the idea of attaching the permissions to the files > instead of defining them as broadly applicable. > > I really think you're going to have lots of cases of repeated permissions > and issues with portable code. For example: you let's say you have a > "deleteUser" permission. Yeah, there would be a ton of files that all have edit in them. The User template will have that, the message template, and a whole bunch of others, but so does every file in NTFS. > This permission (duh) is needed to delete a user. Now, in good programming > practice you create an encapsulated, portable CFC/Custom > Tag/Function/Whatever to delete the user. That function, of course, checks > for that permission. aha, no it wouldn't. A properly encapsulated tag doesn't care about permissions. It just does what it's told. It's the parent template that's calling the tag that is the deciding factor whether that tag is run or not. > There are also plenty of cases where the file name of the page doesn't > describe what's going on (Fusebox applications for example) - you're system > would have to include more than just filename to possibly work with such a > system. Again, you have templates which are included in other and THOSE > templates need the permissions, not the calling page. haha.. that's funny that you mention fusebox because that throws a whole wrench into this conversation. I've been doing alot of research on frameworks this weekend and I have decided that I am going to be using fusebox for my application. Obviously, the only file that is ever called is index.cfm. So, insead of assigning permissions to files, I'm going to assign them to fuseactions instead. I am planning on making a plugin (similar to cf_security) that will intercept the fuseaction that is being called and then do a similar process like I was planning on doing with my files. The nice thing about fuseactions is they are all unique! I am actually really excited to start playing with fusebox. I just purchased the fusebox 4.1 book and hopefully it'll come in soon. I looks like it should help out with alot of these nitty gritty details as far as the security system goes. Thanks, Mike ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217600 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
