on 11/5/02 7:00 PM, Ditlinger, Steve at [EMAIL PROTECTED] wrote:
As for specifying a forward to be secure or non-secure: changing the
protocol requires a redirect, so every forward where the protocol changes
would require a redirect, which would be OK assuming the developer
recognizes that going in. I think you can accomplish the same thing right
now by using the sslext:pageScheme tag.
Well, what's important is to reduce the number of different places where
something is specified (anything, but in this case, the desired scheme,
http/https).
One of my main desires in the sslext:link tag is to be able to use them
throughout my JSPs without worrying about what the resource is (or might be
in the future), and without worrying about the hostname.
If the tag handler could look up in some file, preferrably the struts-config
file, what the resource needs are (http vs. https), then it could render an
appropriate tag for what the current request's scheme is.
Since there's no way to ask a JSP directly (I have a thought on this, below)
for parameters, it *could* be done as part of the global forwards tags in
the struts-config file. However, I think the DTD would have to be modified,
either to include a parameter in the tag, or to allow something like this:
forward name=mySecurePage path=login.jsp
set-property property=secure value=true/
/forward
Because the security of a page is so important and pervasive, I think all of
this stuff should be incorporated into Struts, rather than being an
extension, and I'd prefer to see secure added as a property to the tags:
forward name=mySecurePage path=login.jsp secure=true/
Alternatively, a separate set of tags could be added:
secure-resources
resource path=page-one.jsp /
resource path=action-one / // an action: action-one.do, let's say
resource path=page-two.jsp /
/secure-resources
In all cases, the sslext:link tag could consult this data to render the
appropriate URL. This way, if the page ever changes, it would not be
necessary to change every reference to it.
Furthermore, a global SSL switch could be employed, allowing one to turn off
SSL for testing and development purposes (when the certs are self-signed,
you get all sorts of warnings, or when you're having trouble getting the SSL
transport set up, as I did).
Regarding putting the information in the JSP: It should be possible to
create a static method or variable in a JSP that can be queried by any other
Java running in the same container. Unfortunately, I don't think this can be
done in a container-independent manner. I don't know if the Servlet Spec
provides for a programmatic way to find the class compiled out of a JSP. I
know that Tomcat munges the .jsp filename into something resembling it, and
so it should be possible to put into a JSP a very small bit of code or data
(unfortunately, I don't think it can be done with a tag, but maybe; can a
tag create a static method in the JSP?) that can be queried by things like
the sslext:link tag.
Anyway, those are my thoughts. What we really need is an HTTP 1.2 (or 2.0)
protocol that knows how to query the server first to see if a requested
resource needs to be requested securely, along with underlying changes to
support state. But that's a much longer discussion!
Thanks for your reply!
--
Rick
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
