I found a solution and it's not bad at all. This works specifically
with WebLogic and the HTTP WebLogic Plugin, so anyone using that setup
should benefit from this:
1. I created a subclass of
org.apache.wicket.protocol.http.servlet.ServletWebRequest to override
getContextPath():
@Override
public String getContextPath()
{
String webLogicPrepend = getHeader("WL-PATH-PREPEND");
String contextPath = super.getContextPath();
if (StringUtils.equals(webLogicPrepend, contextPath))
return StringUtils.EMPTY;
else
return contextPath;
}
The WebLogic HTTP plugin sends a header called WL-PATH-PREPEND which is
part of the Apache configuration (see
http://docs.oracle.com/cd/E13222_01/wls/docs81/plugins/apache.html). I
simply check to see if this header was sent and if it matches the one
from the servlet. If that's the case, I send an empty string back so it
doesn't get added.
2. Override newWebRequest in the WebApplication to use the
ServletWebRequest subclass:
@Override
public WebRequest newWebRequest(HttpServletRequest servletRequest,
String filterPath)
{
return new ApiServletWebRequest(servletRequest, filterPath);
}
So far in my testing, I haven't had any of the problems I had before.
This solution may also work with mod_proxy, but I'm not sure if there
are headers sent in that situation.
I created a bug (https://issues.apache.org/jira/browse/WICKET-5000)
which could possibly be closed now that I've found this work around.
Tim
On 1/22/13 12:32 PM, Tim Urberg wrote:
First the good news, I was able to get it to work by deploying the
application in the root context. Once I did that, everything worked
the way it should, paged switched from http to https with no problem.
The bad news is that deploying it as / not an option. I've tried
overriding createRedirectUrl to strip out the context in the url in
HttpsMapper, but that only works part of the time. For example, when
I put the @RequireHttps annotation on a page, and have logged in, when
I click a link to it /documentation is added to the URL, which tells
me it's more of a problem than just HttpsMapper. Perhaps it's a
problem with the delegate mapper as well. The fact that it works
correctly when deployed as the root context tells me there's got to be
a better way to fix it. Anyway, I was wondering if anyone had any
ideas as to where to start looking. It would be nice if there was a
way to tell the wicket application that "even though I'm deployed at
'/myapp', I'm actually behind a proxy and my context is '/'" That
would really solve the problem.
I was thinking of creating a JIRA ticket or feature request for this.
Any thoughts?
Tim
On 1/17/13 3:04 PM, Tim Urberg wrote:
Ok, I'm making *some* progress (if you can call it that). First of
all, here's more about my setup. I'm using wicket-auth-roles for
authentication and I have this set up in my WebApplication.class
based on an example I found in wicket examples:
1) the authorization strategy
getSecuritySettings().setAuthorizationStrategy(new
IAuthorizationStrategy()
{
@Override
public <T extends IRequestableComponent> boolean
isInstantiationAuthorized(Class<T> componentClass)
{
if (AuthenticatedWebPage.class.isAssignableFrom(componentClass))
{
if (ApiAuthenticatedWebSession.get().isSignedIn())
return true;
throw new RestartResponseAtInterceptPageException(new
LoginPage());
}
return true;
}
@Override
public boolean isActionAuthorized(Component component, Action
action)
{
return true;
}
});
2) I have every page needing login.
3) I've got the login page mounted as /login and @RequireHttps on it.
4) In the onsubmit of the the login form I'm calling
continueToOriginalDestination();
That's my setup, My attempt was to override createRedirectUrl in
HttpsMapper so that it looks like this:
@Override
protected String createRedirectUrl(IRequestHandler handler, Request
request, Scheme scheme)
{
return StringUtils.remove(super.createRedirectUrl(handler,
request, scheme), "/documentation");
}
This works as long as I go to http://myserver.com/login and it will
correctly redirect to https://myserver.com/login rather than
https://myserver.com/documentation/login like it did before. However,
if I go to http://myserver.com/ (the home page which redirects to the
login page as part of the authorization strategy) it goes to
https://myserver.com/documentation/login. Also if I go straight to
the login page, login successfully, it will redirect to
http://myserver.com/documentation what it thinks is the home page.
I looked at the code in RestartResponseAtInterceptPageException and
I'm thinking this code could be the culprit:
static void continueToOriginalDestination()
{
InterceptData data = InterceptData.get();
if (data != null)
{
data.continueOk = true;
String url =
RequestCycle.get().getUrlRenderer().renderUrl(data.originalUrl);
RequestCycle.get().replaceAllRequestHandlers(new
RedirectRequestHandler(url)); <-- that's probably it
}
}
I also noticed when debugging, that if I go to http://myserver.com,
it never gets to the HttpsMapper#createRedirectUrl method probably
because of the code above. Of course, everything above works
perfect when I'm running it in WebLogic by itself with no Apache
Proxy in front of it.
I know what I wrote is not the best solution, but I'm really not sure
there's any other way based on how the Weblogic Apache plugin works.
Thanks in advance for any help.
Tim
On 1/11/13 5:01 PM, vp143 wrote:
Hi Tim,
I do not use Weblogic but I do use Jboss.
Your problem sounds familar (but not exactly the same).
Take a look at my resolution here:
http://apache-wicket.1842946.n4.nabble.com/Configure-http-and-https-with-apache-and-jboss-td3633546.html
and try and apply it to Weblogic.
Regards
Vishal
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/HttpsMapper-with-Apache-Virtual-Host-Appending-the-Wrong-Path-tp4655303p4655311.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org