Updated October 3,
2004  Please read this entire page.
        Released new version
"sslext for Struts 1.2, Release 0"
First release for Struts 1.2 is now available. Release 0 is a 1.2 baseline version that includes only
updates for Struts 1.2 compatibility (e.g. new link tag "module" attribute).
This release does not yet support char encoding attribute for link & rewrite tags.
Have also eliminated all references to the obsolete "subapp" terminology in favor of "module".
This release also places a copy of the sslext.tld file into the meta-inf/tlds directory inside the sslext.jar
file for JSP 1.1/1.2 programming convenience.
Subsequent releases (Release 1, Release 2, etc.) will include features submitted and/or requested by Maciej Miechowicz
and Dennis Muhlestein.  If you have a feature to submit, please feel free to do so by sending me email.
Special thanks to Dennis Muhlestein for assistance and suggestions for this release.
        (12/31/2003)
Released updated version
"sslext for Struts 1.10 - 4"
Added SecurePlugInInterface and SecureTilesPlugin along with the necessary changes to
other classes to utilize these.  This fixes a reported problem with using sslext in combination with Tiles.
When using sslext with Tiles, specify the SecureTilesPlugin (org.apache.struts.tiles.SecureTilesPlugIn)
and the SecureTilesRequestProcessor (org.apache.struts.action.SecureTilesRequestProcessor).
These changes are based on source code posted by Kim Turner referenced in the discussion forums on this site.
Special thanks to Kim Turner for her contribution.
 
        
        Also added is the ability to configure the "always add Session ID to URL feature".  This feature was
        added in a previous release to compensate for older browsers that do not automatically share sessions
        between the http and https protocols.  If you are sure that this problem will not exist for you, you can now
        disable this feature through the "addSession" property of the SecurePlugIn (or SecureTilesPlugin).  Thanks to all
        who suggested this enhancement. (Or otherwise complained about the old behavior :-).
 
        
        (9/8/2003)
Released updated version
"sslext for Struts 1.10 - 3"
Fixed bug that could result in exception if mapping cannot be found for a
requested action.  
        
        (9/5/2003)
Released updated version "sslext for Struts 1.10 - 2"
 New feature - recognizes multiple mappings for the Struts action servlet,
