IsUserInAnyRole() bug

[Stefan]

In ColdFusion, you do:

isUserInAnyRole('role1,role2,role3')

But that throws an error in Railo: "too many Attributes in function
[ISUSERINANYROLE] "

In Railo you are supposed to do this (for a reason I do not
understand)

if (sUserInAnyRole())
writeOutput("huarrah");

That could easily be accomplished with

if (len(getuserroles()) gt 0)
writeOutput("huarrah");

To do isUserInAnyRole('role1,role2,role3') the Railo way is far more
time consuming,

if (isUserInRole('role1') OR isUserInRole('role2') OR isUserInRole
('role3'))
writeOutput("you can enter");

This in combination with the fact that <cffunction> does not support
the roles attribute (of course that is not mention in the
compatibility chart) makes me seriosly consider to wipe it off my hard
drive, because I have a LOT of role based code on the admin side of my
sustem, which is still running CF.

Is this a bug, or what? I could live without having 'roles' in the
cffunction, but this strange behaviour of sUserInAnyRole() will really
make my life an orgie in pain for weeks.

Sorry if I sound annoyed, but I am.

[Stefan]

Is the role system topic non grata here? All questions about that
subject is met with silence.

[Peter Boughton]

Stefan, I suspect it's because not many people actually use
cflogin+related, so aren't able to offer suggestions.

Since the CF docs for isUserInAnyRole do say (although not clearly)
that it supports an optional argument which is a list of roles, this
counts as a compatibility bug, so you can go raise it in Jira.

As a temporary workaround, you could use a function along the lines of
this to avoid the long-winded method:

<cffunction name="isUserInRoles" returntype="Boolean">
<cfargument name="RolesList" type="String" required="false" />

<cfif StructKeyExists(Arguments,'RolesList')>
<cfset var CurRole = 0 />
<cfloop index="CurRole" list="#Arguments.RolesList#">
<cfif IsUserInRole(CurRole)>
<cfreturn true/>
</cfif>
</cfloop>
<cfelse>
<cfreturn isUserInAnyRole() />
</cfif>

</cffunction>


And if you never use the non-argument version of isUserInAnyRole, you
can use Railo's custom built-in functions to override the core
function with something like the above so you don't need to change
your original code.

[Todd Rafferty]

Sorry Stefan, I've always rolled my own security rather than relying on ACF implementation.

~Todd Rafferty ** Volunteer Railo Open Source Community Manager ** http://getrailo.org/

[Sean Corfield]

I gave up using roles on function a long, long time ago (long before I
started using Railo). The problem is that you just get a nasty
exception at the call site and so your error handling options are
limited and that leads to a poor user experience. The basic <cflogin>
machinery is OK, sort of, for simple stuff but the roles stuff was
never well thought out and many people think it's unusable.

That's probably why no one ever responds to questions about roles on
<cffunction> here. Very few users have requested that be added, BTW.

Per Peter B, it does sound like a compatibility bug with
isUserInAnyRole() so please add that to JIRA and it'll get addressed.
That aspect of roles - programmatically checked - is just about usable
in ACF although, like most other CFers, I tend to roll my own system
using groups and permissions which is far more flexible.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Stefan]

I usually handle role checking outside the functions as well, but what
I like with cffunction roles= is that it guarantees that the method is
not being accessed and executed by mistake/hack/lazy coding whatever.
When several people program against the same components, maybe in
different contexts and even applications, it is easy that some random
hack is left around that is using admin functions without proper
security check.
I went the other direction, from finding cflogin and roles useless to
thinking they actually do a decent job at component level. It's not
ideal, but you get a "standard" way of dealing with it without
creating a separate "standard" framework that everyone has to accept
and learn.

But regardless of it's usefulness, I think it is important to make it
clear that cffunction does not handle roles, in the compatibiliay
chart on the web page. It was a nasty surprise for me.

S

On Nov 27, 6:07 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Fri, Nov 27, 2009 at 2:55 AM, Stefan
>

