You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Chris Audley <CA...@urbanfetch.com> on 2000/06/27 01:05:55 UTC

SSL with Struts: Proposed changes

I'm using struts for a project which will ultimately be deployed on the
public internet. As such, handling certain pages through a secure connection
will be mandatory.  Therefore, I'd like to propose the following set of
changes to the ActionForward and ActionServlet classes to support SSL.

The core change I've made is adding an attribute to the ActionForward class,
secure, which indicates whether or not the target of the forward should be
accessed in a secure manner ( SSL ).  When performing a forward, the secure
flag is checked to determine whether the scheme of the request needs to be
changed.  If the request is secure but the forward is not, the forward
redirects to the target path using http:, if the request is not secure, but
the forward is, the forward redirects using https:.  If the secure flag on
the request and the forward match, nothing  special needs to be done.

A wrinkle in this procedure is caused by the current treatment of the path
by the forward object. Whether the path is absolute or not is infered by the
state of the redirect attribute.  The problem is -- with my changes -- the
redirect flag is no longer the final word in whether or not the forward will
redirect or not.  ( As a side note: a pedantic reading of the definition of
the redirect attributes comment "Should this be a redirect instead of a
forward?" never guarantees a forward instead of a redirect, so I'm not
actually changing the "spec" ;-)  I've never been a fan of implied
attributes anyway, I think ambiguity is a "bad thing", so I've added an
explicit pathAbsolute attribute to the forward which defaults to false.
This, of course, will break existing code.   I know that there is a general
desire to avoid doing this, but we are at a pre release-1.0 stage, and SSL
support is important for a large class of users.  Further, allowing the
servlet to explicitly flag absolute paths will be generally usefull ( more
on this later ).

Another change I've made is to add a perform method on the ActionForward
object and call this from the performActionInstance code in ActionServlet.
In my interpretation of good OO principals, any non-trivial code which
depend on the state of an object should be a method of that object.  With my
changes, executing a forward in moving into the realm of non-trivial.

The big issue I haven't figured out is what to do when HTTPS isn't available
or when the server is not running on the standard ports.  Somehow, the code
needs to know about this, and this kind of information isn't within the
scope of the Servlet API's.  The code as I've written it assumes that SSL is
present if you've set forwards to secure and the server is using ports
80/443.  The only solution I can think of is to add the information as
parameters to the servlet.  I'd like to here any ideas on solving this.  As
currently written, my changes wont break anything as long as you don't use
the secure attribute.

Even though this proposal isn't complete, I'd like to request that at the
very least the pathAbsolute changes to the forward object be adopted.  This
generally improves the struts packages.  For instance, what if I want to
specify that a forward is done via redirect, but for portability of the
servlet, I don't want to hardcode a path within the servlet in the
action.xml file.  I've run into this problem independant of my SSL changes
while implementing a login/logout process.  Basically, I'd like to use
client redirect to clean up the URL in the browser, but I have to specify a
full path name in my action.xml or create ActionForward objects on the fly.
I'd rather not have to do either.

Thanks
Chris

 <<ActionForward.java>>  <<ActionServlet.java>>