> -----Original Message----- > From: Mike Soultanian [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 08, 2005 1:36 PM > To: CF-Talk > Subject: Re: Question about my security system > > Blank initialized system - Permission database is currently empty (no > permissions registered). > > Some random user logs in and hits two templates (user.cfm and > message.cfm) which have the following: > > USER.CFM > <cf_security perms="read,edit,delete"> > > MESSAGE.CFM > <cf_security perms="read,edit,delete,post"> > > Since neither of these files have been registered with the security > system yet, cf_security registers the filenames and permissions in the > database (assuming filenames are the unique identifier for simplicity) > and tells the user to wait until permissions have been set. The > permission table would look like this:
I guess my only concern here is that it looks like you can't secure a file until you run the file... which seems odd to me. It's like saying I can't lock a room until I go inside it. Automatic population of the permissions database via the file means (I think?) that something like this would happen: 1) Write a new file. Add permissions to it (the cf_security tag). 2) Hit that file (before anybody else) so that the permissions are added to the database. 3) Go to the database and assign groups/users to those permissions (and until you do that the file is either locked completely or open completely since the permissions exist but they've not been configured). 4) Now the file will have the permissions you wanted intact. You still need to know the permissions to apply groups and you still need to touch everything to get everything setup. It seems like there's a grey area between the time the file is moved the to server and the permissions are actually ready to use. By removing the automated permissions I don't think you're adding work or complexity - just eliminating that grey area. The path might me like this: 1) Add your new permissions to the database. 2) Assign groups to those permissions. 3) Write a new file which checks/uses those permissions. 4) Now the file will have the permissions you wanted intact (and will have them from the moment of it's being move to the server). You can still do everything else you have but you wouldn't need to instantiate the permissions from the file leaving a hole between permission design, creation and application. In this case you might also cheat a little - your permissions don't have to be template specific but they could be (I like that kind of freedom). If you define "messageread" you can only use it in the "message" template... but you could also use it elsewhere. You could still do "<cfsecurity perimissionset="message"> at the top of the page to indicate that this page is only concerned with that permission set. > The nice thing about this is within the code, you just use standard > words like: > > if edit > do this > end if > > Instead of: > > if messageedit > do that > end if > > which makes the code nice and portable if you decide to reuse it > somewhere else (not specific to that file). I worry a little about the abstraction of "edit" and the like. It seems like you might have to create odd ones when pages need more than one link. For example consider a page that presents a menu of tools. You might want your system to grey-out or not display tools which the user doesn't have permission for. So, on this one page, you might have both "editMessage" and "editUser" permissions (the entitlements would be checked to see if the option should be shown) if the person is an admin. I also worry about "edit" being portable in that sense. If "edit" one page means "editUser" and "edit" on another means "editMessage" then the words are portable... but the meaning isn't. In other words moving the code from one file to another might make code that requires admin rights in one file allowable to a moderator in another. > The only thing I don't like about this setup is that I'm loading up all > those permissions into memory - seems kinda wasteful. Let's say I had > 100 files with each of them having a few permissions, that list could be > huge, multiply that by lots of users, that could be a lot of memory. I > could instead load the PERMID list into memory, but then I'd obviously > have to do a lookup to pull the actual permission out of the database > every time someone hits a template so cf_security could make the match. Well... the page permissions I wouldn't worry about (and I still say, annoyingly and often, that per-page permissions replaced with uniquely defined permissions would eliminate 90% of that). But loading them all up isn't going to hurt anything - a few meg of memory data at most - you's leak more than that way in an hour with most DB drivers anyway. ;^) The user permissions should, I think, only be loaded when that user is online - and deleted from the cache when it looks like they're gone. This would only use space for those that need it. > The other option is loading up the group memberships into the session > variable at login and then doing a group/permission lookup for every > template, but that would have a similar performance hit (if not slightly > higher) than the PERMID list, but the session variable stays small. I'd still just load a security profile for each logged in user. In my system this is contained in the "entitlements" object which is maintained in a shared memory cache (either application or server) cache. The EntitlementsMediator object is the actual cache - you might want to take a look at it to get some ideas for this. > Now, I understand that I'm repeating permissions, i.e. there is a > permission EDIT in USER.CFM and also another permission EDIT in > MESSAGE.CFM, but those permissions are still template specific. I can't > give some group generic EDIT permissions because EDIT on one template > doesn't mean the same thing on another template. Yup... but it still seems to me that they're task specific, not template specific. Might you not have two templates that do the same task which would now need two permissions managed for it? Using that menu I mentioned above you'd have a page which presents a menu of options that needs to know if the user can delete a user (so it can display that option or not) but you also have the page which does the delete which needs to know the same thing. The two permissions are linked, conceptually (both should always be the same - the menu should only display the option for those can do the task on the action page). But it doesn't look like you could link them together or use the same permission for both. Maybe it's just because I always do this (check permissions to create navigation and such away from the page with the task I've permissioned) that it seems like such a big deal to me. > So whatcha think? So far I could live with it... I can't say that it wouldn't annoy me areas, but I could live with it. ;^) Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217722 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=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
