I've been thinking about this one for a week now - doing a compare &
contrast against how we use cflogin here...
On Saturday, August 17, 2002, at 03:56 , Matthew Walker wrote:
> When we display menus, only the
> menu items associated with fuseactions permitted for that user's user
> group
> appear.
So, in this case you need to perform specific tests to see whether the
logged in user has permission to access the menu item. That's
application-specific logic that you can't directly get around. More below.
> But also when somebody tries to perform some action, the database is
> looked up to check if that fuseaction is assigned to that user group.
Yes, and that's a specific security check, presumably to ensure people can'
t spoof your system by invoking fuseactions directly, when they're not
accessible from the menus? It makes sense to use the same logic as the
test above, since you need to be consistent.
> We are about to transfer this CMS to CFMX and give it an overhaul, so we
> are
> free to use cflogin technology or not in whatever seems the best way. We
I think an approach that might work for you is this (sounds like you're
using a database for user authentication and user roles already?):
cflogin
look up username / password
if valid
lookup user groups
cfloginuser name= password= roles="#groups#"
(comma-separated list)
/cflogin
Presumably you have logic that, for a particular action, looks up the
groups for which that action is allowed and returns true/false? Here it is
with cflogin machinery:
allowed = false
look up groups for action
for each group
if isUserInRole(group)
allowed = true
break
if allowed
show menu item
If each action has only one group, this is much simpler:
look up group for action
if isUserInRole(group)
show menu item
Inside each action I presume you have a similar check so a variant of that
code would also work.
> Is there a particular physical reason why hundreds of roles shouldn't be
> assigned to a user or is it simply not Macromedia's vision?
I don't know what the performance of isUserInRole() would be for "hundreds
of roles" supplied to cfloginuser. If the roles are held internally as a
list (string) then performance would probably suffer since string
operations aren't exactly blisteringly fast in Java. If the roles list is
converted into a more efficent structure, then isUserInRole() ought to be
pretty fast. A simple test should be able to determine this.
We use roles in this way in some of our applications but we don't have a
long list of possible roles, maybe only a dozen, and each user usually
only has one or two roles.
We also have a few very high-level roles which we use for security, i.e.,
where we specify roles="xxx" on cffunction, mostly to prevent simple
malicious use. Note that that level of check - within CF itself - is
purely security and could not be considered a user-friendly permissions
check (since you'll get a CF-level error message).
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
______________________________________________________________________
This list and all House of Fusion resources hosted by CFHosting.com. The place for
dependable ColdFusion Hosting.
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
