You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ke...@sunlife.com on 2002/04/24 14:29:07 UTC
Re: Forward after
I don't disagree with this approach.
One of the problems with using a <check-login> tag in the jsp is that the
check is postponed until you're actually in the jsp. The action servlet is
a better place to handle this kind of decision making.
By subclassing the Action servlet you ensure you have consistent processing
for all pages - which is great if this is what you want. In addition you
don't have this code then inside each action class you create - which makes
maintenance easier and less bug prone.
And having multiple action classes (e.g., SecureAction, LoggedAction to use
your examples) provides flexibility.
The only drawbacks I can see are:
- If you want different behavior for different pages you have to go back
to extending the base Action class and embed the logic in your extended
Action class (this is a problem then because the model becomes mixed - you
handle "standard" processing by extending SecureAction, and handle special
cases right in your action class). This may get confusing (i.e. bug-prone)
if you have a lot of pages.
- The permutations may get complex. What do you do if you want a Secure
and Logged action class? Have a SecureLoggedAction class too?
- You have to modify code and recompile to change the behavior - changing
a configuration would be better.
Even so, this approach seems as good as anything...
But .... I'd actually prefer to be able to modify the behavior of the base
Action.java by specifying options in the struts-config.xml. For example:
<!-- I wish I could... -->
<action path="/MySecureLoggedPath
type="com.path.to.action.AnyApplicationAction"
name="MyForm"
scope="request"
validate="false">
<logger name="myLog" type="com.path.to.logger.MyLogger.class" file="path/to/log/file.txt">
<Security name="mySecurityClass" type="com.path.to.security.MySecure.class" loginURL="http://hostname/path/to/login.jsp >
<forward name="success" path="/Success.jsp" />
</action>
In this example I've added the security and logger options. The classes specified in the security and logger lines should implement interfaces that
define the behavior.
So if I specified a security option I get <check-login> functionality. If I specify a logger, I change my logging options.
Sorry for the cross post to the dev list - I seemed to cross the boundary between responding to the question and dreaming about the future!
FWIW -
Kevin
Struts Newsgroup (@Basebeans.com) <struts on 04/23/2002 08:55:01 PM
Please respond to "Struts Users Mailing List"
<st...@jakarta.apache.org>
To: struts-user@jakarta.apache.org
cc:
Subject: Re: Forward after <check-login>
Subject: Re: Forward after <check-login>
From: "Dave Barber" <db...@solanasoft.com>
===
One thing we've done is to have our *Actions* all extend a base Action
class
(ie. SecuredAction).
SecureAction extends Action {
public ActionForward perform( ServletRequest, etc...) {
// check security, forward to login page, etc...
if (checkSecurity() ) {
return handleRequest( request, ...);
}
}
public ActionForward handleRequest( ServletRequest, etc...) {
// subclasses should override to do something....
}
}
This way, you don't have to muck around with the servlet, and you kind of
stay in the "controller" or command framework. Even better, you can
subclass from different "base" actions to get different behavior like
"Secured", "Logged", etc, actions.
--Dave
=====================================
David Barber
SolanaSoft
JForms - Rapid Struts-based Web forms development
www.solanasoft.com
=====================================
> I have some pages which require a user to be logged in
> and some which do not. If the <check-login> tag
> determines that there is no user logged in, the user
> is forwarded to the login page. I'd like to remember
> where the user came from and forward them there after
> a successful authentication. I'm sure there are
> multiple ways of doing this and I would like some
> advice. Thanks, Andrew Timm
--
To unsubscribe, e-mail: <
mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <
mailto:struts-user-help@jakarta.apache.org>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Forward after
Posted by ADH <an...@gridnode.com>.
>>"But .... I'd actually prefer to be able to modify the behavior of the
base
>>Action.java by specifying options in the struts-config.xml."
I saw something that looked like that at
http://www.livinglogic.de/Struts/description.html just recently, though I
havent had time to read through it yet so Im not sure if it will help.
(Dirk Storck posted some questions about the material at that link on the
16th to this mailing list, which is how I got the url)
-----Original Message-----
From: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
Sent: Wednesday, April 24, 2002 20:29
To: Struts Users Mailing List
Cc: struts-dev@jakarta.apache.org
Subject: Re: Forward after <check-login>
I don't disagree with this approach.
One of the problems with using a <check-login> tag in the jsp is that the
check is postponed until you're actually in the jsp. The action servlet is
a better place to handle this kind of decision making.
By subclassing the Action servlet you ensure you have consistent processing
for all pages - which is great if this is what you want. In addition you
don't have this code then inside each action class you create - which makes
maintenance easier and less bug prone.
And having multiple action classes (e.g., SecureAction, LoggedAction to use
your examples) provides flexibility.
The only drawbacks I can see are:
- If you want different behavior for different pages you have to go back
to extending the base Action class and embed the logic in your extended
Action class (this is a problem then because the model becomes mixed - you
handle "standard" processing by extending SecureAction, and handle special
cases right in your action class). This may get confusing (i.e. bug-prone)
if you have a lot of pages.
- The permutations may get complex. What do you do if you want a Secure
and Logged action class? Have a SecureLoggedAction class too?
- You have to modify code and recompile to change the behavior - changing
a configuration would be better.
Even so, this approach seems as good as anything...
But .... I'd actually prefer to be able to modify the behavior of the base
Action.java by specifying options in the struts-config.xml. For example:
<!-- I wish I could... -->
<action path="/MySecureLoggedPath
type="com.path.to.action.AnyApplicationAction"
name="MyForm"
scope="request"
validate="false">
<logger name="myLog" type="com.path.to.logger.MyLogger.class"
file="path/to/log/file.txt">
<Security name="mySecurityClass"
type="com.path.to.security.MySecure.class"
loginURL="http://hostname/path/to/login.jsp >
<forward name="success" path="/Success.jsp" />
</action>
In this example I've added the security and logger options. The classes
specified in the security and logger lines should implement interfaces that
define the behavior.
So if I specified a security option I get <check-login> functionality. If I
specify a logger, I change my logging options.
Sorry for the cross post to the dev list - I seemed to cross the boundary
between responding to the question and dreaming about the future!
FWIW -
Kevin
Struts Newsgroup (@Basebeans.com) <struts on 04/23/2002 08:55:01 PM
Please respond to "Struts Users Mailing List"
<st...@jakarta.apache.org>
To: struts-user@jakarta.apache.org
cc:
Subject: Re: Forward after <check-login>
Subject: Re: Forward after <check-login>
From: "Dave Barber" <db...@solanasoft.com>
===
One thing we've done is to have our *Actions* all extend a base Action
class
(ie. SecuredAction).
SecureAction extends Action {
public ActionForward perform( ServletRequest, etc...) {
// check security, forward to login page, etc...
if (checkSecurity() ) {
return handleRequest( request, ...);
}
}
public ActionForward handleRequest( ServletRequest, etc...) {
// subclasses should override to do something....
}
}
This way, you don't have to muck around with the servlet, and you kind of
stay in the "controller" or command framework. Even better, you can
subclass from different "base" actions to get different behavior like
"Secured", "Logged", etc, actions.
--Dave
=====================================
David Barber
SolanaSoft
JForms - Rapid Struts-based Web forms development
www.solanasoft.com
=====================================
> I have some pages which require a user to be logged in
> and some which do not. If the <check-login> tag
> determines that there is no user logged in, the user
> is forwarded to the login page. I'd like to remember
> where the user came from and forward them there after
> a successful authentication. I'm sure there are
> multiple ways of doing this and I would like some
> advice. Thanks, Andrew Timm
--
To unsubscribe, e-mail: <
mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <
mailto:struts-user-help@jakarta.apache.org>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>