Re: HttpsMapper not Switching to SSL When there is no JsessionId Cookie
A JIRA has been created.
https://issues.apache.org/jira/browse/WICKET-5129
Thanks,
Tim
On 3/28/13 6:52 AM, Sven Meier wrote:
Please create a quickstart and attach it to a jira issue.
Sven
On 03/27/2013 06:41 PM, Tim Urberg wrote:
Hi Everyone,
I'm having an issue with HttpsMapper not switching to SSL when there
is no JSESSIONID cookie. It's happening with wicket-auth-roles when
the user goes to the home page, which need authentication. I have
this code in my init method in my WebApplication class.
getSecuritySettings().setAuthorizationStrategy(new
IAuthorizationStrategy()
{
@Override
public boolean
isInstantiationAuthorized(Class componentClass)
{
if (AuthenticatedWebPage.class.isAssignableFrom(componentClass))
{
if (MyAuthenticatedWebSession.get().isSignedIn())
return true;
throw new RestartResponseAtInterceptPageException(new
LoginPage());
}
return true;
}
@Override
public boolean isActionAuthorized(Component component, Action action)
{
return true;
}
});
HomePage implements AuthenticatedWebPage and LoginPage has the
@RequireHttps annotation. This only seems to happen when there is no
JSESSIONID cookie. The URL looks like this:
http://localhost:7011/documentation/login;jsessionid=1c9nRTpWGWynRXdX1WKC5ZnSfTNKCydGTdHH83mvfXQZQcQ8fLpx!-1875818450?0
when it should be https://localhost:7012/login. If I try it a second
time after the cookie has been created it works fine. This is not a
problem when I go straight to http://localhost:7011/login (works fine
then). Just wondering if anyone else has this problem.
Thanks,
Tim
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
HttpsMapper not Switching to SSL When there is no JsessionId Cookie
Hi Everyone,
I'm having an issue with HttpsMapper not switching to SSL when there is
no JSESSIONID cookie. It's happening with wicket-auth-roles when the
user goes to the home page, which need authentication. I have this code
in my init method in my WebApplication class.
getSecuritySettings().setAuthorizationStrategy(new IAuthorizationStrategy()
{
@Override
public boolean
isInstantiationAuthorized(Class componentClass)
{
if (AuthenticatedWebPage.class.isAssignableFrom(componentClass))
{
if (MyAuthenticatedWebSession.get().isSignedIn())
return true;
throw new RestartResponseAtInterceptPageException(new
LoginPage());
}
return true;
}
@Override
public boolean isActionAuthorized(Component component, Action action)
{
return true;
}
});
HomePage implements AuthenticatedWebPage and LoginPage has the
@RequireHttps annotation. This only seems to happen when there is no
JSESSIONID cookie. The URL looks like this:
http://localhost:7011/documentation/login;jsessionid=1c9nRTpWGWynRXdX1WKC5ZnSfTNKCydGTdHH83mvfXQZQcQ8fLpx!-1875818450?0
when it should be https://localhost:7012/login. If I try it a second
time after the cookie has been created it works fine. This is not a
problem when I go straight to http://localhost:7011/login (works fine
then). Just wondering if anyone else has this problem.
Thanks,
Tim
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Eclipse or IntelliJ
Here's the thing, Intellij is great, but it costs like five zillion dollars! (slight exaggeration). So I use Eclipse since its FREE! and it works great for me (even on a Mac). The nice thing about Wicket is that you don't need any special IDE plugins to use it. As long as your IDE knows how to do Java (I hope), HTML, CSS and JavaScript (which most have built in editors for out of the box). Then you're good. On 2/19/13 4:09 PM, Francois Meillet wrote: You have a mac ? Choose the best tool ! Choose Intellij ! François Meillet Formation Wicket - Développement Wicket Le 19 févr. 2013 à 23:06, Stephen Walsh a écrit : That's what I'm hoping for. IntelliJ looks a lot more polished especially for the Mac. Eclipse is crippling at times because it is so slow. Just sort of getting a feel for the Wicket community and what people like best. ___ Stephen Walsh | http://connectwithawalsh.com On Tue, Feb 19, 2013 at 4:03 PM, Josh Kamau wrote: Hi; You use one of them and you feel like you are missing something? No you are not. The one you are most familiar with is the best. I use intellij ... This discussion might also give you what you are looking for. http://www.linkedin.com/groups/Which-IDE-you-use-develop-80181.S.125932453?qid=98abd743-9a14-4eee-91e5-dbd6854bbf52&trk=group_most_popular-0-b-ttl&goback=%2Egmp_80181 Josh On Wed, Feb 20, 2013 at 1:00 AM, Cedric Gatay wrote: At SRMvision we use exclusively IntelliJ for developping. Its excellent Maven support, smart completion and robustness made us forget eclipse very quickly. Le 19 févr. 2013 22:18, "Stephen Walsh" a écrit : Who uses what and why? I've only ever used Eclipse, but I discovered IntelliJ earlier this week and it's so different. Just wondering pros and cons on each. Thanks! ___ Stephen Walsh | http://connectwithawalsh.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: HttpsMapper with Apache Virtual Host Appending the Wrong Path
One last time, I found a bug in the code I had below, here's the fixed
version:
@Override
protected String createRedirectUrl(IRequestHandler handler, Request
request, Scheme scheme)
{
HttpServletRequest req = (HttpServletRequest) ((WebRequest)
request).getContainerRequest();
String weblogicPrepend = req.getHeader(WL_PATH_PREPEND);
String requestUri = req.getRequestURI();
String url = scheme.urlName() + "://";
url += req.getServerName();
if (!scheme.usesStandardPort(getConfig()))
url += ":" + scheme.getPort(getConfig());
url += StringUtils.remove(requestUri, weblogicPrepend);
if (req.getQueryString() != null)
url += "?" + req.getQueryString();
return url;
}
On 2/13/13 5:58 PM, Tim Urberg wrote:
One more thing, I needed to override createRedirectUrl in HttpsMapper
to look like this:
@Override
protected String createRedirectUrl(IRequestHandler handler,
Request request, Scheme scheme)
{
HttpServletRequest req = (HttpServletRequest) ((WebRequest)
request).getContainerRequest();
String url = scheme.urlName() + "://";
url += req.getServerName();
if (!scheme.usesStandardPort(getConfig()))
{
url += ":" + scheme.getPort(getConfig());
}
if (req.getQueryString() != null)
{
url += "?" + req.getQueryString();
}
return url;
}
It does the same thing, checks the context path. It would be nice if
createRedirectUrl had separate methods for each part of the URL so
those could be overridden individually since I basically copied and
pasted the code from the original method only changing the request URI
part.
On 2/13/13 2:38 PM, Tim Urberg wrote:
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 ex
Re: HttpsMapper with Apache Virtual Host Appending the Wrong Path
One more thing, I needed to override createRedirectUrl in HttpsMapper to
look like this:
@Override
protected String createRedirectUrl(IRequestHandler handler, Request
request, Scheme scheme)
{
HttpServletRequest req = (HttpServletRequest) ((WebRequest)
request).getContainerRequest();
String url = scheme.urlName() + "://";
url += req.getServerName();
if (!scheme.usesStandardPort(getConfig()))
{
url += ":" + scheme.getPort(getConfig());
}
if (req.getQueryString() != null)
{
url += "?" + req.getQueryString();
}
return url;
}
It does the same thing, checks the context path. It would be nice if
createRedirectUrl had separate methods for each part of the URL so those
could be overridden individually since I basically copied and pasted the
code from the original method only changing the request URI part.
On 2/13/13 2:38 PM, Tim Urberg wrote:
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 boolean
isInstantiationAuthorized(Class 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
continueToOrig
Re: HttpsMapper with Apache Virtual Host Appending the Wrong Path
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 boolean
isInstantiationAuthorized(Class 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 co
Re: Wicket job market
I wouldn't discount Apache, look at how Struts took off, and look at the Apache HTTP server, the most widely used server on the web. Apache may not be a "big corporation" but they are a still a big name. On 2/4/13 7:37 AM, Ernesto Reinaldo Barreiro wrote: Hi, IMHO on countries that invest heavily on R&D (new technologies) like Germany, Netherlands, UK, USA, etc Wicket market is growing... and you can find lots of Jobs posts asking for Wicket versed programmers.. See http://www.indeed.de/Jobs?q=Wicket&l= http://www.indeed.nl/Wicket-vacatures http://www.indeed.fr/emplois?q=Wicket&l= http://www.indeed.co.uk/jobs?q=Wicket&l= compare to http://www.indeed.es/ofertas?q=Wicket&l= :-( As many other OpenSource projects its development depends largely on volunteers and on companies willing to pay back with "employee time" for maintenance/documentation. etc. So, there is no point on comparing with frameworks backed by big players or "well established" frameworks. At least in Spain my experience is that: 1- "I do not risk my ass" decision makers are a big obstacle for adoption: they just want to hear about "big names backed software" or at least well know/established software... so that, if development ins't going as planned, it is not a problem of the framework selected. 2- Many programmers comming from Struts like frameworks background have big problems in caching up with OOP required for Wicket and the "Wicket way". 3- Lack of a unified "place" where to find free/well-supported "commercial quality" components doesn't help either when you want to sell wicket. On Mon, Feb 4, 2013 at 1:05 PM, Philippe Demaison wrote: Hello, Let's say that the most popular java web frameworks are Wicket, Tapestry, GWT, Spring MVC. Have you seen the graph ? http://www.indeed.com/jobtrends?q=Wicket%2C+Tapestry%2C+GWT%2C+%22Spring+MVC%22 Other frameworks Play Framework, Apache Click, Stripes, Struts, JSF, Seam http://www.indeed.com/jobtrends?q=%22Play+Framework%22%2C+%22Apache+Click%22%2C+Stripes%2C+Struts%2C+JSF%2C+Seam What needs to be improved to get a wider adoption of Wicket ? Best regards Phlippe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: HttpsMapper with Apache Virtual Host Appending the Wrong Path
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 boolean
isInstantiationAuthorized(Class 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
-
Re: Wicket + Spring
If you use Maven, it will take care of all the dependencies for you. That would be the easiest way to go. Make sure you make your Wicket project into a war by using the war packaging element and have the wicket project depend on the spring project. On 1/20/13 10:52 AM, JCoder wrote: Hi all, Im just trying to setup a basic project structure in Eclipse with Wicket and Spring. I think its pretty smart to separate both Wicket and Spring into two different Eclipse projects, isnt it? Thus, I created an Eclipse project for the Web part and one for the Spring (and later Hibernate as well) part. Now when I start Tomcat with Eclipse I get "...Caused by: java.lang.NoClassDefFoundError: org/springframework/context/ConfigurableApplicationContext" Thats not rocket science. After adding the corresponding Spring lib to the WEB-INF/lib folder another error message appears after server startup telling me that another class is missing from a different jar. Probably I will end up adding all Spring jars into my WEB-INF/lib folder. But thats not what I what. I dont want to add any Spring Core jar in my Web project (Reasons should be clear). I already added all Spring related jars into my different Spring Eclipse project. Any suggestions. Cheers, Y - 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
Re: HttpsMapper with Apache Virtual Host Appending the Wrong Path
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 boolean
isInstantiationAuthorized(Class 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
Re: HttpsMapper with Apache Virtual Host Appending the Wrong Path
Hi Vishal, Thanks for sending this. I looked into it and the Weblogic HTTP Server plugin uses a different mechanism than the solution you posted. I'm going to have to look into it further. If anyone else has experience with the Weblogic plugin, your help would be appreciated (even if it was a non-Wicket case). Otherwise, it's something that will be on my list of things to look into down the road. Thanks, 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
HttpsMapper with Apache Virtual Host Appending the Wrong Path
I using Wicket 6.4.0 and am deploying to WebLogic server version
10.3.5.0 I have set up a simple HttpsMapper in my WebApplication like this:
@Override
public void init()
{
...
setRootRequestMapper(new HttpsMapper(getRootRequestMapper(),
new HttpsConfig()));
}
I have a login page with the @RequireHttps annotation on it (set up with
Wicket Auth Roles). Everything works great when I deploy it to Weblogic
by itself. The problem comes in when the application sits behind Apache
using the Weblogic Apache Plugin
(http://docs.oracle.com/cd/E11035_01/wls100/plugins/apache.html). When
it tries to do the switch to https, it appends the weblogic context root
to the end of the path. So here's how it looks:
Weblogic Only (no problem):
Non-ssl - http://myserver.mycompany.com/documentation
after ssl switch - https://myserver.mycompany.com/documentation
Apache in front of weblogic
Non-ssl: http://documentation.mycompany.com
After ssl switch: https://documentation.mycompany.com/documentation <--
appends /documentation on the end
So then we get a 404. Here's what the Apache config snippets look like:
ServerName documentation.mycompany.com
