I've been through a bunch of different styles of security over the last
5 years and i've ended up on one that I've been using for almost a year
now on about 60-70 different circuit applications, it's only required
very minor changes. Here is what I've come up with:
1) Securing a Fusebox application can happen at 4 levels
1) Secure the entire 'home' application (call the security module in
your application.cfm)
2) Secure individual 'circuit' applications (call the security module
at the top of your index.cfm)
3) Secure individual Fuseactions (call the security module at the top
of each cfcase tag
4) Secure individual exit points (wrap the exit point with the security
module)
2) Securing the areas should allow for the 3 different states of users
1) Anyone can access the area in step 2 (Unknown user)
2) User must have filled out a form (Registered User)
3) User must belong to the appropriate group (Known user)
3) After a user logs in, the user should maintain focus on what they
were doing, it shouldn't take them to some new page that confuses them.
This is where the <cf_returnfuseaction> tag comes in.
4) After a user logs in they should be assigned a #client.user_id# and
#client.user_groups# (the names are unimportant). User_ID is used to
obtain more information about the user if necessary, user_groups
specifies which groups they belong to, this way you can quickly verify
if a user can access an area.
5) After the user logs out it should delete their client variables
That covers most of it, i left out some minor things. As soon as I free
up an hour (when will that be?!) I'll post some code and a tutorial on
how to do this.
Steve Nelson
Emilio wrote:
>
> Hello all,
> I've been hassling some people off list with this one and decided to post
> the question here:
> Has anyone put any R&D into assigning permissions to fuseactions which then
> get compared to the user's available permissions? now the permissions I'm
> talking about are not "Admin" or "Editor" I'm referring to OS style
> Read|Write|Delete|Archive|yadda.
>
> I have group security in place currently with some code from
> www.halhelms.com/bpcf/ and this works fine. I want/need the ability to ask
> a couple more things on each request.
> 1) does the user requesting the fuseaction have the permission required to
> invoke the "action"? more specifically, using group permissions, if I
> wanted to create a method to allow certain users the delete ability and
> other user who do not have the delete ability I would need to create 2
> groups and then use the LoginBlocks/ReturnStack ( see bpcf ) around each
> "button" or menu choice...
> 2) does the requested fuseaction have multiple eXit points? If so does the
> user have the ability to invoke any of those actions? this is important for
> usability in that I don't want the user to see a button they can't activate
> or select a menu option which will only ever produce,"I'm sorry you can't do
> that" How frustrating for the user.
>
> the easiest example would be that of the "user" form or whatever noun you
> like. So the example I'm thinking is that potentially, the form could have
> 4 eXit points:
> 1) New
> 2) update
> 3) delete
> 4) refresh/clear
>
> now as a member of the website_GOD group I should be able to do whatever I
> want to eXit the form, if however I'm a member of the MakeNewUsers_FOO group
> I can only use this form to add new users and so I shouldn't see an update
> or delete button.
>
> To back track a step here, I'm really looking for something db driven in
> that if one of those above groups had their permissions/fuseaction list
> modified, it makes more sense to have the db find all the users of that
> group to modify the change as opposed to a scheduled CF operation. I also
> like the ability to store all the fuseactions in a db, though to be honest I
> don't know why. I am aware that trying to use a db for validating every
> user request does not make much sense either.
>
> My ideal scenario would be to have a custom tag which is passed the id of
> the fuseaction and the userID and depending upon what the user has for
> permissions, generate XFA's accordingly. Then in the dsp_page if a user
> doesn't have the delete flag, an empty XFA is passed in which tells the
> dsp_page to not put a delete button.
> the solution would have to prevent a user from hand typing a fuseaction they
> weren't able to process but as it appears from this post each fuseaction
> would need to be checked against the master list...
>
> That is all assuming each action is bound to one fuseaction. We have cases
> though where the Add/Update is handled by the same fuseaction
> (usr.saveUserForm)...which is another thing I'd like to establish; should
> fuseactions be kept singular in their design or can related functionality be
> grouped into a single fuseaction? Any comments
>
> An example of this would be a storedProc used to update that user. If the
> userID field is blank (or some other fancy flag) then the storedProc runs
> the INSERT vs. the UPDATE...is this burying business logic, making it easier
> to work with? I dunno.
>
> Wow, that was a mouthful eh?
>
> Cheers,
> Emilio
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
