There are a number of things you can do, but most of them involve multiple
logic tags. Here is one that doesn't:
<html:text property="property1"
disabled="<%= !request.isUserInRole("admin") ? "true" : "false" %>"
/>
That will set disabled to "true" when the user does not have the "admin"
role. This assumes that you are using a security setup where
request.isUserInRole() works, which means container-managed security or a
filter-based solution like SecurityFilter. You may also choose to use
multiple logic tags, etc., as a matter of convention or in the interest of
clarity or minimizing <%= %> stuff.
This will handle the UI side of things. But it would be very easy for a user
to sidestep this "security" approach unless you also add checking to make
sure the user has the role required to change this property on the server.
If the action that handles this form after it is submitted just blindly
accepts any values or chages to values without checking for access, a user
could construct their own request to change the value, even if they don't
have the "admin" role. Don't trust the access level if it is simply a hidden
field or something, as the user can change that, too.
To really protect your app, you would need to do something like this (in the
Action):
if (request.isUserInRole("admin")) {
myPersistentObject.setProperty1(bean.getProperty1());
} else {
// user doesn't have access, so ignore any changes to property1
}
It can be useful to include the access information in the ActionForm if you
want to pass it down to your business logic level, thereby avoiding coupling
your business logic processing to the security framework of the web
environment. If you do this, just be sure to re-set the values you get with
the form submission to protect your app from the user changing them
maliciously. Your action might have code like this for such protection:
// The user might set this to "true" in their form submittal even if they
don't have access.
// Throw out the value from the form submittal and set it properly before
passing the
// ActionForm (bean) to the business logic processing layer
bean.setUserHasAdminAccess(request.isUserInRole("admin") ? "true" :
"false");
// the doSomething() method will call bean.getUserHasAdminAccess() to see if
the user
// should really be allowed to change property1
BusinessLogicProcessor.doSomething(bean);
Don't trust the request! Anyone can submit whatever they want to your web
app. That's one reason we do server-side validation. You obviously have to
"trust" some information, but it is all too easy to open security holes in
your app if you are too trusting. Without such server-side processing, a
user could run these commands to change things that you don't want them to
change:
curl -d "property1=haha_I_changed_it" http://server/wreakHavoc.do
curl -d "property1=haha_I_changed_it&userHasAdminRole=true"
http://server/wreakHavoc.do
You can login and use a session with curl, too, since it supports cookies.
So don't think that hurdle will protect you app. Here's an example:
curl -c cookies.txt -b cookies.txt -d
"j_username=badboy&j_password=password" http://server/j_security_check
curl -c cookies.txt -b cookies.txt -d
"property1=haha_I_changed_it&userHasAdminRole=true"
http://server/wreakHavoc.do
You can even do some of this stuff in the browser, which will maintain the
session for you. A user could type this into the address bar:
http://server/wreakHavoc.do?property1=haha_I_changed_it&userHasAdminRole=tru
e
I get a lot of "who's going to do that?" responses when I bring this stuff
up. But frankly, anyone who knows a little HTTP and HTML can do this quite
easily. It might be a disgruntled or merely mischeivious
employee/associate/customer on an intranet or extranet app. Or anyone on the
internet for an extranet or internet app. If you don't think about this
stuff from the beginning and take measures to protect your app, you can end
up in a very bad situtation where you have to go over the whole app to find
and close security holes. That can make a mess of your architecture if you
have to pile on a bunch of code where you didn't expect to need it, and
could be a very bad thing for your company or career if you have holes that
lead to lost money, destroyed data, or merely a damaged reputation.
Understanding these simple 'hacking' techniques go a long way toward toward
developing secure systems, but many web app developers are not aware of
them. Any time you create some functionality, take a moment to "think like a
hacker" and see how the new functionality might allow the user to do
something they aren't supposed to be able to do. Be careful!
-Max
----- Original Message -----
From: "Sebastien Cesbron" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, March 21, 2003 1:35 AM
Subject: Re: Fine Grained Access Control in Sturts
> And what about "read" mode for role "newbie" and "write" mode for role
> "admin".
>
> Is there a way not to put the input field twice with two different
> logic:present tags ?
>
> Does anybody have an idea on how to change display based on the role
> (and maybe something else) ?
>
> Seb
>
> Max Cooper wrote:
> > You can use the logic tags to do something like this:
> >
> > <logic:present role="admin">
> > <html:link page="/admin/Admin.do">Admin</html:link>
> > </logic:present>
> >
> > This assumes you are using a security mechanism where
> > request.isUserInRole("admin") will return true when the user is in that
> > role. For that to work, you must use container-managed security or a
> > filter-based solution like http://securityfilter.sourceforge.net/.
> >
> > -Max
> > shamelessly plugging SecurityFilter again :)
> >
> > ----- Original Message -----
> > From: "Mike Duffy" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, March 20, 2003 12:23 PM
> > Subject: Fine Grained Access Control in Sturts
> >
> >
> >
> >>Does anyone have any thoughts on fine grained access control in
> >>Struts?
> >>
> >>Struts enables access control based on actions (see "Struts in
> >>Action", Husted, et. al., pp 550-553), and most application servers
> >>can protect resources based on realms/roles.
> >>
> >>But what about display options based on roles. For example, if you
> >>only wanted an "Admin" link to appear if the user was an
> >>administrator, what would be the best way to do this?
> >>
> >>You could make the "role" an attribute of the user object and then do
> >>a logic test for the appropriate role. Or it might be even better to
> >>write a logic tag that takes the user role as an attribute. Any
> >>thoughts?
> >>
> >>Thanks for your consideration.
> >>
> >>BTW. The Husted book is a very good book.
> >>
> >>Mike
> >>
> >>
> >>__________________________________________________
> >>Do you Yahoo!?
> >>Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> >>http://platinum.yahoo.com
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > _____________________________________________________________________
> > GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
> > (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn�.
> > R�glement : http://www.ifrance.com/_reloc/sign.sms
> >
>
> _____________________________________________________________________
> GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
> (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn�.
> R�glement : http://www.ifrance.com/_reloc/sign.sms
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
