I have an interesting situation at work whereby both table of contents
navigation as well as feature content and the features themselves need to be
limited based on your permissions level. While I used cfObjects to help me
easily accomplish this, Fusebox could easily implement the same protocol.
The advantage of our simple solution is that any time you have content or
features (visual displays of text or form interactions as well as buttons
representing features on a per page basis) you need only simple surround the
content with an appropriate call to check a predefined, pre-loaded
permissions string for the permissions that would grant that use access.
This makes the coding very simple for other developers and it is very easy
to administrate. The downside is that ultimately, while data drive, hard
coded "code" values for each level of permission must be included in the
code. We thought of mathetmatically handling this with algorythms based on
bit-wise operation but management decided against it. I'm not sure I agree
with that decision, but this solution, while a little more maintenance is
necessary up front...is pretty simple and gets the job done.
Mike Craig
-----Original Message-----
From: JME Maxwell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 06, 2001 8:03 AM
To: Fusebox
Subject: RE: assigning permissions to fuseactions
Hi Emilio,
I've just had to deal with some security issues on a site I am currently
working on.
I did not come up with a good universal security schema but I did come
across a few things which may or may not be useful.
1. Not allowing a user to invoke an action through your interface is not
enough.
Using brute logic (not a universal security scheme for fuseActions) we
originaly prevented a user from accessing certain fuseActions on the website
by not presenting them with eXitfuseActions to get there.
However if the user could guess at how to access those fuseActions (A user
who once had permissions to do something but had them revoked) they could
modify the HTML on the client side and call the prohibited fuseActions just
as if we had allowed them to from the interface.
What we had to do was check the users security at the time of execution of
the fuseAction.
We had to run a security routine ensuring that the user executing it was a
user who had permissions to.
2. Encapsulating security routines in a circuit application makes them easy
to maintain.
When we originaly tried to implement a security routine we tried to write it
in a function (Our shop uses a fnx_ prefix for this). As we identified more
and more places where we needed to implement security, each with different
rules our function became more and more convoluted.
Eventualy we broke the security logic out in to a circuit application. Each
fuseAction in the circuit application was another security rule.
Ex: fuseAction = "postingSecurity"; users can only modify postings which
they have made
fuseAction = "digestSecurity"; only users with administrative
privlidges for a section may send the E-mail digest.
I know this doesn't answer your question, but maybe these security solutions
may help you out a bit.
JME
-----Original Message-----
From: Emilio [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 05, 2001 9:16 PM
To: Fusebox
Subject: assigning permissions to fuseactions
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