including the mixing of prefix and suffix mapping.  For example, you
can map *.do, *.foo, AND /do/* to the Struts action servlet.  Sslext
will recognize the mapping and create the link tag, form tag, etc. with the
appropriate specified protocol.
        (7/19/2003)
 Struts 1.10 final version  released.  New features (originally added
in RC2, but not announced here):
        "secure" property for
 actions in struts config file now accepts values "true", "false" AND "any". 
 A value of "any" means that the action will accept http or https protocol,
 whichever is current.
          
          "secure" property
 for pageScheme tag now accepts values "true", "false" AND "any".  A
value of "any" means that the action will accept http or https protocol, whichever
is current.
        Also,  bug fixed:
          Added "action"
attribute  to the TLD for link tag
          
          
        New Struts 1.1 Beta3
 version released.  New "enable/disable" feature available in 1.1 Beta3
 version. (1/27/2003)
           Bug-Fixed versions
 of 1.0, 1.1Beta1, and 1.1Beta2 versions released (1/27/2003)
        Servlet 2.2 compliance
 enforced, now compatible for both Servlet 2.2 and 2.3 (10/30/2002)
          
        Struts-folk, please read: 
         In the course of our
 work, we have had numerous projects where          it was necessary to switch
 between using the http & https protocols        on  a page by page basis.
  We had a solution which we used in a traditional        MVC  framework with
 servlets and JSP. We have since switched over to   using     Struts  in
all  of our projects.  Reworking our solution within  Struts has    improved
 our solution dramatically. 
         We had noticed that
 other Struts users had been asking about enabling this type of protocol switching.
  We thought that you might find enough value in what we have done to include
 our solution as an extension to Struts. 
         The following describes
 what we have done: 
         We added a "secure"
 property to the action tag in the struts-config.xml          file.  A value
 of true for this property will specify that the request       to   the action
 should be transmitted via SSL (https).  We defined a  class     SecureActionMapping
   (SecureActionConfig for Struts 1.1) that extends  the   ActionMapping class
  and includes the new "secure" property.         
        In the Struts 1.0 version,
 we added two more initialization parameters          for SecureActionServlet
 (our extension to ActionServlet).  These parameters,         http-port and
 https-port, specify the ports being used by the web application        for
 http and https protocols.  These default to 80 & 443, respectively.
       For Struts 1.1, there is no SecureActionServlet.  This initialization
        is handled as a Plugin. 
        Also in the Struts 1.0
 version, we added code to SecureActionServlet          which will redirect
 the action if the protocol in the request (http    or   https)   for some
 reason does not match that specified by the value   of the   "secure"   property.
  The redirect URL will include the correct  protocol  and port number.
   One possible reason for the protocols not matching would   be the manual
  entry of a URL into a browser client with the wrong protocol   specified.
  In   the Struts 1.1 version, this is handled by SecureRequestProcessor,
    which  is our extension of the default RequestProcessor class. 
       
         We created SecureLinkTag
 as an extension to LinkTag .  The added          capability to this tag is
 that it checks the action mappings for the    "secure"     property of actions
 that are specified in the link.  If the   secure property     is true and
 the current page was transmitted using http,   the SecureLinkTag     creates
 a link specifying the https protocol  and https   port for the web   application.
   Similarly, for pages transmitted  using  https that have http   links,
the http  protocol and port will be generated  by the link tag.  If   the
protocol for  the current page matches that of  the link specified, a  relative
link is created  in the page.   For good measure, we also added a SecureWriteTag,
 which behaves  similarly.  We have extended FormTag with SecureFormTag in
 the same way.  Other tags which could have similar changes change are ImageTag
 and ImgTag.   (I promise we will get to these eventually.)
        
         We created a new tag
 which we call PageSchemeTag.  This allows          developers to specify
transmission protocol at the page level.  While      good    design would
seem to require switching protocols only at the action     level,    this
tag comes in handy for pages like the login page, especially     using  container
 managed security.  As with the actions, this tag will   cause  a redirect
if  the request protocol does not match the protocol specified     by the
secure attribute.         
         We also added some
utility methods in our SecureRequestUtils          class. 
         Also included in each
 version is a small demo application of the extension: 
          
      NullAction is the action class that is used in the definition     of
 all   four  actions in the struts-config.xml file.  It places a string
  in  the request   to be forwarded and displayed in a JSP.  The other four
 actions      are:                  
          
      true - an action with the "secure" attribute set to TRUE   which
 forwards      to true.jsp, a page which does not specify a security   parameter.
           
          
      false- an action with the "secure" attribute set to FALSE   which
  forwards     to false.jsp, a page which does not specify a security   parameter.
           
          truetag - an action with
 the "secure" attribute set to  FALSE    which    forwards   to truetag.jsp,
 a page which includes the pageScheme    tag to specify   a "secure"   attribute
 of TRUE. 
          
      falsetag - an action with the "secure" attribute set to  TRUE   which
   forwards   to falsetag.jsp,  a page which includes the pageScheme     tag
to   specify a "secure"  attribute of FALSE.
          
          
                            There
 are also a pair (1 specifying secure as TRUE and one as FALSE) of  form
 submit    actions.
          
        The Struts 1.1 version
 of the extension includes a main application          and a subapp, each
with these same actions outlined above along with  these two additional
actions:
          
      any- an action with the "secure" attribute set to ANY which    forwards
     to any.jsp, a page which does not specify a security   parameter.
        
           anytag - an action with
 the "secure" attribute set to  ANY which    forwards   to falsetag.jsp,
 a page which includes the pageScheme     tag to   specify a "secure"  attribute
 of ANY.
          
          
          Each JSP includes links
 to the other actions.  The SecureLinkTag          is used to create these
 links.  Note that the URL generated for each     of   these  links will include
 any change of protocol and port that is  required.
        
         We offer this to developers
 as an extension to Struts, but think          that ideally our solution would
 be incorporated into the Struts core.              
         Please give it a try
 and let us know what you think.  Download  the distribution.  Look
 at the example apps, especially the    config    files. 
         A caveat: When a redirect
 takes place,         request attributes  are  temporarily       stored in
 the session.  If you are working in a clustered           environment,
    this means that your request attributes must be  serializable.  (Note
 that the "automatic redirect"   feature cacn be turned off in the Struts
1.10 version.  This feature should  only be needed when a user directly
      enters a URL using the wrong protocol.   Non-secure access to
secure      pages can and should also be blocked through the web container.
 )  
         Please feel free to
 ask us any questions or give us any comments          or suggestions that
 you may have about this solution. 
         Note: We can't redistribute
 jsse.jar, jnet.jar or jcert.jar,          so you'll have to get your own
from Sun at the 
                JSSE 1.0.2
                       page. 
         Also: If you are
 using Tomcat, please follow the directions          on the         
                              Tomcat SSL
                      page to set up SSL for Tomcat.