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
