Zipping up text files is a pretty common custom on jakarta lists... tomK
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: vrijdag 25 januari 2002 9:57 > To: [EMAIL PROTECTED] > Subject: RE: Proposed solution for HTTP vs. HTTPS > > > Please don't send binary files to the list. It gets me into > lots of trouble > with our mail gateway people > > > -----Original Message----- > > From: Ditlinger, Steve [mailto:[EMAIL PROTECTED]] > > Sent: 24 January 2002 17:34 > > To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > > Subject: RE: Proposed solution for HTTP vs. HTTPS > > > > > > > > > > > Struts-folk: > > > > > > Please see the attached file as a demonstration of our > > > proposed extensions for Struts. > > > > > > 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 that extends the > > ActionMapping class > > > and includes the new "secure" property. > > > > > > 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. > > > > > > 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. > > > > > > We created SecureLinkTag as an extension to LinkTag to > > > prevent unncessary round trips and provide greater > security to data > > > transmission. 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. > > The FormTag > > > should also be changed in the same way. Other tags which > could have > > > similar changes change are ImageTag and ImgTag. > > > > > > 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 a bunch of utility methods in our > > > SecureRequestUtils class that is an extension of the > > RequestUtils class. > > > > > > Also included is a small demo application of > > the extensions > > > we have made for use with Tomcat : > > > 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 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. > > > > > > Each JSP includes links to the 3 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 > > ActionServlet, > > > ActionMapping, LinkTag, etc. > > > > > > Please give it a try and let us know what you think. We > > > will post again once we have added our extension to FormTag. > > > > > > Please feel free to ask us any questions or give us any > > > comments or suggestions that you may have about this solution. > > > > > > > > > Sincerely, > > > > > > Max Cooper > > > Steve Ditlinger > > > Prakash Malani > > > Danny Trieu > > > > > > eBuilt, Inc. > > > Irvine, CA > > > > > > <<sslext.jar>> > > > > > > > > > > Internet communications are not secure and therefore the > Barclays Group > does not accept legal responsibility for the contents of this message. > Although the Barclays Group operates anti-virus programmes, > it does not > accept responsibility for any damage whatsoever that is caused by > viruses being passed. Any views or opinions presented are > solely those > of the author and do not necessarily represent those of the Barclays > Group. Replies to this email may be monitored by the Barclays Group > for operational or business reasons. > > > -- > To unsubscribe, e-mail: > <mailto:struts-user-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
