You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Skip Hollowell <sk...@hotmail.com> on 2004/04/07 17:29:05 UTC
Need advice on design decisions and architecture issues.
I am not sure if this is an acceptable forum for a question like this but I
need some advice on how to proceed with a design for an application. Some
of you (Andy, Niall) have helped on a few things already regarding the
DynaValidator stuff. Let me describe the app first, and some of the things
that we are definitely doing, and then maybe you can help me fill in the
blanks.
This app will require a user to log in, and based upon who they are, they
will have certain priveleges in the system. Some of these priveleges may be
modified by a manager at anytime (user has processed their dollar limit for
the day, but needs a higher limit for whatever reason).
The interface will be Tab based, and tabs will be enabled/disabled on
per-user basis. Each tab will represent a page with a form (or several
forms) of data that display things from the database and allow the user to
update data in the database. I also believe that since this is a
customer-care application, that not more than 1 user will be working with
any given set of customer data at any 1 time.
Things I know so far. We are using Struts 1.1 as the basic framework for
the system. We are using Tiles for piecing together the parts of the
interface (tabBar, header, body, footer for each page). It has also been
suggested that we use SAIF (Interceptor Framework) to be able to process
before every action whether the user is logged in, and what they are allowed
to do. We could then also do some after-action processing as needed.
Now the questions:
1. With my tabs, I have what turns out to be at least 30 actions, and will
probable be closer to 60 when it is all said and done. So I have created
them all in the struts-config.xml as show below. But then I am going to
need form beans for each one, and a DynaValidatorActionForm for each, won't
I? The granularity of this is nice, and I like the concept of keeping
everything separated out, but is this overkill? Is there a better way to do
this kind of work? As you can see, some of this is related functionality,
but just for different types of data. Is there some way to use just 1
Action for all these forms on my app? (I would doubt it, but I want to see
what you have to say)
2. Is SAIF the best (probably not) way to go for handling users and roles.
How do you handle what a user is allowed to do and see in a struts based
application? What do I do if a user tries to hand code an URL and go to a
part of the system he is not authorized for? Right now I am looking at the
SAIF saying "not authorized" (which I already have) and then ... what?
Redirecting them to the login page I would assume (if they are not logged
in) or to the main (start) page if they are logged in.
Those are my two biggest dilemmas right now, handling the user-roles issue
and how to handle so many different forms and actions in the app. I am sure
there are others, but they escape me know that I am actually writing this
all down.
Ideas? Comments? Pointers? All are greatly appreciated.
Skip Hollowell
struts-config.xml [edited]
--------------------------
<global-forwards >
<forward name="PrepaidAccountInfo" path="/PrepaidAccountInfo.do" />
<forward name="PrepaidPlaceCall" path="/PrepaidPlaceCall.do" />
<forward name="PpiAccountInfo" path="/PpiAccountInfo.do" />
<forward name="PpiPlaceCall" path="/PpiPlaceCall.do" />
<forward name="WifiAccountInfo" path="/WifiAccountInfo.do" />
<forward name="WifiPlaceCall" path="/WifiPlaceCall.do" />
</global-forwards>
<action-mappings >
<action
path="/mainPage"
type="org.apache.struts.actions.ForwardAction"
parameter=".accountInfo.mainLayout" />
<action
path="/PrepaidAccountInfo"
type="org.apache.struts.actions.ForwardAction"
parameter=".prepaid.accountInfoLayout" />
<action
path="/PrepaidPlaceCall"
type="org.apache.struts.actions.ForwardAction"
parameter=".prepaid.placeCallLayout" />
<action
path="/PpiAccountInfo"
type="org.apache.struts.actions.ForwardAction"
parameter=".ppi.accountInfoLayout" />
<action
path="/PpiPlaceCall"
type="org.apache.struts.actions.ForwardAction"
parameter=".ppi.placeCallLayout" />
<action
path="/WifiAccountInfo"
type="org.apache.struts.actions.ForwardAction"
parameter=".wifi.accountInfoLayout" />
<action
path="/WifiPlaceCall"
type="org.apache.struts.actions.ForwardAction"
parameter=".wifi.placeCallLayout" />
</action-mappings>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Need advice on design decisions and architecture issues.
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Skip Hollowell wrote:
> This app will require a user to log in, and based upon who they are, they
> will have certain priveleges in the system. Some of these priveleges may
be
> modified by a manager at anytime (user has processed their dollar limit
for
> the day, but needs a higher limit for whatever reason).
>
> The interface will be Tab based, and tabs will be enabled/disabled on
> per-user basis. Each tab will represent a page with a form (or several
> forms) of data that display things from the database and allow the user to
> update data in the database. I also believe that since this is a
> customer-care application, that not more than 1 user will be working with
> any given set of customer data at any 1 time.
>
> Things I know so far. We are using Struts 1.1 as the basic framework for
> the system. We are using Tiles for piecing together the parts of the
> interface (tabBar, header, body, footer for each page). It has also been
> suggested that we use SAIF (Interceptor Framework) to be able to process
> before every action whether the user is logged in, and what they are
allowed
> to do. We could then also do some after-action processing as needed.
>
> Now the questions:
>
> 1. With my tabs, I have what turns out to be at least 30 actions, and will
> probable be closer to 60 when it is all said and done. So I have created
> them all in the struts-config.xml as show below. But then I am going to
> need form beans for each one, and a DynaValidatorActionForm for each,
won't
> I? The granularity of this is nice, and I like the concept of keeping
> everything separated out, but is this overkill? Is there a better way to
do
> this kind of work? As you can see, some of this is related functionality,
> but just for different types of data. Is there some way to use just 1
> Action for all these forms on my app? (I would doubt it, but I want to
see
> what you have to say)
If your system has 30 completely different forms then its not overkill to
have 30 DynaValidatorActionForm's to represent them. If though sets of forms
shared alot of common data then maybe you can define a few generic forms and
reuse them with multiple actions - for example maybe your "PpiPlaceCall" and
"WifiPlaceCall" actions have almost the same data. Are you aware of the
difference between DynaValidatorForm and DynaValidatorActionForm? Just in
case you're not - DynaValidatorForm uses the form name and
DynaValidatorActionForm uses the action path to get the validation rules
from validation.xml .
so in struts-config.xml...
<form-beans>
<form-bean name="PlaceCallForm" dynamic="true"
type="o.a.s.v.DynaValidatorActionForm">
<form-property name="phoneNumber" ....>
<form-property name="caller" ....>
<form-property name="PpiField" ....>
<form-property name="WifiField" ....>
</form-bean>
</form-beans>
<action path="/PpiPlaceCall" name="PlaceCallForm"
type="org.apache.struts.actions.ForwardAction"
parameter=".ppi.placeCallLayout" />
<action path="/WifiPlaceCall" name="PlaceCallForm"
type="org.apache.struts.actions.ForwardAction"
parameter=".wifi.placeCallLayout" />
and in validation.xml...
<form name="/PpiPlaceCall" >
<field property="phoneNumber"....>
<field property="caller"....>
<field property="PpiField"....>
</form>
<form name="/WifiPlaceCall" >
<field property="phoneNumber"....>
<field property="caller"....>
<field property="WifiField"....>
</form>
A couple of alternatives to this though:
1) LazyValidatorActionForm:
http://www.niallp.pwp.blueyonder.co.uk
2) Hubert's FormDef plugin
http://www.rabago.net/struts/formdef/
> 2. Is SAIF the best (probably not) way to go for handling users and roles.
> How do you handle what a user is allowed to do and see in a struts based
> application? What do I do if a user tries to hand code an URL and go to a
> part of the system he is not authorized for? Right now I am looking at
the
> SAIF saying "not authorized" (which I already have) and then ... what?
> Redirecting them to the login page I would assume (if they are not logged
> in) or to the main (start) page if they are logged in.
Haven't used SAIF so I can't comment on it.
We use container managed security to control access to the webapp. Within
the webapp itself we have a rolled our own security to determine whether a
use is allowed to run a particular action and/or if they are allowed access
to the data that action is trying to process. All our jsp's are located
under the WEB-INF directory so a user cannot access them directly. Different
Actions need different security checks, some actions can be run by anyone
logged on (e.g. "change password" action) some check if the user is
authorised for the Action, some check if the user is authorised for the data
and some check both Action and Data. If the user tries to run an Action or
access data they are not authorised for then they get re-directed to a "Not
Authorized" page - as they are still "logged on" within the web app they can
then carry on navigating around the system afterwards. All our Actions
derive from a "base" action, containing the security logic, and configure
themseleves on which parts of the security checking to perform. We could
have plugged some of this logic into a filter or a custom request processor
rather than deriving all actions from a "base" Action - but it works well
for us at the moment.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org