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>
