Hi Ricardo,Thanks for the bug report. This is already fixed in the next version of WO.
Item 1 can be solved easily by over riding the following method in WOContext
public String directActionURLForActionNamed(String anActionName, NSDictionary<String, ? extends Object> queryDictionary) { return this.directActionURLForActionNamed(anActionName, queryDictionary, (this.request() != null ? this.request().isSecure() : false), 0, false);
}
the current WO 5.4 wrongly uses false for the isSecure parameter. or
more easily if you don't subclass WOContext use the other API
public String directActionURLForActionNamed(String requestHandlerPath, NSDictionary<String, Object> queryDictionary, boolean isSecure, boolean entityEscapeQueryDict)
entityEscapeQueryDict should typically be false.Item 2 is govern by the previous one. If we are generating a URL and we change from unsecure to secure or vice versa we generate a full URL, otherwise we should generate relative URL.
public String _urlWithRequestHandlerKey(String requestHandlerKey, String aRequestHandlerPath, String aQueryString, boolean isSecure, int somePort) {
String url = null;
// Try to be automagically smart about when to generate
complete URLs
// If we are supposed to, or we are switching modes (http->https or
https->http) then generate a complete URL
if (_generateCompleteURLs || (_request != null && isSecure !=
_request.isSecure())) {
url = completeURLWithRequestHandlerKey(requestHandlerKey,
aRequestHandlerPath, aQueryString, isSecure, somePort);
} else {
url = relativeURLWithRequestHandlerKey(requestHandlerKey,
aRequestHandlerPath, aQueryString);
}
return url;
}
Please not that we use the request isSecure() method to check the
transition.
public boolean isSecure() {
if (_isSecure == null) {
String serverPort = headerForKey(ServerPortHeader);
if ((serverPort == null) || (serverPort.equals(""))) {
serverPort = headerForKey(ServerPortHeaderX);
}
_isSecure =
Boolean.valueOf((ServerPortSecureValue.equals(serverPort) ||
"on".equalsIgnoreCase(headerForKey("HTTPS"))));
}
return _isSecure.booleanValue();
}
I would check that the correct headers are sent to the application.
Item 3 Can you elaborate on the wrong server name? Thanks
Pierre
--
Pierre Frisch
[email protected]
On May 5, 2009, at 13:01, Ricardo J. Parada wrote:
It seems to me that there are three separate issues:1. WO generating direct action URLs with http even though the application is accessed securely via https.2. WO generating complete URLs for direct actions. 3. The generated URL having the wrong server name.I thinks #1 is a bug. See also the chart pointed to by Andrew, in particular section G, the last two rows show my scenario: the application is being accessed securely in deployment but the generated URLs have an http prefix. I have not heard by anyone whether that is a bug or not. If not a bug I would like to know why not. :-)Anyways, I filed a radar for issue #1: 6857862Secure app's directActionURLForActionNamed() generates URL with http prefixThen for #3, I think that may be an apache configuration issue on our site. I don't think it's WO's fault there. WO is simply using the server_name http header. :-) The problem is we haven't figured out why. The Apache configuration httpd.conf file has ServerName set to www.mpv.com.And #2, I don't think it's a bug, it would not be a problem if #1 and #3 are resolved.The workaround right now is to subclass WOContext and override the directActionURLForActionNamed() method.In case it helps others, so far out testing has revealed all the following things are broken in WO 5.4.3:o WOPopUpButton's noSelectionString = "" ==> Use noSelectionString = " " (space) instead o WOFrameworksBaseURL/WOApplicationBaseURL ==> Patched in application constructor o WOContext's directActionURLForActionNamed(String,NSDictionary) in production and accessed via https generates wrong URLAlso, other changes in WO 5.4.3 that I noticed (not really bug):o EOSharedEditingContext.bindObjectsWithFetchSpecification() now raises an exception if the fetch specification passed in as an argument is set up to fetch as raw rows o If using ORACLE, make sure you update your jdbc driver otherwise you may run into exceptions if you use CLOB external typeWe're almost ready to deploy our application using WO 5.4.3. Thanks all for all the help through all these issues encountered during testing and QA. I really appreciate it.:-) On May 5, 2009, at 1:09 PM, Ricardo J. Parada wrote:Thanks Susanne... That definitely sounds like the culprit.We use Apache on Solaris and there is an sslInclude.conf file but no ServerName in there. We're still checking apache configurations.I'll report back if we find out. Thanks a million, Ricardo On May 5, 2009, at 11:34 AM, Susanne Schneider wrote:Hi Ricardo,we had just a similar problem here yesterday: the culprit was the misconfigured Apache. For SSL there is a separate config file where the server name is defined. No WO magic in here, WO just picks up the entry from the header passed over by Apache.on Mac: /etc/apache/extra/httpd-ssl.conf on Linux: /etc/httpd/conf.d/ssl.conf HTH Susanne_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com This email sent to [email protected]_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/pierre%40apple.com This email sent to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
