If you are using Win NT, you could do this... I'm sure there are better,
cleaner ways, but one down-n-dirty way is to read the permissions using an
NT command called "CACLS", which, amongst other things, will iterate the
permissions for a given file or directory.
The devil is in the detazils of course, and in this case, it means parsing
out the results. I'm using CACLS in a project now, for an on-line document
library where users can create their own libraries, and add specific authors
to their libraries. I'm doing the whole thing by writing batch files, and
using CFEXECUTE to run them. It works great!
If I was in your shoes, I'd rework things a bit so that I'd execute a batch
file that invoked CACLS, and wrote the results to a text file, that I'd then
CFFILE in and parse out to determine the permissions.
Mind you, this would not be practical on a site with a ton of simultaneous
users, what with all this batch file executes and file reads an' all.. But
in an intranet environment, it would probably work great.
Alan McCollough
Web Programmer
Allaire Certified ColdFusion Developer
Alaska Native Medical Center
> -----Original Message-----
> From: Emilio [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, March 05, 2001 5: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
