Re: Re: SSLExt and Struts Workflow?
Tim: Without looking into it too deeply (and without knowing anything about Workflow), I can say the easiest thing from the sslext side is to redefine SecureActionConfig to extend WorkflowMapping, just as you say. If you have problems, I can look at it more. Steve From: Tim Shadel [EMAIL PROTECTED] Date: 2003/10/16 Thu PM 01:52:22 CDT To: Struts Users Mailing List [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: SSLExt and Struts Workflow? I know this thread is a couple weeks old, but I just started looking into this myself. Actually, I don't think that they are currently compatible, but not because of the RequestProcessor. Matthias has made it easier to write a RequestProcessor that includes others, so that should be possible (though I haven't done it). The problem seems to be that they each require a custom ActionMappings class: action-mappings type=org.apache.struts.config.SecureActionConfig action-mappings type=com.livinglogic.struts.workflow.WorkflowMapping I assume that you can't use both. After looking at the code, it appears that it may not be hard to change SSLExt to expect an Interface instead of a class in most areas that the SecureActionConfig is really needed for the config.getSecure() call (WorkflowMapping seems to hold more than simple get/set methods). It seems that the changes to SecureActionConfig are most in the checkSsl() and computerUrl() methods. I may be missing something, but it doesn't seem like much would break. Eclpse's Extract Interface... refactoring can't do it automatically, but gives a quick glance at the areas most affected. If the SslExt code could use an interface, then it would be possible to extend the WorkflowMapping, add the needed methods, use the new class in the action-mapping and then use both SslExt and Struts Workflow together. Steve and Matthias, do you see any glitches with this approach? If not, I may try to start working at it (isn't that the general rule - don't propose something unless you want to volunteer to help? :-D). Thanks for your great extentions to Struts! Tim Matthias Bauer wrote: If you still want to use the sslext RequestProcessor you should be easily able to do that: It is fairly trivial to build an SSLExtWorkflowRequestProcessor in just the same way as the TilesWorkflowRequestProcesser is built, which is included in the Struts Workflow Extension. This is because all the workflow logic is extracted into a separate class WorkflowRequestProcessorLogic. If you are interested, have a look at the classes WorkflowRequestProcessor, TilesWorkflowRequestProcessor, WorkflowRequestProcessorLogic and WorkflowRequestProcessorLogicAdapter. --- Matthias Steve Ditlinger wrote: I'll admit to not having used Struts Workflow. But I don't know of any reason why sslext should not work, as long as actions are defined in a struts config file like other struts apps. If Struts Workflow uses its own RequestProcessor, you would not be able to use the sslext RequestProcessor (without creating your own custom RequestProcessor). However, that is OK. You can use the sslext Plugin without the sslext RequestProcessor. Assuming the use of the sslext tags, the sslext RequestProcessor is really only needed as a failsafe for redirecting to the correct protocol if a URL is improperly hand-entered. HTH, Steve - Original Message - From: Mick Knutson [EMAIL PROTECTED] To: struts [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 2:54 PM Subject: SSLExt and Struts Workflow? Does SSLExt and Struts Workflow work together? --- Thanks Mick Knutson http://www.baselogic.com --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /div - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSLExt and Struts Workflow?
I'll admit to not having used Struts Workflow. But I don't know of any reason why sslext should not work, as long as actions are defined in a struts config file like other struts apps. If Struts Workflow uses its own RequestProcessor, you would not be able to use the sslext RequestProcessor (without creating your own custom RequestProcessor). However, that is OK. You can use the sslext Plugin without the sslext RequestProcessor. Assuming the use of the sslext tags, the sslext RequestProcessor is really only needed as a failsafe for redirecting to the correct protocol if a URL is improperly hand-entered. HTH, Steve - Original Message - From: Mick Knutson [EMAIL PROTECTED] To: struts [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 2:54 PM Subject: SSLExt and Struts Workflow? Does SSLExt and Struts Workflow work together? --- Thanks Mick Knutson http://www.baselogic.com --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: InvalidClassException....
This sounds like you need to make sure that each server/node in the cluster has the same version of the class. The failover node is trying to deserialize a class that was serialized on the original node as a different version of the same class. Steve - Original Message - From: Trieu, Danny [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 10:48 AM Subject: InvalidClassException Hi All, I have an ActionForm that has a FormFile attribute used for fileupload. I had the attribute marked as transient so that the ActionForm can be serializable and replicate in a cluster environment. However, the out come is not what I am expected, it throws InvalidClassException. Does anyone know what happens or how to fix this? Thanks, --danny This message and any attachments are for the intended recipient(s) only and may contain privileged, confidential and/or proprietary information about Downey Savings or its customers, which Downey Savings does not intend to disclose to the public. If you received this message by mistake, please notify the sender by reply e-mail and delete the message and attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] new version of sslext for Struts 1.10 posted
Minor change to fix a bug in previously-posted version that could result in exceptions if the action specified in the sslext:link or sslext:form tags could not be found. sslext for Struts 1.10 - 3 is the latest version, available at http://sslext.sourceforge.net. I will be deprecating previous Struts 1.10 release. STeve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sslext can only get it to post
Yes, Tomcat's handling of the security-constraint is very complementary to the use of sslext. Unfortunately, unless this has changed recently, not all containers behave in this way. Weblogic, for instance, just creates a response that outputs a message to the browser stating that a particular URL is available only by HTTPS. (Maybe this has changed in 8.1, I'll check it out.) Tomcat definitely has the superior implementation on this issue. Steve - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Cc: Stephane Grenier [EMAIL PROTECTED] Sent: Monday, September 15, 2003 10:37 AM Subject: Re: sslext can only get it to post On Sun, 14 Sep 2003, Max Cooper wrote: Some design changes are needed to make the switch to the https port in what I consider to be an acceptable manner. One avenue to explore is using one particular capability of container managed security, and declare a security constraint requiring SSL on a particular request. Something like this: security-constraint web-resource-collection web-resource-nameCheckout Section/web-resource-name description The set of URL patterns for requests that must be submitted via SSL. In order to avoid sending confidential data unencrypted, these patterns MUST include the page that renders the form to be submitted that contains that confidential data. /description !-- URL pattern for the form containing the credit card number -- url-pattern/checkout_form.jsp/url-pattern !-- URL pattern for the buy it submit button -- url-pattern/buy.do/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint If you do this, the container will switch to HTTPS for you before the checkout form is rendered. Hence, the ultimate submit of that form will be done over SSL. It's up to the container to figure out what the correct SSL port number is (in Tomcat, you configure this with the redirectPort attribute on a Connector element; the default configuration for non-SSL on port 8080 redirects to SSL on port 8443). Note that, because there is no auth-constraint here, this particular security constraint does not require you to use container managed security for authentication -- it's only being used to do the redirect to SSL trick for you. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Implementing HTTPS in Struts
Robert, All: We have added SecureFormTag as an extension to FormTag for our implementation of HTTPS/HTTP web application switching. SecureFormTag will determine if the action specified as the action attribute value should be called using SSL or not. The HTML form element it creates will then include an action specifying the appropriate protocol (http or https) if that protocol does not match the current protocol. This is similar to the SecureLinkTag extension we had done earlier. Please try it out and let us know what you think. You can download it at http://struts.ditlinger.com. Thanks, Steve __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
