> -----Original Message----- > From: Mike Soultanian [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 03, 2005 10:23 PM > To: CF-Talk > Subject: Question about my security system > > Like I mentioned in a previous post, I am creating a security system > that assigns each CF page it's own unique ID. Based on that file's id, > it keeps track on who has access to that page. To do this, I was going > to put a custom tag at the top of every page that I wanted to be secure > and then have the file edit itself and place a random "security ID" at > the top of the page. That ID would then be stored in the DB and have a > security setting applied to it through my security system.
It seems like it might be overkill to tag every single page (since then you would have to provide permissions to every single page). Are your needs really so complex that they can't be managed with groups? In other words you define a group (say "editor" or "admin") and then assign sets of pages to that one group. In fact assigning "pages" to groups is actually a bit too rough for my tastes: I would want to assign functionality to groups and check that within the page. It seems to me there are plenty of cases where a single template needs to display things for many different entitlements... a simple example is a navigation component/tag. It's common for the navigation of a page to change based on the permissions of the user. > Now, the problem with me is I'm a forgetful person. So, instead of > putting the tag in every single file (which I might forget to do), how > about putting the tag in the Application file and then telling the tag > to edit the file referenced by the CGI script name variable. I haven't > yet tried it, but I'm hoping that variable would be referring to the > file being called, not the application.cfm file, even though the tag is > being run from the application.cfm file. That way, every single file on > my site is guaranteed to be secure. Sounds like a plan. > My question is whether or not that will pose any weird quirks. Is there > any reason or circumstance where the CGI Script Name variable wouldn't > refer to the file that the end-user was requesting? The CGI script name > variable comes from the web server, correct, and would *always* be > populated with a value of the target file, right? I can't think of > anything that would cause a problem, but that doesn't mean that there > would be a way around it (hence, my reason for asking the list). > Ultimately, I'm trying to figure out which way is more secure (in the > application.cfm file, or each file). I would probably not trust the CGI variables (which are web server dependent) for this. Instead use the built in CF functions: getCurrentTemplatePath() for example. As for which is "more secure" - neither. Where you put your code has nothing to do with the security of the system. The application.cfm solution will DEFINITELY make the code more maintainable... and maintainable code is less buggy than un-maintainable code. I know that I've been plugging this lately but you might might want to check out the Security System in the DP Libraries (long URL): http://www.depressedpress.com/depressedpress/Content/Development/ColdFusion/ DPLibraries/Index.cfm I know that the documentation is weak (only the components themselves are documented, not how to use them) but I think it may be a help to look through the code to see how somebody else has done it. In my case you instantiate the security system by storing one CFC instance. For example: <cfset Application.DPSecurity = CreateObject("Component", "CFC_DepressedPress.Security.DP_Security").init(Application.DP.getPersistenc eInfo("Default")) /> Each page is given a "SecSetting" which is a list of roles which can view the page (or none which indicates anybody can). So, for example, "SecSetting = 'Admin, Member, Editor'" Each user, when they log in, has an "Authentication" component created in the security system to represent their current login. Part of that component is an "Entitlements" component which has information about what they can do (their roles in the simple system but this can be as complex as you like). When a use hits a page a single, simple call is made to the "isEntitled()" method of the security system: <cfif NOT Application.DPSecurity.isEntitled(Session.DP.getProp("SessionKey"), Request.DP.getProp("SecSetting"))> ... Stuff if they're not entitled ... </cfif> Other methods of the security system are "authenticate()" (log in), "unauthenticate()" (log out), "isUserIDLockedOut()" (true if the ID is locked due to bad password attempts) and so forth. Although the system is set up right now with just plain roles as entitlements you can replace the entitlements component with whatever you like... so, in your case you might use a page ID entitlement component. This way you can build just that piece and use the rest of the system off the shelf. I'd be happy to work with you to set things up (I've got to work on documentation anyway and working through things with somebody could really help me with that). 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:217316 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
