On 2/8/12 12:32 PM, Jon Kleiser wrote:
On 2/8/12 5:53 AM, Klaus Berkling wrote:
On Feb 7, 2012, at 7:42 AM, Jon Kleiser wrote:
This is roughly how we handles the logout (simplified):
public WOComponent logout() {
WORedirect redirect = new WORedirect(context());
loginUrl =
context().directActionURLForActionNamed("default", null);
redirect.setUrl(loginUrl);
// ... calling session logout method
return redirect;
}
Is this problem familiar to anyone out there?
Yup. Try:
.directActionURLForActionNamed(String requestHandlerPath,
NSDictionary queryDictionary, boolean isSecure, boolean
entityEscapeQueryDict)
context().directActionURLForActionNamed("default", null, useSSL, true);
I'll have to try Chuck's suggestion though.
kib
"The
trouble with normal is
it always gets worse."
Bruce
Cockburn
Klaus Berkling
Web Application Dev. & Systems Analyst
DynEd International, Inc.
www.dyned.com
Hi Klaus,
I wanted to try your way of calling directActionURLForActionNamed,
and it seemed to work on my WOLips-based Mac, but when I tried to
build on our Linux server, I got
"directActionURLForActionNamed(java.lang.String,com.webobjects.foundation.NSDictionary)
in com.webobjects.appserver.WOContext cannot be applied to
(java.lang.String,<nulltype>,boolean,boolean)". It seems we
have a slightly older WO version there. My WO 5.2.4 docs doesn't
mention your alternative either. Do you know in which WO version
this was introduced? And do you know where I can find up-to-date
docs for WOContext on the net?
/Jon
Hi again,
My first thought was that we should upgrade the WO on our dev.
server (Linux) to support the modern version of
'directActionURLForActionNamed', but that would of course require
all the other test and prod servers (run by other institutions) to
be checked and possibly upgraded. So I went for a simpler solution:
We have a utility method 'getSchemeAndHostForApplication' which in
our case returns "https://ourhost.no". So, if that scheme is https,
and the loginUrl I get from 'directActionURLForActionNamed' starts
with "http:", the I do this quick-and-dirty replacement:
loginUrl = loginUrl.replaceFirst("http://[\\w\\-\\.]+:?\\d*",
schemeAndHost);
In the regex I assume that the host part is a mix of word chars,
hyphens and dots, possibly followed by a :port. That may not cover
all possible host names out there, but for us it seems to work.
Why this problem turned up now, is still unclear to me. If I knew,
maybe it could have been solved on the server and not in our
application.
Thanks for all the input.
/Jon
|