You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Marinó A. Jónsson" <ma...@centrum.is> on 2003/07/29 22:47:59 UTC
Struts 1.1 support - bug fix and support for Struts SSL Ext
Hi guys,
I've just posted updated versions of StrutsUtils and StrutsLinkTool on the
Wiki, as well as a new tool; SecureStrutsLinkTool.
http://nagoya.apache.org/wiki/apachewiki.cgi?Velocity_Tools_For_Struts_1.1
The setForward() method in StrutsLinkTool wasn't working correctly with
modules it's now fixed.
StrutsUtils now include three new general purpose methods that are
especially useful for the SecureStrutsLinkTool:
getForwardURL() -> returns the context-relative URL that
corresponds to the specified ForwardConfig
selectModule() -> returns the ModuleConfig for a given URL path
toEncoded() -> returns URL encoded with the session id
SecureStrutsLinkTool is a substitute for StrutsLinkTool intended for those
who use the SSL Ext with Struts. Simply switch class names in toolbox.xml
and you're set.
For those not familiar with this extension, it enables you to to switch
between using the http & https protocols on a page by page basis.
It's really simple to set up:
Of course you need to have SSL set up on your webserver and a keystore
prepared.
Add the SSL Ext jar to your classpath.
Change the <action-mappings> tag in in your struts-config to be of the type
org.apache.struts.config.SecureActionConfig.
Add the org.apache.struts.action.SecurePlugIn to your struts-config. (
optionally set the httpPort and httpsPort properties for the plugin if not
default, as well as the enable property to "true|false" )
Add a <set-property property="secure" value="true|false|any"/> to the
actions you want either secure or not secure ("any" being default).
the SecureStrutsLinkTool will take care of the rest ( if you use
setAction("name_of_action") or setForward("name_of_forward") that is ).
More info here:
http://sslext.sourceforge.net <http://sslext.sourceforge.net/>
enjoy,
Marino
PS. I know the name of the tool is cumbersome I have no problem with
changing it :)
RE: Struts 1.1 support - bug fix and support for Struts SSL Ext
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
ok
changed name of SecureStrutsLinkTool to SecureLinkTool.
changed getForwardURL() in StrutsUtils to include code shared between
SecureLinkTool.setForward() and StrutsLinkTool.setForward() ... changed
SecureLinkTool and StrutsLinkTool accordingly.
deprecated getActionMappingName() in StrutsUtils.
rewrote the toEncoded method so that query data comes before the anchor ...
also moved it from StrutsUtils to SecureLinkTool (can always be moved again
in the unlikely event other tools might need a method to encode URLs with
session id's unconditionally :)
check it out,
Marino
-----Original Message-----
From: Nathan Bubna [mailto:nathan@esha.com]
Sent: 29. júlí 2003 22:49
To: Velocity Developers List
Subject: Re: Struts 1.1 support - bug fix and support for Struts SSL Ext
Marinó A. Jónsson said:
...
> Had any feedback about a view-agnostic version of RequestUtils
> from the Struts guys?
from the commit messages that have come across the struts-dev list this last
week or so, they're already working on this for 1.2! but, to be honest, it
probably won't ever completely replace StrutsUtils, though i'm happy to ship
off responsibility to them for most any part of it.
> >how is this method an improvement on HttpServletResponse's
> >encodeURL(String)
> >method (which is called as the final step in LinkTool.toString())? and
> >even
> >if it is necessary for some reason i don't know, shouldn't the query data
> >come
> >before the anchor?
>
> The difference from the HttpServletResponse counterpart is that this one
> puts the session id in unconditionally. It's use is explained in the
> SecureLinkTool where the method is called: <quote>This is a hack to help
us
> overcome the problem that some older browsers do not share sessions
between
> http & https</quote>
hmm. well, if it is a hack for dealing with https stuff, is there cause for
it to be in StrutsUtils and not just in SecureLinkTool? i.e. do you forsee
it being used in other classes?
...
> >shouldn't SecureStrutsLinkTool extend the StrutsLinkTool? there seems to
> >be
> >some code duplication there. but maybe it's necessary, i'll admit i
> >haven't
> >looked closely yet.
>
> There are only two methods in StrutsLinkTool and they both need to be
> overloaded in SecureLinkTool so I thought it unnecessary ... still -
future
> versions might share some code ... we'll see.
...
ah, ok. well, i might want to come back to this. seems to me that most of
what setForward does is repeated. maybe that can be factored into a
separate
StrutsLinkTool method or into StrutsUtils or something. i dunno. we'll
see.
:)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Struts 1.1 support - bug fix and support for Struts SSL Ext
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
...
> Had any feedback about a view-agnostic version of RequestUtils
> from the Struts guys?
from the commit messages that have come across the struts-dev list this last
week or so, they're already working on this for 1.2! but, to be honest, it
probably won't ever completely replace StrutsUtils, though i'm happy to ship
off responsibility to them for most any part of it.
> >how is this method an improvement on HttpServletResponse's
> >encodeURL(String)
> >method (which is called as the final step in LinkTool.toString())? and
> >even
> >if it is necessary for some reason i don't know, shouldn't the query data
> >come
> >before the anchor?
>
> The difference from the HttpServletResponse counterpart is that this one
> puts the session id in unconditionally. It's use is explained in the
> SecureLinkTool where the method is called: <quote>This is a hack to help us
> overcome the problem that some older browsers do not share sessions between
> http & https</quote>
hmm. well, if it is a hack for dealing with https stuff, is there cause for
it to be in StrutsUtils and not just in SecureLinkTool? i.e. do you forsee
it being used in other classes?
...
> >shouldn't SecureStrutsLinkTool extend the StrutsLinkTool? there seems to
> >be
> >some code duplication there. but maybe it's necessary, i'll admit i
> >haven't
> >looked closely yet.
>
> There are only two methods in StrutsLinkTool and they both need to be
> overloaded in SecureLinkTool so I thought it unnecessary ... still - future
> versions might share some code ... we'll see.
...
ah, ok. well, i might want to come back to this. seems to me that most of
what setForward does is repeated. maybe that can be factored into a separate
StrutsLinkTool method or into StrutsUtils or something. i dunno. we'll see.
:)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Struts 1.1 support - bug fix and support for Struts SSL Ext
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Nathan said:
>since it is our aim that StrutsUtils become obsolete in the future
>(replaced
>by view-agnostic improvements in Struts' own RequestUtils, as mentioned in
>the
>javadoc for the class), i think it would be best if we avoided adding
>methods
>such as this which *only* delegate to a matching method in RequestUtils
>(Struts 1.1 version of course). since we want to move to RequestUtils
>anyway,
> why not start moving what we can now? :)
I totally agree ... I only did it this way in case you had something against
referencing RequestUtils directly in the tools :P Guess I was wrong :) Had
any feedback about a view-agnostic version of RequestUtils from the Struts
guys?
>how is this method an improvement on HttpServletResponse's
>encodeURL(String)
>method (which is called as the final step in LinkTool.toString())? and
>even
>if it is necessary for some reason i don't know, shouldn't the query data
>come
>before the anchor?
The difference from the HttpServletResponse counterpart is that this one
puts the session id in unconditionally. It's use is explained in the
SecureLinkTool where the method is called: <quote>This is a hack to help us
overcome the problem that some older browsers do not share sessions between
http & https</quote>
Yes, I think the query data should come before the anchor - the code is
extracted from the SSL Ext lib - I'll fix it :)
>shouldn't SecureStrutsLinkTool extend the StrutsLinkTool? there seems to
>be
>some code duplication there. but maybe it's necessary, i'll admit i
>haven't
>looked closely yet.
There are only two methods in StrutsLinkTool and they both need to be
overloaded in SecureLinkTool so I thought it unnecessary ... still - future
versions might share some code ... we'll see.
>i think org.apache.velocity.tools.struts.SecureLinkTool would be
>sufficient.
cool thanks.
Marino
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Struts 1.1 support - bug fix and support for Struts SSL Ext
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
...
> I've just posted updated versions of StrutsUtils and StrutsLinkTool
> on the Wiki, as well as a new tool; SecureStrutsLinkTool.
...
> The setForward() method in StrutsLinkTool wasn't working correctly
> with modules - it's now fixed.
thanks! i'll try and test this and check it in soon.
> StrutsUtils now include three new general purpose methods that are
> especially useful for the SecureStrutsLinkTool:
>
> getForwardURL() -> returns the context-relative URL that
> corresponds to the specified ForwardConfig
since it is our aim that StrutsUtils become obsolete in the future (replaced
by view-agnostic improvements in Struts' own RequestUtils, as mentioned in the
javadoc for the class), i think it would be best if we avoided adding methods
such as this which *only* delegate to a matching method in RequestUtils
(Struts 1.1 version of course). since we want to move to RequestUtils anyway,
why not start moving what we can now? :)
> selectModule() -> returns the ModuleConfig for a given URL path
> toEncoded() -> returns URL encoded with the session id
how is this method an improvement on HttpServletResponse's encodeURL(String)
method (which is called as the final step in LinkTool.toString())? and even
if it is necessary for some reason i don't know, shouldn't the query data come
before the anchor?
> SecureStrutsLinkTool is a substitute for StrutsLinkTool intended for
> those who use the SSL Ext with Struts. Simply switch class names
> in toolbox.xml and you're set.
shouldn't SecureStrutsLinkTool extend the StrutsLinkTool? there seems to be
some code duplication there. but maybe it's necessary, i'll admit i haven't
looked closely yet.
...
> PS. I know the name of the tool is cumbersome - I have no problem
> with changing it :)
i think org.apache.velocity.tools.struts.SecureLinkTool would be sufficient.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org