RE: Question about my security system
> -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 > > > MESSAGE.CFM > > > 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 " 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
Re: Question about my security system
Ok Jim, I think I found the last area where we're getting mixed up. However, I think I understand where you're coming from (and see some of the advantages that you have suggested). My proposed idea below is still storing the file information, but I'm using your filename-permission idea. Check this out: 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 MESSAGE.CFM 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: PERMID FILENAMEPERMGROUP 1 MESSAGE READ 2 MESSAGE EDIT 3 MESSAGE DELETE 4 MESSAGE POST 5 USERREAD 6 USEREDIT 7 USERDELETE Now, I log into my super-duper permission editor and assign groups to those permissions so the table will now look like this: PERMID FILENAMEPERMGROUP 1 MESSAGE READUSERS 2 MESSAGE EDITMODS 3 MESSAGE DELETE ADMINS 4 MESSAGE POSTUSERS 5 USERREADUSERMODS 6 USEREDITUSERMODS 7 USERDELETE ADMINS Now, here is the user/group membership table: USERS GROUPS joe USERMODS, USERS mikeADMINS, MODS dan USERS Let's say user "Joe" logs in and he's obviously a member of the USERMODS and USERS groups. Upon login, the system performs a lookup to see what permissions are assigned to those groups (IDs 1, 4, 5 and 6). Those permissions are then loaded into memory like this: session.permissions = "messageread, messagepost, userread, useredit" Now, let's say Joe hits the USER.CFM template. The cf_security tag is the following: USERS.CFM so the cf_security tag can do a compare between the permissions loaded in memory (session.permissions) and what permissions are stored in the file and set any permission to TRUE that match up (remember, cf_security assembles the permission by taking the filename and the permission). 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). What I really like about this is that there are no database hits while the user is browsing the site. Keeps things nice and fast. 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. 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. 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. i.e. You have an file in NTFS that has modify permission. You also have an OU in Active Directory that can be assigned the modify permission. However, that doesn't mean that I should have generic modify access to both of those objects just because their permission "titles" are the same. So whatcha think? Mike ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217658 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
RE: Question about my security system
> -Original Message- > From: Mike Soultanian [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 08, 2005 12:05 AM > To: CF-Talk > Subject: Re: Question about my security system > > > 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... I'm not worried at all about performance - performance can be addressed. I don't think anything you've talked about will pose a real challenge in that area - it's all doable. > > 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). > > you already have a requirement to put something in every file (or in > > 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: > > For some reason I had assumed that all addition of permissions would be done through the GUI... this is clearer. For what it's worth my site works in a very similar fashion and for very similar reasons. The main problem is that Application.cfm can't accept parameters from the page - it's prepended to the page and so nothing on the page can affect it. To get around this in the past (I'm talking CF 4.5) we used "baseinclude.cfm" files which, as a standard, included at the top of every page but preceded by any number of settings, values or whatever (one of which is the security profile). > 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. This makes a lot of sense - the page informs the system. I like that model. > 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 would the database actually be storing the page information or just the abstracted permissions? It seems like all of your negatives hinge on storing the page information (page name and location) in the database ALONG with the permissions. But since those permissions are already in the page why does the system need the page? > > 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: > > This makes more sense... but I'm not sure if the complexity is worth it. It seems like just making sure your permissions are uniquely named would solve the problem. Doing: would let you ignore the page - you'd be abstracting the permissions. Once ANY page added them you could reuse them for other pages just by adding the name. > As of now, I know of no other way to uniquely identify other than giving > it a unique identifier. I'd just think long and hard on whether you need to uniquely identify the page. Instead just consider uniquely identifying the entitlement and reusing it over and over. This also goes further to eliminating situations were somebody is prevented from performing an action on one page, but can on another because each page has a separate entitlement for the same action. > 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. Su
Re: Question about my security system
Dave Watts wrote: >>As of now, I know of no other way to uniquely identify other >>than giving it a unique identifier. > > > The file name and path is, by definition, unique within a filesystem. Why > not just use that? CF itself uses this mechanism to track which files have > been compiled, for example. Unfortunately, that's making the assumption that either the filename won't be renamed (which yes, is unlikely) or the file will not move (this could happen easily within the life of the app). It's not that big of a deal for CF because it just recompiles. It would suck if it lost it's permissions because then you'd have to go reassign them again. Mike ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217603 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
RE: Question about my security system
> As of now, I know of no other way to uniquely identify other > than giving it a unique identifier. The file name and path is, by definition, unique within a filesystem. Why not just use that? CF itself uses this mechanism to track which files have been compiled, for example. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| 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:217602 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
Re: Question about my security system
> 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: 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: 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 w
RE: Question about my security system
> -Original Message- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Monday, September 05, 2005 5:35 PM > To: CF-Talk > Subject: RE: Question about my security system > > Here's the functional difference: > > I've provided an application to someone else (not myself), and I've > built in several roles. Now the other person, let's call him Bob, > decides that the 3 roles I've built into the system aren't sufficient. > If I've chosen to reference those role names in page, here are my > instructions for adding a role: This isn't a functional difference... it's a convention. Your system only knows what's put into it. It's doesn't matter if you do it "at the factory" or Bob does it six months later. You've decided not to check roles in templates - you've already said that your system COULD check roles in templates. Your system doesn't stop people from checking roles in templates. It's by convention you don't. Don't get me wrong - it's a GOOD convention. I'm not arguing (as you seem to think I am) for (or against, actually) checking roles in templates. I'm arguing that the difference between a role and permission is by convention and not a systemic requirement. > > Not at all. The question is not how to use them or > > how you might define rules to use them, its how a system > > would treat them differently. Or, more specifically why > > a system would need to treat them differently. > > It's not a matter of treating them differently... It's a matter of > their _being_ different. You can _treat_ them exactly the same, and > the end result will still be different behavior/consequences (see > above). EXACTLY! Now we're getting someplace! You can treat them exactly the same - the system can. The system doesn't require knowledge of your conventions! Well - to be clear, the enititlement checking system doesn't, the administrator system needs all sorts of knowledge of your conventions. > It's true they are labels, but they're labels for different things... > > What you're saying is that I should be able to come to you and say > > a) Here is the accounting department (bunch of people). > > b) Here is a member of the accounting department, currently > distributing a payroll check. > > a=b) The act of distributing (verb) a payroll check is not only > synonymous with, but exactly the same thing as the accounting > department (noun). You're reading too much into what I'm saying. You're arguing conventions and I'm not. ALL I'm saying is that the acts of CHECKING whether somebody is in the accounting department OR whether somebody can distribute checks are equivalent to the security system. That's it - read nothing else into it. The system checks, it says "yes" or "no". That's it. It doesn't need to know that one is a task and one is group (in my opinion). Is this person connected to that thing? That's all it cares about. > Labels for different things... that's why they have different labels. In the interface, sure. In the underlying system as well if you prefer - but it's not _necessary_ there by any means. > > Your explanation makes PERFECT sense when considering the > > UI to maintain these things however - that's where such > > conventions are needed. They simplify the management of > > the system and reduce the complexity of using it. But > > you don't need to restrict your underlying system to > > that model at all. > > Umm... okay... but I don't write software that will do something I > consider to be a patently bad idea. But you do write software so that Bob can set up the system that makes the most sense to him (even when it doesn't make sense to you)... you're life is a paradox! ;^) > > Convesationally: Anoymous is a child of Member, Member > > is a child of Moderator and Moderator is a child of Admin. > > > If an Admin wants to "Read" you would check the context > > (yes, we're on the right page) and then check the parent > > - it's "anonymous". But since anonymous is a descendent > > of "admin" admin can read. > > It doesn't bother you that this is a complete non-sequitur and makes > absolutely no sense whatsoever? I don't see it as such. > What you've said is > > "Anonymous is a child of admin, therefore an admin can read." > > More or less it's equivalent of: > > "Coliflour and brocoli are both vegetables, therefore carrots are > orange." Not at all. Anonymous is a child of admin
RE: Question about my security system
> -Original Message- > From: Mike Soultanian [mailto:[EMAIL PROTECTED] > Sent: Monday, September 05, 2005 5:15 PM > To: CF-Talk > Subject: Re: Question about my security system > > Users are then assigned into each of those groups utilizing a > many-to-many relationship. I can then assign groups to resources > instead of assigning individual users to resources. This is standard > windows administration practice because it makes for easier user admin. > Now whether this is the best strategy for web app security, that's > another thing, but I'm giving it a try anyways. Gotcha. We're on the same page. > Now, my basic system currently works like this. I have a table that > stores all the files on my site (they are uniquely named) and what > groups are allowed to access each of those files. When a user requests > a file, my cf_security tag (which is inserted at the beginning of every > template) does a lookup to see what groups are allowed to access that > file and then if the user is a member of one of those groups, it allows > the user to access the file. If not, it will halt execution and go to > an "access denied" template. 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. 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. 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). 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). 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. 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. (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.) 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. Instead of you hitting a database and seeing what a file has you hit the file, extract its security information from a standardized block and view it. Changing permissions would just rewrite the file with the new permissions (or any other meta data information you wanted). Most source control systems already have this concept (they have the same problem: the file systems won't allow you to add ambiguous metadata). They add (or have the option of adding) meta data in a standard block to the top of files. So your CF_Security might become this: Or even this: (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 eliminates the need for unique file names. It allows files to be moved around and such without losing information. It means that files could be added without touching the interface or could be added and then security managed via interface - whichever you like. In this sense the security system (the actual running system) doesn't need to know beans about files - only roles/permissions (which is the way I like it). The files are still managing
RE: Question about my security system
>> -Original Message- >> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] >> Sent: Monday, September 05, 2005 11:30 AM >> To: CF-Talk >> Subject: RE: Question about my security system >> >> >> I'm sure that's how entitlements are differentiated in >> >> Jim's apps (message_edit, user_edit, etc). >> >> > Nope. ;^) My apps are dumbasses. >> >> > The system just allows you make labels for things - you >> > get granular and do tasks or generic and do groups or >> > whatever - there's no difference in concept. >> >> > So far I've never needed more than generic "Admin", >> > "Editor", "Member" and "Visitor". >> >> Ahh, so you just do the one thing I expressly avoid. :P > Ah - but that's the point: I do that, but the system I > built does enforce that model. You could use the exact > same system to set up task-based permissions as well - > because functionality there's no difference. Umm... yes there is... Here's the functional difference: I've provided an application to someone else (not myself), and I've built in several roles. Now the other person, let's call him Bob, decides that the 3 roles I've built into the system aren't sufficient. If I've chosen to reference those role names in page, here are my instructions for adding a role: 1) Open Dreamweaver (or your preferred editor) 2) Find all the templates you want the role to have access to 3) modify the line where the user's roles are checked 4) save those templates Viola! You can now no longer upgrade to the latest version of my software easily. Comparatively, if I only reference the individual permissions in-page, here are the instructions to add a new role: 1) Open a browser and log in to the application 2) go to the admin section and add your role a) select the checkbox next to all permissions you'd like the user to have 3) press the save button Viola! No modifications to code = no hassles when you upgrade. You've not had to deal with these issues apparently because you've only used your security system on clients for custom site/app work which doesn't get resold, i.e. the code for FirstNight belongs to FirstNight (nevermind who holds the copyright) -- nobody else gets it. >> > I'm having the same problem here: I don't see any >> > conceptual difference between a role and permission. >> > The difference is all in the labeling and physical >> > concepts they represent, not the system level. >> >> Umm... no there's a pretty significant difference... >> >> Let me see if I can produce an example that illustrates >> it sufficiently: > >> Does that make more sense now? > Not at all. The question is not how to use them or > how you might define rules to use them, its how a system > would treat them differently. Or, more specifically why > a system would need to treat them differently. It's not a matter of treating them differently... It's a matter of their _being_ different. You can _treat_ them exactly the same, and the end result will still be different behavior/consequences (see above). > You set up a "group": "admin"; you set a permission > "DeleteUser". "DeleteUser" is assigned to "admin". > Template developers are told to only check > enititlements for the "deleteUser" permission. > How is this different from: > You set up a group "Admin". You set up another group: > "DeleteUser". DeleteUser is a child group of Admin. > Template developers are told to only check > enititlements for the "deleteUser" group. See above. I'm not writing software just for other developers -- I'm also writing it for non-developer/non-programmer users, some of whom will be administrators with the permission to change what privileges/tasks/rights/entitlements belong to what groups of users (roles). If I put references to the group names in page, then I've suddenly limited my target audience to writing software that's significantly less versatile because it requires a programmer to change roles. > In both cases all of these (groups, permissions, > entitlements, roles, tasks, etc) are just labels > - just labels which can be checked > against a membership list. It's true they are labels, but they're labels for different things... What you're saying is that I should be able to come to you and say a) Here is the accounting department (bunch of people). b) Here is a member of the accounting department, currently distributing a payroll check. a=b) The act of distributing (verb) a pay
Re: Question about my security system
>>template and then let the template know whether or not it can go ahead >>and perform the requested entitlement. > > > I think this is where I'm losing you. I see no difference between "groups" > and "tasks" in this. Ok, I think I figured out where we're getting mixed up. I come from windows administration land, so I am thinking about the setup a bit differently. When I say groups, I mean that I am creating real groups w/ group IDs in a database table and assigning users to those groups. I am not talking about logical groupings of users and calling those groupings "roles" or "entitlements" - those are two different things and I think that's where we're getting mixed up. I have specifically created tables that keep track of what users are part of what groups. So, here are some of my groups: Administrators Message Mods Organization Mods Users Public Users are then assigned into each of those groups utilizing a many-to-many relationship. I can then assign groups to resources instead of assigning individual users to resources. This is standard windows administration practice because it makes for easier user admin. Now whether this is the best strategy for web app security, that's another thing, but I'm giving it a try anyways. Now, my basic system currently works like this. I have a table that stores all the files on my site (they are uniquely named) and what groups are allowed to access each of those files. When a user requests a file, my cf_security tag (which is inserted at the beginning of every template) does a lookup to see what groups are allowed to access that file and then if the user is a member of one of those groups, it allows the user to access the file. If not, it will halt execution and go to an "access denied" template. Now, the only real permission (using windows lingo) that any user has with my basic system is execute. They either have permission to execute the file or not. Taking this a step further, I wanted to allow myself to assign other permissions (read, write, display, concatenate, jump, fly, whatever) to templates based on the actions that those templates might perform. 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. So, when a template is built, permissions need for that template are registered in the database and access is controlled by assigned groups to each of those permissions for that template. Is it overkill, maybe, maybe not. It's obviuosly not overkill for windows because people use file-level permissions all the time. I'm building a big application that is going to need a lot of different security contexts so making it very flexible and robust is key. Now, In my other emails I've gone over the nitty gritty of how I've programmed my current system and how I plan to program my newer concept, but the description above is the overall idea of how it will work. The ultimate goal here is to have a central security system where every permission in every template can be manged from a GUI. There will be no references to users or groups within the templates that are doing the actual processing. All the template cares about is whether it has permission to do something or not, and it's the cf_security tag (inserted at the top of every template) that tells the template what it's allowed to do (based on the pre-registered permissions for that template). Mike ~| 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:217385 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
RE: Question about my security system
> -Original Message- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Monday, September 05, 2005 11:30 AM > To: CF-Talk > Subject: RE: Question about my security system > > >> I'm sure that's how entitlements are differentiated in > >> Jim's apps (message_edit, user_edit, etc). > > > Nope. ;^) My apps are dumbasses. > > > The system just allows you make labels for things - you > > get granular and do tasks or generic and do groups or > > whatever - there's no difference in concept. > > > So far I've never needed more than generic "Admin", > > "Editor", "Member" and "Visitor". > > Ahh, so you just do the one thing I expressly avoid. :P Ah - but that's the point: I do that, but the system I built does enforce that model. You could use the exact same system to set up task-based permissions as well - because functionality there's no difference. > > I know - I've led a sheltered life. > > > It's also a tiny bit frustrating that spent so long > > modeling and building this security system and all > > I've ever needed from it is a four-way switch. ;^) > > Yes you have... wow... I'd have thought there'd be enough red-tape at > a major insurance company to guarantee you abstracted the permissions > beyond that. Whoa there, buddy. This was never for work (we've not even upgraded from CF 4.5 there yet!) In any case had I built it for the office they wouldn't have let me open-source it. (For what it's worth the office uses SiteMinder for its enterprise security system. Along with a lot of one-off "tactical" systems which are all being (rightly) pressured to move to the enterprise system.) I've used this system on FirstNight.org and DepressedPress.com and several intranet projects. In all those cases there's been a lot of "public" material, a small slice of "members only" and a smaller slice of "admin only". Easy peasy. ;^) > > I'm having the same problem here: I don't see any > > conceptual difference between a role and permission. > > The difference is all in the labeling and physical > > concepts they represent, not the system level. > > Umm... no there's a pretty significant difference... > > Let me see if I can produce an example that illustrates it > sufficiently: > Does that make more sense now? Not at all. The question is not how to use them or how you might define rules to use them, its how a system would treat them differently. Or, more specifically why a system would need to treat them differently. You set up a "group": "admin"; you set a permission "DeleteUser". "DeleteUser" is assigned to "admin". Template developers are told to only check enititlements for the "deleteUser" permission. How is this different from: You set up a group "Admin". You set up another group: "DeleteUser". DeleteUser is a child group of Admin. Template developers are told to only check enititlements for the "deleteUser" group. In both cases all of these (groups, permissions, entitlements, roles, tasks, etc) are just labels - just labels which can be checked against a membership list. You may conceptually limit things (like in your example) to "super labels" (groups, roles, etc) which may contain "child labels" (permissions, tasks, entitlements, etc) or not limit it and allow anything to contain anything else... but in the end they're the same thing functionally: "Is this person assigned to that label (or a label which inherits that label)?" The concept of groups vrs permissions is a convenient convention, not a system-level requirement. You decide to call some things "roles" and some things "permissions" and you, by convention, only check for the latter - but they're both the same conceptually: just labels. This is my point. Your explanation makes PERFECT sense when considering the UI to maintain these things however - that's where such conventions are needed. They simplify the management of the system and reduce the complexity of using it. But you don't need to restrict your underlying system to that model at all. The system can happily keep all this on the same conceptual level via a many-to-many parent-child relationship and an current-implementation-defined "context" catagory. Such a system could be leveraged to do EVERYTHING that's been discussed here for the past few days. The system doesn't care. You want complex inheritance? Fine. You want simple "role-permission" inheritance? Fine. You want simpler group-only checking? Fi
RE: Question about my security system
>> -Original Message- >> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] >> Sent: Sunday, September 04, 2005 4:25 PM >> To: CF-Talk >> Subject: Re: Question about my security system >> >> > Here's the problem - what if there is a template called >> > users.cfm for modifying user accounts. Now that user >> > will also have edit, delete, post, and read access >> > unless you differentiate the entitlement sets like: >> > messageedit, message_delete, message_post, message_read, >> > user_delete, user_edit. What I'm saying is that not >> > every template on the site uses the same set of >> > entitlements. While one template can perform one set >> > of actions, another template might be doing something >> > completely unrelated. >> >> I'm sure that's how entitlements are differentiated in >> Jim's apps (message_edit, user_edit, etc). > Nope. ;^) My apps are dumbasses. > The system just allows you make labels for things - you > get granular and do tasks or generic and do groups or > whatever - there's no difference in concept. > So far I've never needed more than generic "Admin", > "Editor", "Member" and "Visitor". Ahh, so you just do the one thing I expressly avoid. :P > I know - I've led a sheltered life. > It's also a tiny bit frustrating that spent so long > modeling and building this security system and all > I've ever needed from it is a four-way switch. ;^) Yes you have... wow... I'd have thought there'd be enough red-tape at a major insurance company to guarantee you abstracted the permissions beyond that. >> I personally hate security models that place role >> names in the page... imo the only thing an >> individual page should know about is the permission, >> and maybe the user (for performing >> impersonation or > I'm having the same problem here: I don't see any > conceptual difference between a role and permission. > The difference is all in the labeling and physical > concepts they represent, not the system level. Umm... no there's a pretty significant difference... Let me see if I can produce an example that illustrates it sufficiently: I produce software which I then give/sell to other people. The software comes with several roles "built-in" by default: Admin, Everyone, Anonymous. I have of course chosen what I believe to be the most logical set of permissions for each of these roles, but don't want to limit other people to only these roles. When someone else downloads my software and install it, there's a simple web-based interface through which they can create new roles and assign permissions for those roles. As the author, I have no idea what roles they have, or which roles have what permissions. However -- I'm still able to write software that integrates the security system, because I know what individual permissions are needed on any given page. If I put request.tapi.permit(x) in a page then any user who's a member of any role which has permission x will be able to use that page. If I went the other way and checked the user's role, I would either be locking people in to the hard-coded set of roles I chose for that permission, or I would be requiring them to edit the CFML code to change the permissions (bad mojo). Since I stick with just the permissions, people who download my apps are able to assign any permission to any role (custom or built-in except admin which gets everything) without ever changing any of the CFML. Does that make more sense now? >> otherwise checking to see if another user is >> permitted to perform a given task). And it's for >> the same reason you cite -- you can't then add >> roles without editing tons of different templates. >> There should be a single, logical and easy to use >> tool for updating user-roles and role-permissions >> in one place, and it shouldn't require extra > But you do have to create extra programming to add > permissions... so what's the difference? Umm... in most cases no I don't... The framework abstracts the permission to an individual process and then checks permission automatically... I do occasionally check the applicability of an alternate permission (for something other than the current process), but the system is designed such that someone who installs it elsewhere can actually create new permissions to secure sections of my application even if I didn't secure them, without writing any CFML. Moreover even if I am manually checking a specific permission within a page, the page doesn't know anything about what roles are granted to that permission, which allows the p
RE: Question about my security system
> -Original Message-
> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 04, 2005 4:25 PM
> To: CF-Talk
> Subject: Re: Question about my security system
>
> > Here's the problem - what if there is a template called
> > users.cfm for modifying user accounts. Now that user
> > will also have edit, delete, post, and read access
> > unless you differentiate the entitlement sets like:
> > messageedit, message_delete, message_post, message_read,
> > user_delete, user_edit. What I'm saying is that not
> > every template on the site uses the same set of
> > entitlements. While one template can perform one set
> > of actions, another template might be doing something
> > completely unrelated.
>
> I'm sure that's how entitlements are differentiated in Jim's apps
> (message_edit, user_edit, etc).
Nope. ;^) My apps are dumbasses.
The system just allows you make labels for things - you get granular and do
tasks or generic and do groups or whatever - there's no difference in
concept.
So far I've never needed more than generic "Admin", "Editor", "Member" and
"Visitor".
I know - I've led a sheltered life.
It's also a tiny bit frustrating that spent so long modeling and building
this security system and all I've ever needed from it is a four-way switch.
;^)
> I personally hate security models that place role names in the page...
> imo the only thing an individual page should know about is the
> permission, and maybe the user (for performing impersonation or
I'm having the same problem here: I don't see any conceptual difference
between a role and permission. The difference is all in the labeling and
physical concepts they represent, not the system level.
> otherwise checking to see if another user is permitted to perform a
> given task). And it's for the same reason you cite -- you can't then
> add roles without editing tons of different templates. There should be
> a single, logical and easy to use tool for updating user-roles and
> role-permissions in one place, and it shouldn't require extra
But you do have to create extra programming to add permissions... so what's
the difference?
> >> The key is that all of that complexity (groups of
> >> groups, etc) is abstracted away in a service-level
> >> component. You need to know the group or task you
> >> want to perform ("delete" or "member") but that's
> >> it - you ask the system "can he?" and it says
> >> "yes" or "no".
>
> > the requirement of knowing group or task is
> > specifically what I was trying to pull out of the
> > template-level code.
>
> Yeah, I would shy away from any system that recommends an individual
> page request to know if the current user is a member of a specific
> role to handle permissions instead of asking about a specific
> permission. The Members onTap component has tools to determine that of
Again - I'm just not seeing the difference. Whether page asks "can he
delete" or "is he an admin" is just syntax - they're both the same concept.
> > I just wonder how big of a memory hit that would be if I
> > have 7000 users with a pretty long entitlement list
> > loaded for every user. It'd probably be smart to use
> > some kind of abbreviation notation.
>
> Yep, see above... Store it in the application scope -- I'd even store
> the list of roles for a given user in a struct in the application
> scope and just compare that to a userid stored in the session... It'll
> save you a lot of both memory and sanity.
This is how I do things. It does work nicely.
The security system is a self-contained service. When a user logs in it's
given an identification key (I use a version of the CFTOKEN). Only that key
is stored in the session - and any data retrieved from the security service
is found by passing it the key.
The security service knows nothing about the application and the application
knows damn little about the security service. The service can be loaded
into the application scope or the server scope: since all of the data caches
are properties of the instantiated component it's up the application where
it wants to persist it - the security system couldn't care less.
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:217336
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
RE: Question about my security system
> -Original Message- > From: Mike Soultanian [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 04, 2005 3:24 PM > To: CF-Talk > Subject: Re: Question about my security system > > That's assuming that you have a defined set of entitlements. So, let's > say the user logs in and the system loads up that user's entitlements. > That list could be edit, delete, post, read (because they're a message > admin). But you MUST have this. Your pages need to have them predefined to work - however your label them, segment them, group them or whatever they must be redefined and agreed upon. > Again, I am trying to pull any group reference out of the templates. I > want the security system to do all the group lookups and cross-reference > it to the entitlements that were registered in the DB for that given > template and then let the template know whether or not it can go ahead > and perform the requested entitlement. I think this is where I'm losing you. I see no difference between "groups" and "tasks" in this. I define a role of "admin" and give some people that role or I define a task of "MessageEdit" and give some people the ability to do that - it's the same thing. The underlying implementation is exactly the same for both, aren't they? If the template has to say: If delete AND User entitled to delete Delete End if Then it's using "groups" = the group is called "delete" rather than "admin" or "editor" or what ever, but it's still a "group". Or, to reverse it: things like "Admin" and "editor" are really just entitlements no different than "delete". > Like above, you would have to create a subgroup for every possible > different entitlement that all the various templates would require. > Edit in the message.cfm template is definately not the same as edit in > the user manager. Yup. And that's all you're doing as well even if you don't know it... whether you say "messageDelete" or "Delete on the message page" you're really doing the same thing: setting up a specific entitlement. One of abstracting this is via some kind of "context" parameter. For example instead of "isEntitled(User, 'delete')" you might add a context modifier such as " isEntitled(User, 'delete', 'message') where "message" is a context for the entitlement. In your case you might keep your current idea and still do this - the context of the check would be the page: isEntitled(User, 'delete', CurrentPage) However I still think it's adding a lot of complexity to this for every single page when a conversational abstraction works. In the end this is really no different than just doing "isEntitled(User, 'messageDelete')" however. > the requirement of knowing group or task is specifically what I was > trying to pull out of the template-level code. But from everything I've seen it's still there - isn't it? If you're checking for a Boolean tag before doing something isn't that putting the task into the template? > > But your template still needs to "know" about groups here. How is that > > different than, say (let's say, to stick with your checking model, that > > "entitlements returns a struct of Boolean keys): > > the template doesn't need to know about groups. That's handled by the > security system which then tells the template if it's allowed to perform > the requested entitlement. But again - I'm not seeing the difference between groups and entitlements here. To me, so far, they're just two labels for the same concept. > In other words, the message template asks the security system "I have a > user logged in and they requested the delete entitlement, should I allow > this?" and the security system checks to see if that user has permission > to use that entitlement for the message template (this information would > be stored in the DB), and then the security system returns a true or > false back to calling template based on the permission settings. Sounds great - exactly what I've been talking about. ;^) For this to happen the security service doesn't need to know that they're in that template however, it doesn't need to know anything about the page. Just that this user wants to delete a message, can he? > Let's say the user also hits the user management template, that template > asks the system "I've got a user that wants to edit a user, should I let > them?" and the security system will go and check to see if that user has > permission to use that entitlement f
Re: Question about my security system
> Here's the problem - what if there is a template called
> users.cfm for modifying user accounts. Now that user
> will also have edit, delete, post, and read access
> unless you differentiate the entitlement sets like:
> messageedit, message_delete, message_post, message_read,
> user_delete, user_edit. What I'm saying is that not
> every template on the site uses the same set of
> entitlements. While one template can perform one set
> of actions, another template might be doing something
> completely unrelated.
I'm sure that's how entitlements are differentiated in Jim's apps
(message_edit, user_edit, etc).
>> You can then use the same system for group-level checks.
>> For example:
>>
>> if URL.action=delete & isEntitled(UserID, "admin,member")
>>delete message
>> end if
>>
>> This is saying that "if the person is a member of the
>> admin or moderator groups, let'em delete".
> Again, I am trying to pull any group reference out of
> the templates. I want the security system to do all the
> group lookups and cross-reference it to the entitlements
> that were registered in the DB for that given template
> and then let the template know whether or not it can go
> ahead and perform the requested entitlement.
I personally hate security models that place role names in the page...
imo the only thing an individual page should know about is the
permission, and maybe the user (for performing impersonation or
otherwise checking to see if another user is permitted to perform a
given task). And it's for the same reason you cite -- you can't then
add roles without editing tons of different templates. There should be
a single, logical and easy to use tool for updating user-roles and
role-permissions in one place, and it shouldn't require extra
programming to make that happen. Needing to program in the association
of permission to template is enough -- although for framework apps
I've eliminated most of that work as well. This is one of the reasons
I dislike using the built-in permission features in CFC's -- that and
the fact that I don't believe the individual domain-model CFC's should
be responsible for security because that more or less breaks
encapsulation. Securtiy should be an aspect of the view/controller.
>> With this you gain the concept of inheritance.
>> In your example, for example, there's really no
>> need to have the same permissions defined multiple
>> times. Instead have permissions inherited:
> Inheritance is definately something that I'd like to
> investigate further. I know that my example was very
> poorly written, but I'd definately like to optimize
> the code so it's using inheritance instead of brute
> force to figure out who's got access to what. After
> we get through this initial conversation, I'd like
> to further investigate your logic for how groups are
> inherited (the nitty gritty). But let's leave
> that for another thread ;)
I personally dislike the idea of inheritance in this context, and
would actually encourage against it... Same with user-permissions and
user-groups (members of user group x are also members of role y and
z). I think these concepts tend to result in lots of confusion from
the people using the user-management system with very little gain.
Individual user permissions mostly results in users using only
individual user permissions and thus creating way more work for
themselves (and everyone else) because they refuse to use roles to
accomplish the task for which they're intended. Role inheritance and
user-groups just confuse people. "Okay, so user x is a member of group
y and role z but since he's a member of group y that means he's also
members of roles a and q, so my user is a member of ... what now?" ...
or "Oh he shouldn't have permission to access that, I'll just remove
him from role x ... why does he still have that permission? Which
roles have that permission? He's a member of 7 groups, how many
freaking groups have one of those roles?!"
I generally recommend just having a many-to-many relationship between
users and roles (so a single user can be in several roles) and omit
all the other fancy bells and whistles that could be introduced here,
such as individual user permissions, inheritance or user groups. If
the users can understand the simple principals behind roles, this is
the easiest way for them to manage the application users.
>> The key is that all of that complexity (groups of
>> groups, etc) is abstracted away in a service-level
>> component. You need to know the group or task you
>> want to perform ("delete" or "member") but that's
>> it - you ask the system "can he?" and it says
>> "yes" or "no".
> the requirement of knowing group or task is
> specifically what I was trying to pull out of the
> template-level code.
Yeah, I would shy away from any system that recommends an individual
page request to know if the current user is a member of a specific
role to handle permissions instead of asking about a specific
permission. The Members o
Re: Question about my security system
Jim Davis wrote:
> retrieve userlevel
>
> if userlevel=admin
>Entitlements = delete, edit, post, read
> It's still the template that's protecting itself, not the security system
> enforcing rules over the template.
Ok, your version is a much cleaner example of the standard security
system that most people employ. We're still on the same page here...
> if URL.action=delete & isEntitled(UserID, "delete")
>delete message
> end if
>
> This is saying "I've got a user here that wants to delete - can he?"
>
> The complexity of the system is abstracted - the page needs to know nothing
> about possible entitlements, just the one specific it needs.
That's assuming that you have a defined set of entitlements. So, let's
say the user logs in and the system loads up that user's entitlements.
That list could be edit, delete, post, read (because they're a message
admin).
Here's the problem - what if there is a template called users.cfm for
modifying user accounts. Now that user will also have edit, delete,
post, and read access unless you differentiate the entitlement sets
like: messageedit, message_delete, message_post, message_read,
user_delete, user_edit. What I'm saying is that not every template on
the site uses the same set of entitlements. While one template can
perform one set of actions, another template might be doing something
completely unrelated.
> You can then use the same system for group-level checks. For example:
>
> if URL.action=delete & isEntitled(UserID, "admin,member")
>delete message
> end if
>
> This is saying that "if the person is a member of the admin or moderator
> groups, let'em delete".
Again, I am trying to pull any group reference out of the templates. I
want the security system to do all the group lookups and cross-reference
it to the entitlements that were registered in the DB for that given
template and then let the template know whether or not it can go ahead
and perform the requested entitlement.
> The concept is exactly the same: a task-based entitlement like the first
> just tends to result in more entitlements overall. Just like there's an
> "admin" group with some members there's a "delete" group with some members.
In my setup, I am not creating groups that mimic the entitlements. I am
creating groups and then assigning those groups to different
entitlements that the different templates require.
> You can combine the two into groups and subgroups - this is closest to what
> you have presented. So, the admin group has a sub group of "delete, edit,
> post, read" and some of those items are also assigned to other groups (it's
> a many-to-many relationship).
Like above, you would have to create a subgroup for every possible
different entitlement that all the various templates would require.
Edit in the message.cfm template is definately not the same as edit in
the user manager.
> With this you gain the concept of inheritance. In your example, for
> example, there's really no need to have the same permissions defined
> multiple times. Instead have permissions inherited:
Inheritance is definately something that I'd like to investigate
further. I know that my example was very poorly written, but I'd
definately like to optimize the code so it's using inheritance instead
of brute force to figure out who's got access to what. After we get
through this initial conversation, I'd like to further investigate your
logic for how groups are inherited (the nitty gritty). But let's leave
that for another thread ;)
> The key is that all of that complexity (groups of groups, etc) is abstracted
> away in a service-level component. You need to know the group or task you
> want to perform ("delete" or "member") but that's it - you ask the system
> "can he?" and it says "yes" or "no".
the requirement of knowing group or task is specifically what I was
trying to pull out of the template-level code.
> But your template still needs to "know" about groups here. How is that
> different than, say (let's say, to stick with your checking model, that
> "entitlements returns a struct of Boolean keys):
the template doesn't need to know about groups. That's handled by the
security system which then tells the template if it's allowed to perform
the requested entitlement.
In other words, the message template asks the security system "I have a
user logged in and they requested the delete entitlement, should I allow
this?" and the security system checks to see if that user has permission
to use that entitlement for the message template (this information would
be stored in the DB), and then the security system returns a true or
false back to calling template based on the permission settings.
Let's say the user also hits the user management template, that template
asks the system "I've got a user that wants to edit a user, should I let
them?" and the security system will go and check to see if that user has
permission to use tha
RE: Question about my security system
> -Original Message-
> From: Mike Soultanian [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 04, 2005 3:50 AM
> To: CF-Talk
> Subject: Re: Question about my security system
>
> Sorry,
> Now, the standard setup that I've seen goes as following: Most
> applications might have 3 user levels, admin, moderator, user. So,
> there will be a check in the processing portion of the message.cfm
> template that checks to see if the user has access to perform that action.
>
> So you have something like the following somewhere in the template:
Then this is no different than my system or any other security system. You
may be abstracting the template-level check but the rest is the same.
In a generic system your pseudo code might look like this:
retrieve userlevel
if userlevel=admin
Entitlements = delete, edit, post, read
if userlevel=moderator
Entitlements = edit, post, read
if userlevel=user
Entitlements = post, read
endif
if URL.action=delete & Listfind(Entitlements, "delete")
delete message
end if
That first part could be on the page, in an application.cfm or anyplace -
the key is that the user's entitlements are just a collection of labels (a
list in this case, a series of Booleans in yours). That list of labels,
once you get it (however you get it) can be turned into a list, a series or
Booleans or whatever.
It's still the template that's protecting itself, not the security system
enforcing rules over the template.
In a system like mine, where the entitlementments are abstracted into a
service this would change to simply:
if URL.action=delete & isEntitled(UserID, "delete")
delete message
end if
This is saying "I've got a user here that wants to delete - can he?"
The complexity of the system is abstracted - the page needs to know nothing
about possible entitlements, just the one specific it needs.
You can then use the same system for group-level checks. For example:
if URL.action=delete & isEntitled(UserID, "admin,member")
delete message
end if
This is saying that "if the person is a member of the admin or moderator
groups, let'em delete".
The concept is exactly the same: a task-based entitlement like the first
just tends to result in more entitlements overall. Just like there's an
"admin" group with some members there's a "delete" group with some members.
You can combine the two into groups and subgroups - this is closest to what
you have presented. So, the admin group has a sub group of "delete, edit,
post, read" and some of those items are also assigned to other groups (it's
a many-to-many relationship).
You still would have a single "entitlements" checker that returned just true
or false but it might be called like this:
isEntitled(UserID, "admin") OR isEntitled(UserID, "admin")
Since admin contains "delete" the first would work. Since "delete" is what
you want to do the latter would work.
With this you gain the concept of inheritance. In your example, for
example, there's really no need to have the same permissions defined
multiple times. Instead have permissions inherited:
type "Visitor" can "read"
type "Member" inherits "Visitor" and, in addition can "post"
type "Moderatator" inherits "Member" and, in addition can "edit"
type "Admin" inherits "Moderatator" and, in addition can "delete"
So, if you add somebody to the "moderator" group you can do:
isEntitled(User, "delete") and get false (neither moderator or any of it's
inherited roles has that permission).
Or
isEntitled(User, "member") and get true (moderators are, through
inheritance, members).
Or
isEntitled(User, "post") and get true (moderators can, through inheritance
of "Member" post).
The key is that all of that complexity (groups of groups, etc) is abstracted
away in a service-level component. You need to know the group or task you
want to perform ("delete" or "member") but that's it - you ask the system
"can he?" and it says "yes" or "no".
> Obviously this might not be the best example, but I think it should
> illustrate my point. So, based on whatever group the user is a member
> of, they'll be able to perform certain actions in the template
> message.cfm.
Exactly - that's the standard model.
> What I don't like about the example above is that I had to hard-code
> those checks in the template - in other words, I am explicitly coding
> admin, moderator, and user into the file. What happens if I decide I
> want to add a super-moderator level to the whole application? Now I
> need to go int
Re: Question about my security system
> Sorry, > I don't think I did the best job explaining it. > My approach is definately not the standard setup. > The key here is abstraction; abstracting any group > membership checks from templates. I'll try and > lay it out a bit more simply: Hey Mike, you might have a look at the onTap framework's Members onTap plugin, because it uses some similar concepts for handling permissions. Even if you don't use the framework, you might be able to get some ideas from it. Rather than storing a record for each template, part of the template path (discluding the file extension, i.e. .cfm) is prepended to the unique identifier for each process (function|entitlement|permission)... So for instance, you can have /admin/index.cfm = admin/index /admin/member/index.cfm = admin/member/index /admin/member/index.cfm?netaction=edit = admin/member/index/edit The process path (the right side of the equal sign) is the unique identifier used for each permission. Information about the current user is retreived from the session scope in the Application.cfm or during the onRequestStart event of the Application.cfc. Once that data is available, you can then call the permission function against any permission in the system on any page like so: ... display link to member edit page ... This function is called once automatically for each request to ensure the user has permission to use the requested process and if not the user is redirected to the login page. Once they log in, any form or url data that had been provided to the page prior to sending them to the login is then returned to that page to complete their requested process. Also, because the permission path is abstract, there's no necessary relationship between the permission path and a file... If you want a permission to determine if a user can see something on a page without creating a separate process/template for that page, all you have to do is append your desired string to the path for the parent process, and you can use a special character if you really want to make a clear distinction between the file/process permission and a virtual permission, i.e. admin/member/index/edit/$preferences to determine if the current user can change someone else's preferences. Since all the data to drive this authentication model is stored in the application (roles and permissions) or session (member data) scope you don't have to worry about extra database traffic on each request. s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~| 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:217325 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
RE: Question about my security system
>> Also, why wouldn't you trust the web server from >> providing the correct file name to the CF server? > It's not that I don't trust it... it's just that I don't > trust it. ;^) > If you're security system is based on this information > then you really want as little dependency as possible. > Do it all inside CF and you don't have to worry (as > much) about people spoofing a web server path or > something to circumvent your code. I don't think that's actually possible with an http request... and if it were, I don't think it would matter... Sure, you could say that because CF doesn't rely on the webserver to get its data for getBaseTemplatePath() or getCurrentTemplatePath() that it has fewer vulnerabilities... BUT... the webserver _MUST_ tell the CF server which template it needs to process in the first place. If the webserver doesn't provide the correct template path, CF processes a different template or produces a "file not found" error. If it processes a different template, then the cgi variables will still match the values returned by the CF native functions because, well... the webserver told it to process the other template. So... I don't think there's any reason to inherently mistrust the cgi variables... although I use getCurrentTemplatePath() in the Application.cfm or Application.cfc to get my application root path. (Although I have specifically seen the cgi.http_domain variable return an empty string erroneously, but I think that was a cf server bug). s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~| 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:217324 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
Re: Question about my security system
Sorry, I don't think I did the best job explaining it. My approach is definately not the standard setup. The key here is abstraction; abstracting any group membership checks from templates. I'll try and lay it out a bit more simply: Now, let's say you have one single template called message.cfm, and it can perform 4 actions: read, post, edit, delete. How that template knows what action to perform is based on the URL attribute passed (i.e. message.cfm?action=edit) - nothing special here. Now, the standard setup that I've seen goes as following: Most applications might have 3 user levels, admin, moderator, user. So, there will be a check in the processing portion of the message.cfm template that checks to see if the user has access to perform that action. So you have something like the following somewhere in the template: retrieve userlevel if userlevel=admin allowedtodelete=true allowedtoedit=true allowedtopost=true allowedtoread=true if userlevel=moderator allowedtodelete=false allowedtoedit=true allowedtopost=true allowedtoread=true if userlevel=user allowedtodelete=false allowedtoedit=false allowedtopost=true allowedtoread=true endif if URL.action=delete & allowedtodelete delete message end if Obviously this might not be the best example, but I think it should illustrate my point. So, based on whatever group the user is a member of, they'll be able to perform certain actions in the template message.cfm. What I don't like about the example above is that I had to hard-code those checks in the template - in other words, I am explicitly coding admin, moderator, and user into the file. What happens if I decide I want to add a super-moderator level to the whole application? Now I need to go into every file and update the processing section to include super-moderator; that could be very time-intensive. Now here's my solution. I want to abstract any group checking processing from the templates. The template shouldn't "care" about group names or users or what not, it just needs to know if it's allowed to do something. So, take the same example as above but rewrite it: if url.action=delete & caller.actiondelete delete message end if Here's what happens: A user calls message.cfm?action=delete. The cf_securitycheck tag checks to see if the user is logged in. If the user is logged in, it then looks up the actions stored in the database for message.cfm (lets assume the file has previously been registered in the database and permissions have already been set). The simplified relational tables may look like this: FILEACTIONS GROUPS message.cfm readusers, admins, mods message.cfm postusers, admins, mods message.cfm delete admins message.cfm editadmins, mods It looks in the database to see if the groups that the user is a member of have access to any of those actions. Then, any of the actions that the user is entitled to, it sets a variable to TRUE that the message.cfm template can see using the caller scope (i.e. cfset caller.deleteaction=true). So, let's say the user is a member of mods, it will return three variables set to TRUE to message.cfm: caller.actionread, caller.actionpost, and caller.actionedit. Now all you need to do in message.cfm is do a check to see if any of those variables were set to true and perform processing accordingly. Obviously it's somewhat complicated, and probably really database intensive, but it nicely abstracts any user processing from the end template (message.cfm in my example). This idea is purely theoretical right now as I haven't figured out all of the nitty gritty details. I might end up scrapping the idea because it is so database intensive, but I will still give it a try. For my application I may be adding and removing groups throughout the life of the application and I don't want to be adding group checks into the processing sections of the templates. So does that make any sense at all? Mike ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217320 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
RE: Question about my security system
> -Original Message- > From: Mike Soultanian [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 04, 2005 1:27 AM > To: CF-Talk > Subject: Re: Question about my security system > > Jim Davis wrote: > > 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? > > Well, I need the application to know what file is what because it is > going to return structures with "rights" (think windows NT rights) flags > back to the calling template based on permissions. So, let's say a page > can post, edit, or delete a topic, when the page is accessed, it will > check the current user's permissions and will set any "flag" variables > (or rights) to the template and let the template know, for lack of > better words, what it's allowed to do. Does that make sense? Sure - in the lingo you're returned a set of entitlements. The user can "do these things". But I'm still not clear why each page has to be defined separately. For example if you have three pages in a site which are part of the "add user" function (let's say the three pages are "enter data", "verify data" and "submit data") in your scheme you need to add three pages the system and allow "add user" to all of them. Instead it would seem simpler to create a role or group called "add user" and have those three pages check to see if the current user has that role or is a member of that group. In most cases security is pretty flat... many sites only have "administrator" and "visitor" for example. In a roles based scheme you just add people to the "administrator" group and pages which provide administrator functions make sure they're part of it. Unless I'm misunderstanding in your scheme every page with administrator functions will have to be defined separately and each user granted specific access to every one of those pages. > Like I mentioned above, the application will "tell" the page what it's > allowed to do based on the permissions of the user logged in. How the > system knows what permissions are associated with each different page is > another portion I have not explained, but it's not really that important > right now. I'm missing something (it wouldn't be the first time!) If the application "tells" the page... how is it enforced? Doesn't the page still have to 1) know that the function in question is covered under that label and b) agree to honor that restriction? And, since that's the case, why would you store a profile for every page in the site instead of just the roles? All the page needs to know is what the user can do - the system doesn't need to know what the page can do. > > 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. > > Ok, now, my question here is if I use that function, what template is it > going to return? Remember, this function is going to be called from a > custom tag that is located within the Application.cfm file. So will it > return the tag pathname, the application.cfm pathname, or the actual > file that was requested by the user? Actually in that case you'd probably want "GetBaseTemplatePath()" which returns the path of the root template (the template called by the web server). > Also, why wouldn't you trust the web server from providing the correct > file name to the CF server? It's not that I don't trust it... it's just that I don't trust it. ;^) If you're security system is based on this information then you really want as little dependency as possible. Do it all inside CF and you don't have to worry (as much) about people spoofing a web server path or something to circumvent your code. > > 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 think what I meant to say by secure was is there a way to get around > my tags. You kinda answered my question when you suggested not to trust > the CGI variables. Well - in either case there's a chance. Whether you link the tags from the template itself or from application it doesn't really matter. Remember that Application.cfm is really just an "auto include" - it runs as part of th
Re: Question about my security system
Jim Davis wrote: > 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? Well, I need the application to know what file is what because it is going to return structures with "rights" (think windows NT rights) flags back to the calling template based on permissions. So, let's say a page can post, edit, or delete a topic, when the page is accessed, it will check the current user's permissions and will set any "flag" variables (or rights) to the template and let the template know, for lack of better words, what it's allowed to do. Does that make sense? > 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. Like I mentioned above, the application will "tell" the page what it's allowed to do based on the permissions of the user logged in. How the system knows what permissions are associated with each different page is another portion I have not explained, but it's not really that important right now. > 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. Ok, now, my question here is if I use that function, what template is it going to return? Remember, this function is going to be called from a custom tag that is located within the Application.cfm file. So will it return the tag pathname, the application.cfm pathname, or the actual file that was requested by the user? Also, why wouldn't you trust the web server from providing the correct file name to the CF server? > 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 think what I meant to say by secure was is there a way to get around my tags. You kinda answered my question when you suggested not to trust the CGI variables. > 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): Thank you for posting the URL to your library. I saw you mention something about it in one of the COAL posts but I didn't see any urls. I will definately check out what you've done. > http://www.depressedpress.com/depressedpress/Content/Development/ColdFusion/ > DPLibraries/Index.cfm In regards to everything you wrote explaining your security system (I won't quote it all), there is one thing which I don't think it addresses which is specifically what I am looking for: In all the security systems that I've seen so far (even the built in one), they only assign permissions to files. Whether it's done by groups, roles, whatever, it still only says who can access a file. It doesn't really address the fact that pages and perform multiple duties. One thing I refuse to do is hard-code stuff like: if admin let me delete this message if moderator or admin let me edit this message if user i can't do crap endif I want my system to be completely dynamic such that it will keep track of what functions (or entitlements like you called it) each page can perform (like my example with the message posting page above), and who is allowed to perform each of those functions for that page. Now, how does the system know what tasks a page can perform? The page tells it in a tag. aw crap. I think I just answered my question as to why I have to put a tag at the top of each page. Ok, you know when you have one of those moments where you typed out an entire message about a question and then answered it at the very end. Well, I've just done that. Instead of retyping, I'm just going to continue... Ok, nevermind, you can ignore my questions about putting the tag in the application.cfm file. I still have to put it in the top of each file because it's in that tag that you specify what rights, or entitlements, that page has and then those rights are registered with the application and then assigned permissions. Then, when that page is requested by a user, the system checks to see if that user has permissions to access the file *and* what rights the user has permission to. Based on those permissions, the application then tells the calling page what it's allowed to do. Does that make any
Re: Question about my security system
Bobby Hartsfield wrote: > Being able to able to move and/or rename the templates and still have the > system keep track of them will most definitely prove to be tough if > everything else is important to you. Here's my plan, the system will check to see if a file has an ID at the top of it. If it does, it will check the permissions and make sure the current user has the credentials to pass through. If not, page load is halted. If the file doesn't have an ID, it will write an ID to the file being requested and halt processing because permissions haven't been set on the file. > To be able to shuffle them around, you'd be back to making sure every file > had its unique ID set at the top of the template. This is excactly why I want the ID creation scripted instead of me generating a random number to put at the top of each file. I thought of that, but I like automatic things better ;) > Rather you use path/filename or hash of cgi.script_name they are basically > the same thing. One is just encrypted. There really is no difference in > which one you use. Hashing them will require de-hashing them (but man those > hashes look cooler than dir/file.cfm) :) I can also use a random nubmer, it really doesn't matter. What matters is that each file has a unique id associated with it so my application can know what file is what. In the event that a duplicate is found, it will probably halt execution and do something cool ... like email me or log it or something like that haven't gotten that far yet.. >>I think what's going to be trick is converting the script_name to a >>path for cffile to understand. > > You can get the full path of file with getcurrenttemplatepath() > This will give the entire path including the file name Ok, I think I played with that a short while ago when I was messing around with uploading files. I'll take a look at that again. > Yes. Cgi.script_name will hold everything in the url that comes AFTER the > domain name (and before any url variables). So if you are at: > > http://mysite.com > > usually the default document in a CF app would be index.cfm so > cgi.script_name in this case would be "index.cfm" Got it! Thanks for the confirmations - I appreciate it. Mike ~| 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:217317 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
RE: Question about my security system
> -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: 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: ... Stuff if they're not entitled ... 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 th
RE: Question about my security system
> You know, I thought of something like this. I was going to use the > path/filename as the identifier, but then I'd run into the problem > like you mentioned below: Being able to able to move and/or rename the templates and still have the system keep track of them will most definitely prove to be tough if everything else is important to you. To be able to shuffle them around, you'd be back to making sure every file had its unique ID set at the top of the template. Rather you use path/filename or hash of cgi.script_name they are basically the same thing. One is just encrypted. There really is no difference in which one you use. Hashing them will require de-hashing them (but man those hashes look cooler than dir/file.cfm) :) > I think what's going to be trick is converting the script_name to a > path for cffile to understand. You can get the full path of file with getcurrenttemplatepath() This will give the entire path including the file name > Ok, that's cool to know. And this CGI.script_name variable > *always* refers to the file that's being called, correct? Yes. Cgi.script_name will hold everything in the url that comes AFTER the domain name (and before any url variables). So if you are at: http://mysite.com/dir/index.cfm?myvar=something It will hold "dir/index.cfm" (ps. Use cgi.query_string for the variables) Dont be fooled, it doesnt read it from the url. Take this for instance. http://mysite.com usually the default document in a CF app would be index.cfm so cgi.script_name in this case would be "index.cfm" -Original Message- From: Mike Soultanian [mailto:[EMAIL PROTECTED] Sent: Saturday, September 03, 2005 11:56 PM To: CF-Talk Subject: Re: Question about my security system Bobby Hartsfield wrote: > I haven't seen the previous thread you mentioned but the "easiest" way to > secure specific templates is to have them all located under a central > location like /secure or /administrative or whatever. > > In the top level of that directory put an Application.cfm that includes your > "security script" so it is included in every template under that directory. > (You can also just include the parent application.cfm to bring any settings > in without duping any code.) In my case, every file would need to have the file id associated with it so I'd just use the main application file. I like the include idea if I did have to break it off for some reason. > If you don't do it this way, and you have mixed templates (some secure some > not) all scattered under one root, I don't see a way around including your > script in every page that you want secured (other than querying for it's ID > to see if it is secure, but why waste the time effort or processing). Like above, I'll be keeping track of every file so that won't be an issue as far as some being secure and non-secure. I guess a better wording would be keeping track of files. I really want every file in the system to have a unique identifier, regardless if it's public or not. > If you already have it logically laid out like you want and you're only > concern is rather or not the cgi.script_name will fail on you, don't worry. > It won't. Ok, that's cool to know. And this CGI.script_name variable *always* refers to the file that's being called, correct? I know this should be the case, but I just want to do a sanity check. This *is* my security system so I want to make sure it's foolproof. I think what's going to be trick is converting the script_name to a path for cffile to understand. I'll have to look at the file/path functions available and hopefully I can extract what I need. Should be interesting... > Here is a good trick for unique template IDs > #hash(cgi.script_name)# You know, I thought of something like this. I was going to use the path/filename as the identifier, but then I'd run into the problem like you mentioned below: > If that is your templates uniqueid, there is no need to make sure it is set > at the top of every page. > > Once those hashes are stored in the database, the only thing that would pose > a problem would be moving or renaming the template. exactly. I want this system to be dynamic and flexible. I want to be able to move a file anywhere under the root and have the system always be able to identify it, regardless of filename or location. > I hope any of that helps (or even makes sense). definately. Thanks! > > ~Bobby > > -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 ea
Re: Question about my security system
Bobby Hartsfield wrote: > I haven't seen the previous thread you mentioned but the "easiest" way to > secure specific templates is to have them all located under a central > location like /secure or /administrative or whatever. > > In the top level of that directory put an Application.cfm that includes your > "security script" so it is included in every template under that directory. > (You can also just include the parent application.cfm to bring any settings > in without duping any code.) In my case, every file would need to have the file id associated with it so I'd just use the main application file. I like the include idea if I did have to break it off for some reason. > If you don't do it this way, and you have mixed templates (some secure some > not) all scattered under one root, I don't see a way around including your > script in every page that you want secured (other than querying for it's ID > to see if it is secure, but why waste the time effort or processing). Like above, I'll be keeping track of every file so that won't be an issue as far as some being secure and non-secure. I guess a better wording would be keeping track of files. I really want every file in the system to have a unique identifier, regardless if it's public or not. > If you already have it logically laid out like you want and you're only > concern is rather or not the cgi.script_name will fail on you, don't worry. > It won't. Ok, that's cool to know. And this CGI.script_name variable *always* refers to the file that's being called, correct? I know this should be the case, but I just want to do a sanity check. This *is* my security system so I want to make sure it's foolproof. I think what's going to be trick is converting the script_name to a path for cffile to understand. I'll have to look at the file/path functions available and hopefully I can extract what I need. Should be interesting... > Here is a good trick for unique template IDs > #hash(cgi.script_name)# You know, I thought of something like this. I was going to use the path/filename as the identifier, but then I'd run into the problem like you mentioned below: > If that is your templates uniqueid, there is no need to make sure it is set > at the top of every page. > > Once those hashes are stored in the database, the only thing that would pose > a problem would be moving or renaming the template. exactly. I want this system to be dynamic and flexible. I want to be able to move a file anywhere under the root and have the system always be able to identify it, regardless of filename or location. > I hope any of that helps (or even makes sense). definately. Thanks! > > ~Bobby > > -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. > > 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. > > 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 hope that's not too confusing what I'm trying to do. If you
RE: Question about my security system
I haven't seen the previous thread you mentioned but the "easiest" way to secure specific templates is to have them all located under a central location like /secure or /administrative or whatever. In the top level of that directory put an Application.cfm that includes your "security script" so it is included in every template under that directory. (You can also just include the parent application.cfm to bring any settings in without duping any code.) If you don't do it this way, and you have mixed templates (some secure some not) all scattered under one root, I don't see a way around including your script in every page that you want secured (other than querying for it's ID to see if it is secure, but why waste the time effort or processing). If you already have it logically laid out like you want and you're only concern is rather or not the cgi.script_name will fail on you, don't worry. It won't. Here is a good trick for unique template IDs #hash(cgi.script_name)# If that is your templates uniqueid, there is no need to make sure it is set at the top of every page. Once those hashes are stored in the database, the only thing that would pose a problem would be moving or renaming the template. I hope any of that helps (or even makes sense). ~Bobby -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. 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. 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 hope that's not too confusing what I'm trying to do. If you'd like further explanation, let me know! Thanks, Mike ~| 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:217311 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
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. 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. 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 hope that's not too confusing what I'm trying to do. If you'd like further explanation, let me know! Thanks, Mike ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217309 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