> <stefan.vesterl...@googlemail.com> wrote:
> > Is the role system topic non grata here? All questions about that
> > subject is met with silence.
>
> I gave up using roles on function a long, long time ago (long before I
> started using Railo). The problem is that you just get a nasty
> exception at the call site and so your error handling options are
> limited and that leads to a poor user experience. The basic <cflogin>
> machinery is OK, sort of, for simple stuff but the roles stuff was
> never well thought out and many people think it's unusable.
>
> That's probably why no one ever responds to questions about roles on
> <cffunction> here. Very few users have requested that be added, BTW.
>
> Per Peter B, it does sound like a compatibility bug with
> isUserInAnyRole() so please add that to JIRA and it'll get addressed.
> That aspect of roles - programmatically checked - is just about usable
> in ACF although, like most other CFers, I tend to roll my own system
> using groups and permissions which is far more flexible.
> --
> Sean A Corfield -- (904) 302-SEAN

> Railo Technologies US --http://getrailo.com/
> An Architect's View --http://corfield.org/

[MrBuzzy]

I'm with Stefan on this one :)
I've used cflogin, isuser* and cffunction security widely and without problem. Sure you can run in to limitations, or discover that it's not for you. But some of us discovered it's pretty effective Or at least has its place as an optional set of features that are nice to use.

I'd like to see these implemented (if the goal is greater compatbility?), or *one day* I might have to rework a whole bunch of (CF 8.0.1) code so it 'supports' Railo :) 

--

You received this message because you are subscribed to the Google Groups "Railo" group.
To post to this group, send email to ra...@googlegroups.com.
To unsubscribe from this group, send email to railo+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/railo?hl=en.

[Sean Corfield]

On Fri, Nov 27, 2009 at 2:41 PM, MrBuzzy <mrb...@gmail.com> wrote:
> I've used cflogin, isuser* and cffunction security widely and without
> problem. Sure you can run in to limitations, or discover that it's not for
> you. But some of us discovered it's pretty effective Or at least has its
> place as an optional set of features that are nice to use.

Just something to consider: the roles check requires that code for
every single function call perform an additional check on the
function's metadata to see if roles= is present so support for roles
will slow all method calls down, everywhere in your code.

So *if* we were to implement it, I suspect we would add another admin
setting for whether roles= was checked and default it to off - that
way only people who care about roles= have to pay the penalty.

Feel free to add it to UserVoice using the feedback tab on the community site.

--
Sean A Corfield -- (904) 302-SEAN

Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

[Stefan]

Well, as I said, I can live without them, but it should be clear in
the documentation that it is not supported. Since you get no warning,
you might believe that your CF code is secure, like it was in
ColdFusion, but it's not. Usually, one test security while you
implement it and unless you have reasons to suspect otherwise, it is
easy to assume your ColdFusion code works also in Railo if you get the
right functionality without errors. .

On Nov 28, 4:35 am, Sean Corfield <seancorfi...@gmail.com> wrote:

> On Fri, Nov 27, 2009 at 2:41 PM, MrBuzzy <mrbu...@gmail.com> wrote:
> > I've used cflogin, isuser* and cffunction security widely and without
> > problem. Sure you can run in to limitations, or discover that it's not for
> > you. But some of us discovered it's pretty effective Or at least has its
> > place as an optional set of features that are nice to use.
>
> Just something to consider: the roles check requires that code for
> every single function call perform an additional check on the
> function's metadata to see if roles= is present so support for roles
> will slow all method calls down, everywhere in your code.
>
> So *if* we were to implement it, I suspect we would add another admin
> setting for whether roles= was checked and default it to off - that
> way only people who care about roles= have to pay the penalty.
>
> Feel free to add it to UserVoice using the feedback tab on the community site.
> --
> Sean A Corfield -- (904) 302-SEAN

> Railo Technologies US --http://getrailo.com/
> An Architect's View --http://corfield.org/