You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Ditlinger, Steve" <SD...@ebuilt.com> on 2003/03/17 20:09:03 UTC

New releases of sslext posted

All:
 
New versions of sslext, the Struts extension for http/https switching, have
been posted at http://sslext.sourceforge.net.  
 
One new posting is a bug-fixed version for Struts 1.1b3.  The bug that was
fixed is described below in an email from last week by Dennis Muhlestein.
 
The other new posting is a new posting for Struts 1.1RC1.
 
Both reflect some refactoring that simplifies the code.  As a
consequence, the ability to specify links including "../" or submodule paths
has been eliminated.  This is consistent with core Struts.  The same
capability
is available by using the "forward" attribute of sslext:link.  See example
app.
 
The versions for Struts 1.1b1 and Struts 1.1b2 are no longer supported and
will soon be withdrawn from their posting.  For now, they remain posted for
comparison purposes.

Additional note: One more thing, both new releases also include an
additional
version of the SecureRequestProcessor called SecureTilesRequestProcessor
for use with Tiles.
 
Thanks,
Steve
 
 
 
> 
> 
> 
> 
> --- Dennis Muhlestein <de...@zserve.com> wrote:
> > sslext does not function as expected with modules.
> > 
> > Specifically, when operating withing a module (ie: subappfoo), the
> > <sslext:link page="/somepage.do"....> does not find the ModuleConfig for
> > the subapplication.  Instead, it finds the ModuleConfig for the root
> > module.
> > 
> > The reason the example applications in sslext works correctly with
> > subappfoo is that the main module and the subappfoo module have the
> > exact same action mappings and secure properties.  Therefore, when you
> > request the true or false page from the subapp, you get a ModuleConfig
> > and SecureActionConfig from the root module that look identical to what
> > you expect to get from the subappfoo module.
> > 
> > To demonstrate the bug, change the struts-config-subapp.xml's /true
> > secure property to be false.  After this change, you should see neither
> > page going to https.  You will see however, that the true page still
> > goes to https (when you are within subappfoo).  This is because the
> > secure config used by sslext:link came from the root module.
> > 
> > Now go to the root module's index file.  You'll see that the links to
> > the true/false pages for the subapp are now correct (neither goes to
> > https).  This is because when you specify the module prefex (ie:
> > page="/subappfoo/true.do" ) in the sslext:link tags forward,href, or
> > page attribute, the sub application's correct ModuleConfig is found.
> > 
> > You can further see that this doesn't function properly by deploying a
> > sub application that does not have the same action mappings as the root
> > application.  Then, sslext:link will not find the action requested in
> > the tag, it won't get a ModuleConfig, and it won't be able to tell
> > whether or not your action is supposed to be secure.  The links will
> > never change between https and http.  They stay on the protocol made by
> > the request that generates the page.
> > 
> > The workaround for right now, is to use the href attribute instead of
> > the page attribute on the sslext:link tag and specify the entire url
> > relative to the root module (ie: href="/myModule/myPage.do" ).
> > 
> > If you have any questions or would like more details let me know.
> > 
> > Thanks
> > Dennis
> > 

 


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org