Re: Tomcat 7 SSL and getDesiredSchemeFor problem
Hi, No I did not. I would like to get both method (http and https) accessible. There is no proxy used. s -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Tomcat-7-SSL-and-getDesiredSchemeFor-problem-tp4671980p4671982.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: Tomcat 7 SSL and getDesiredSchemeFor problem
Hi,
> The sympthom is that super.getDesiredSchemeFor(pageClass) always
returns HTTP
> regardless https or http is in the url.
>
> Scheme sm=super.getDesiredSchemeFor(pageClass);
did you annotate your pageClass with RequireHttps? Whether HTTPS is
desired, does not depend on the scheme of the incoming url.
Regards
Sven
On 17.09.2015 11:50, Sandor Feher wrote:
Hi,
I don't know is it the appropriate channel I should ask but I hope somebody
can give me a pointer.
The sympthom is that super.getDesiredSchemeFor(pageClass) always returns
HTTP regardless https or http is in the url.
If I force Scheme.HTTPS then everything works fine.
TIA., Sandor
-
servlet.xml looks like this:
SSLCertificateFile="C:\apache-tomcat-7.0.64\conf\wildcard_hok-plastic_com.crt"
SSLCertificateKeyFile="C:\apache-tomcat-7.0.64\conf\wildcard_hok-plastic_com.key"
clientAuth="false" sslProtocol="TLS" />
My Application's relevant part is this:
setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new
HttpsConfig()) {
@Override
protected Scheme getDesiredSchemeFor(Class pageClass) {
if (getConfigurationType() ==
RuntimeConfigurationType.DEVELOPMENT) {
LOG.info("Dev mode, always use HTTP");
return Scheme.HTTP;
} else {
Scheme sm=super.getDesiredSchemeFor(pageClass);
sm=Scheme.HTTPS;
LOG.info("not in development mode "+sm.name());
return sm;
}
}
});
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Tomcat-7-SSL-and-getDesiredSchemeFor-problem-tp4671980.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
Tomcat 7 SSL and getDesiredSchemeFor problem
Hi,
I don't know is it the appropriate channel I should ask but I hope somebody
can give me a pointer.
The sympthom is that super.getDesiredSchemeFor(pageClass) always returns
HTTP regardless https or http is in the url.
If I force Scheme.HTTPS then everything works fine.
TIA., Sandor
-
servlet.xml looks like this:
My Application's relevant part is this:
setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new
HttpsConfig()) {
@Override
protected Scheme getDesiredSchemeFor(Class pageClass) {
if (getConfigurationType() ==
RuntimeConfigurationType.DEVELOPMENT) {
LOG.info("Dev mode, always use HTTP");
return Scheme.HTTP;
} else {
Scheme sm=super.getDesiredSchemeFor(pageClass);
sm=Scheme.HTTPS;
LOG.info("not in development mode "+sm.name());
return sm;
}
}
});
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Tomcat-7-SSL-and-getDesiredSchemeFor-problem-tp4671980.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: Firefox 39+ Error code: ssl_error_weak_server_ephemeral_dh_key on ssl connection
Thank you, niestroj, I have solved the issue for my apache tomcat server. It was quite straightforward. I found the solution here: https://jamfnation.jamfsoftware.com/discussion.html?id=15032 The problem is, as Martin Grigorov pointed, a purely server issue, not a wicket issue. I did have a quick look to see if one could tweak the embedded jetty server to resolve the issue, for when one is unit testing. I'm afraid I have run out of time and I have to move on to my next task. But if I can spare 30 minutes, I'll go back to it and hopefully post the solution for the embedded jetty server here. Thanks, once more, Lucas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Firefox-39-Error-code-ssl-error-weak-server-ephemeral-dh-key-on-ssl-connection-tp4671661p4671691.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: Firefox 39+ Error code: ssl_error_weak_server_ephemeral_dh_key on ssl connection
This is what you need to read about it: Logjam attack <https://weakdh.org/> . You need to disable come cipher suites in your server HTTPS configuration. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Firefox-39-Error-code-ssl-error-weak-server-ephemeral-dh-key-on-ssl-connection-tp4671661p4671679.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: Firefox 39+ Error code: ssl_error_weak_server_ephemeral_dh_key on ssl connection
Hi, Wicket doesn't manage this so it is purely Jetty/Tomcat config issue. Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jul 27, 2015 at 12:28 PM, lucast wrote: > Dear Forum, > Since I have upgraded to Firefox 39 I have not been able to run my > application on https since on the browser, I get the following error: > > > > This applies to the embedded jetty server and also the tomcat deployment > server. > > Is this something that can be solved via Wicket, perhaps using > SslContextFactory or is it a purely server problem, exclusive of the wicket > application? > > Thanks in advance, > Lucas > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Firefox-39-Error-code-ssl-error-weak-server-ephemeral-dh-key-on-ssl-connection-tp4671661.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 > >
Firefox 39+ Error code: ssl_error_weak_server_ephemeral_dh_key on ssl connection
Dear Forum, Since I have upgraded to Firefox 39 I have not been able to run my application on https since on the browser, I get the following error: This applies to the embedded jetty server and also the tomcat deployment server. Is this something that can be solved via Wicket, perhaps using SslContextFactory or is it a purely server problem, exclusive of the wicket application? Thanks in advance, Lucas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Firefox-39-Error-code-ssl-error-weak-server-ephemeral-dh-key-on-ssl-connection-tp4671661.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: SSL Offloading and Wicket
We are considering something along those lines you are suggesting as an alternative.As far as load balancers, we actually have two separate situations: one uses AWS Elastic Load Balancer and the other HAProxy. Matt On Thu, Dec 12, 2013 at 4:35 AM, Michael Haitz wrote: > you could use "proxyPort“ in your connector configuration, but this will > always override ‚getServerPort‘ with this value no matter you’ve a http or > https request. > > Do you use an apache or nginx in front? > > > Am 12.12.2013 um 05:05 schrieb Matthew Welch : > > > I'm sure I'm missing something simple as there are certainly many others > > using similar setups, but I cannot figure out what I'm doing wrong. > > > > We force all requests from the public internet to use HTTPS when > accessing > > our app.We terminate SSL at the load balancer and the request that > actually > > hits Apache and then Tomcat is straight HTTP. The load balancer adds the > > proper X-Forwarded-Proto headers to the requests heading back to the app > > server and Wicket and we've confirmed that these are being received. > We've > > setup the XForwardedRequestWrapperFactory in our web application init. We > > can even confirm that request.getScheme() is properly returning "https" > > inside our application. > > > > Where things break down is when Wicket issues a redirect, which of course > > it does all of the time as people navigate from page to page. For some > > reason, the issued redirects are always HTTP, instead of HTTPS. These > HTTP > > redirects themselves eventually get redirected back to HTTPS by our load > > balancer on their return trip from the client, but many of our customers > > are ultra security conscious and have firewalls in place that won't even > > allow those initial HTTP requests through, so we've got a problem. > > > > We've traced through the Tomcat code and the cause is > > in org.apache.catalina.connector.Response. This is the original response > > that was created when the container first began processing the request. > It > > carries a pointer to the "original" request as well and it uses this > > request with its getScheme(), getServerPort(), and getServerName() to > > generate the redirect that is eventually returned. It does not use the > > "wrapped" request that contains the values determined from processing the > > X-Forwarded headers. > > > > As I said, I'm sure this is working as intended and that we've just > missed > > something somewhere, but for the life of me, I can figure out what it is. > > > > Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. > > > > Matt > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: SSL Offloading and Wicket
That makes sense. I'll ask there. Thank you. Matt On Thu, Dec 12, 2013 at 2:00 AM, Martin Grigorov wrote: > Hi, > > I think you should ask in Tomcat mailing lists. > The related code in Wicket is: > > https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java?source=cc#L232 > > As you can see Wicket always passes relative url to the underlying > container. > The container makes it absolute, i.e. sets the scheme, host, port and full > path, and then sets the "Location" response header. > > > On Thu, Dec 12, 2013 at 6:05 AM, Matthew Welch > wrote: > > > I'm sure I'm missing something simple as there are certainly many others > > using similar setups, but I cannot figure out what I'm doing wrong. > > > > We force all requests from the public internet to use HTTPS when > accessing > > our app.We terminate SSL at the load balancer and the request that > actually > > hits Apache and then Tomcat is straight HTTP. The load balancer adds the > > proper X-Forwarded-Proto headers to the requests heading back to the app > > server and Wicket and we've confirmed that these are being received. > We've > > setup the XForwardedRequestWrapperFactory in our web application init. We > > can even confirm that request.getScheme() is properly returning "https" > > inside our application. > > > > Where things break down is when Wicket issues a redirect, which of course > > it does all of the time as people navigate from page to page. For some > > reason, the issued redirects are always HTTP, instead of HTTPS. These > HTTP > > redirects themselves eventually get redirected back to HTTPS by our load > > balancer on their return trip from the client, but many of our customers > > are ultra security conscious and have firewalls in place that won't even > > allow those initial HTTP requests through, so we've got a problem. > > > > We've traced through the Tomcat code and the cause is > > in org.apache.catalina.connector.Response. This is the original response > > that was created when the container first began processing the request. > It > > carries a pointer to the "original" request as well and it uses this > > request with its getScheme(), getServerPort(), and getServerName() to > > generate the redirect that is eventually returned. It does not use the > > "wrapped" request that contains the values determined from processing the > > X-Forwarded headers. > > > > As I said, I'm sure this is working as intended and that we've just > missed > > something somewhere, but for the life of me, I can figure out what it is. > > > > Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. > > > > Matt > > >
Re: SSL Offloading and Wicket
you could use "proxyPort“ in your connector configuration, but this will always override ‚getServerPort‘ with this value no matter you’ve a http or https request. Do you use an apache or nginx in front? Am 12.12.2013 um 05:05 schrieb Matthew Welch : > I'm sure I'm missing something simple as there are certainly many others > using similar setups, but I cannot figure out what I'm doing wrong. > > We force all requests from the public internet to use HTTPS when accessing > our app.We terminate SSL at the load balancer and the request that actually > hits Apache and then Tomcat is straight HTTP. The load balancer adds the > proper X-Forwarded-Proto headers to the requests heading back to the app > server and Wicket and we've confirmed that these are being received. We've > setup the XForwardedRequestWrapperFactory in our web application init. We > can even confirm that request.getScheme() is properly returning "https" > inside our application. > > Where things break down is when Wicket issues a redirect, which of course > it does all of the time as people navigate from page to page. For some > reason, the issued redirects are always HTTP, instead of HTTPS. These HTTP > redirects themselves eventually get redirected back to HTTPS by our load > balancer on their return trip from the client, but many of our customers > are ultra security conscious and have firewalls in place that won't even > allow those initial HTTP requests through, so we've got a problem. > > We've traced through the Tomcat code and the cause is > in org.apache.catalina.connector.Response. This is the original response > that was created when the container first began processing the request. It > carries a pointer to the "original" request as well and it uses this > request with its getScheme(), getServerPort(), and getServerName() to > generate the redirect that is eventually returned. It does not use the > "wrapped" request that contains the values determined from processing the > X-Forwarded headers. > > As I said, I'm sure this is working as intended and that we've just missed > something somewhere, but for the life of me, I can figure out what it is. > > Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. > > Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SSL Offloading and Wicket
Hi, I think you should ask in Tomcat mailing lists. The related code in Wicket is: https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java?source=cc#L232 As you can see Wicket always passes relative url to the underlying container. The container makes it absolute, i.e. sets the scheme, host, port and full path, and then sets the "Location" response header. On Thu, Dec 12, 2013 at 6:05 AM, Matthew Welch wrote: > I'm sure I'm missing something simple as there are certainly many others > using similar setups, but I cannot figure out what I'm doing wrong. > > We force all requests from the public internet to use HTTPS when accessing > our app.We terminate SSL at the load balancer and the request that actually > hits Apache and then Tomcat is straight HTTP. The load balancer adds the > proper X-Forwarded-Proto headers to the requests heading back to the app > server and Wicket and we've confirmed that these are being received. We've > setup the XForwardedRequestWrapperFactory in our web application init. We > can even confirm that request.getScheme() is properly returning "https" > inside our application. > > Where things break down is when Wicket issues a redirect, which of course > it does all of the time as people navigate from page to page. For some > reason, the issued redirects are always HTTP, instead of HTTPS. These HTTP > redirects themselves eventually get redirected back to HTTPS by our load > balancer on their return trip from the client, but many of our customers > are ultra security conscious and have firewalls in place that won't even > allow those initial HTTP requests through, so we've got a problem. > > We've traced through the Tomcat code and the cause is > in org.apache.catalina.connector.Response. This is the original response > that was created when the container first began processing the request. It > carries a pointer to the "original" request as well and it uses this > request with its getScheme(), getServerPort(), and getServerName() to > generate the redirect that is eventually returned. It does not use the > "wrapped" request that contains the values determined from processing the > X-Forwarded headers. > > As I said, I'm sure this is working as intended and that we've just missed > something somewhere, but for the life of me, I can figure out what it is. > > Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. > > Matt >
SSL Offloading and Wicket
I'm sure I'm missing something simple as there are certainly many others using similar setups, but I cannot figure out what I'm doing wrong. We force all requests from the public internet to use HTTPS when accessing our app.We terminate SSL at the load balancer and the request that actually hits Apache and then Tomcat is straight HTTP. The load balancer adds the proper X-Forwarded-Proto headers to the requests heading back to the app server and Wicket and we've confirmed that these are being received. We've setup the XForwardedRequestWrapperFactory in our web application init. We can even confirm that request.getScheme() is properly returning "https" inside our application. Where things break down is when Wicket issues a redirect, which of course it does all of the time as people navigate from page to page. For some reason, the issued redirects are always HTTP, instead of HTTPS. These HTTP redirects themselves eventually get redirected back to HTTPS by our load balancer on their return trip from the client, but many of our customers are ultra security conscious and have firewalls in place that won't even allow those initial HTTP requests through, so we've got a problem. We've traced through the Tomcat code and the cause is in org.apache.catalina.connector.Response. This is the original response that was created when the container first began processing the request. It carries a pointer to the "original" request as well and it uses this request with its getScheme(), getServerPort(), and getServerName() to generate the redirect that is eventually returned. It does not use the "wrapped" request that contains the values determined from processing the X-Forwarded headers. As I said, I'm sure this is working as intended and that we've just missed something somewhere, but for the life of me, I can figure out what it is. Any ideas? We need Wicket/Tomcat to produce HTTPS redirects. Matt
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
Re: HttpsMapper not Switching to SSL When there is no JsessionId Cookie
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
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: HttpsMapper: doent work with proxy-ssl termination
Hi,
If the proxy handles ssl, I assume it forwards the request to wicket
over plain http?
In that case, wicket cannot see (with default config) that the request
was in fact an ssl request.
Have a look at XForwardedRequestWrapper to make wicket aware of the ssl
termination on your proxy.
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 10-11-2012 14:42, schreef Martin Sachs:
Hi *,
i noticed some errors while using the httpsmapper with ssl-termination
on a proxy(nginx, bigip-F5).
Wicket redirects the following sequence:
http://domain.com/test
results in
https://domain.com/test
this url was also redirected with end ?0 but not https. Redirect to
http://domain.com/test?0
I debugged the HttpsMapper and found, that the method
mapHandler(IRequestHandler handler, Request request) causes this problem.
Original wicket-6.2 source
//**
* Creates a url for the handler. Modifies it with the correct
{@link Scheme} if necessary.
*
* @param handler
* @param request
* @return url
*/
final Url mapHandler(IRequestHandler handler, Request request)
{
Url url = delegate.mapHandler(handler);
Scheme desired = getDesiredSchemeFor(handler);
Scheme current = getSchemeOf(request);
if (!desired.isCompatibleWith(current))
{
// the generated url does not have the correct scheme, set
it (which in turn will cause
// the url to be rendered in its full representation)
url.setProtocol(desired.urlName());
url.setPort(desired.getPort(config));
}
return url;
}/
I changed the code to get it work:
/final Url mapHandler(IRequestHandler handler, Request request)
{
Url url = delegate.mapHandler(handler);
Scheme desired = getDesiredSchemeFor(handler);
if (desired!= Scheme.ANY)
{
// the generated url does not have the correct scheme, set
it (which in turn will cause
// the url to be rendered in its full representation)
url.setProtocol(desired.urlName());
url.setPort(desired.getPort(config));
}
return url;
}/
I dont have a quickstart for this, 'cause you also need a proxy
configuration to get this bug.
What do you mean?
cya
Martin
HttpsMapper: doent work with proxy-ssl termination
Hi *,
i noticed some errors while using the httpsmapper with ssl-termination
on a proxy(nginx, bigip-F5).
Wicket redirects the following sequence:
http://domain.com/test
results in
https://domain.com/test
this url was also redirected with end ?0 but not https. Redirect to
http://domain.com/test?0
I debugged the HttpsMapper and found, that the method
mapHandler(IRequestHandler handler, Request request) causes this problem.
Original wicket-6.2 source
//**
* Creates a url for the handler. Modifies it with the correct
{@link Scheme} if necessary.
*
* @param handler
* @param request
* @return url
*/
final Url mapHandler(IRequestHandler handler, Request request)
{
Url url = delegate.mapHandler(handler);
Scheme desired = getDesiredSchemeFor(handler);
Scheme current = getSchemeOf(request);
if (!desired.isCompatibleWith(current))
{
// the generated url does not have the correct scheme, set
it (which in turn will cause
// the url to be rendered in its full representation)
url.setProtocol(desired.urlName());
url.setPort(desired.getPort(config));
}
return url;
}/
I changed the code to get it work:
/final Url mapHandler(IRequestHandler handler, Request request)
{
Url url = delegate.mapHandler(handler);
Scheme desired = getDesiredSchemeFor(handler);
if (desired!= Scheme.ANY)
{
// the generated url does not have the correct scheme, set
it (which in turn will cause
// the url to be rendered in its full representation)
url.setProtocol(desired.urlName());
url.setPort(desired.getPort(config));
}
return url;
}/
I dont have a quickstart for this, 'cause you also need a proxy
configuration to get this bug.
What do you mean?
cya
Martin
Re: Problem sending email using SSL after upgrading to Wicket 1.5
It turns out that the problem was because of the custom trust store we were
using in our application.
It has nothing to do with wicket.
Sorry for bothering you all.
On Tue, Aug 14, 2012 at 3:55 PM, James Eliyezar wrote:
> Martin,
>
> Yes I use smtp props that are similar to what you have shared. Kindly see
> my initial post for the smtp properties used by me.
> I may sound stupid but the same piece of code runs fine when using
> wicket-1.4.x.
> And I use the following wicket related dependencies:
>
>- wicket
>- wicket-extensions
>- wicket-ioc
>- wicket-spring
>- wicket-datetime
>- wicketstuff-annotation
>- wicketstuff-objectautocomplete
>- wiquery-jquery-ui
>
> All of them use the version 1.5.7. (Yes some of them don't belong to the
> wicket project at all but they depend on wicket-1.5.x)
>
> Is there a possibility of a dependency conflict?
>
> NOTE: I found that wicket-ioc depends on "cglib". But even when I excluded
> it the problem persists.
> On Tue, Aug 14, 2012 at 2:27 PM, Martin Grigorov wrote:
>
>> Hi,
>>
>> I don't think this is anyhow related to Wicket.
>> Here are the GMail SMTP related props I use successfully:
>>
>> mail.server.host=smtp.gmail.com
>> mail.server.port=587
>> mail.server.username=my.em...@gmail.com
>> mail.server.password=my-passwd
>> mail.server.starttls.enable=true
>>
>> You may also check the docs of SMTPAppender in Logback. There are
>> examples for configuring it with GMail. I believe the problem is in
>> these settings.
>>
>> On Tue, Aug 14, 2012 at 5:34 AM, James Eliyezar
>> wrote:
>> > Greetings to all of you.
>> >
>> > We recently upgraded our application to Wicket 1.5.
>> > However, after upgrading we had problems sending email using SSL from
>> our
>> > application.
>> > This may not be related to wicket at all but I promise we didn't change
>> any
>> > dependencies other than wicket's.
>> > What amuses me is that it works as expected in our older versions which
>> > still use Wicket 1.4.x.
>> > Both the older version and the current version were run using the same
>> JRE.
>> >
>> > Here's the code that sends email:
>> >
>> >
>> > public class MailSenderTask implements Runnable
>> > {
>> > private Properties smtpProperties;
>> > private EmailMessage message;
>> > private static final Logger logger =
>> > LoggerFactory.getLogger(MailSenderTask.class);
>> >
>> > public MailSenderTask(Properties smtpProperties, EmailMessage
>> message)
>> > {
>> > this.smtpProperties = smtpProperties;
>> > this.message = message;
>> > }
>> >
>> > public synchronized void sendMail() throws Exception
>> > {
>> > try {
>> > if (addSSlProvider()) {
>> > logger.info("Adding ssl provider");
>> > Security.addProvider(new
>> > com.sun.net.ssl.internal.ssl.Provider());
>> > } else {
>> > logger.info("Using plain text connection as ssl/tls is
>> not
>> > enabled");
>> > }
>> > Session session = createSession();
>> > MimeMessage mimeMessage = new MimeMessage(session);
>> > mimeMessage.setSender(new
>> InternetAddress(message.getSender()));
>> > mimeMessage.setSubject(message.getSubject());
>> >
>> > if (message.getRecipients().indexOf(',') > 0) {
>> > mimeMessage.setRecipients(Message.RecipientType.TO,
>> > InternetAddress.parse(message.getRecipients()));
>> > } else {
>> > mimeMessage.setRecipient(Message.RecipientType.TO, new
>> > InternetAddress(message.getRecipients()));
>> > }
>> >
>> > MimeBodyPart bodyPart = new MimeBodyPart();
>> > bodyPart.setContent(message.getBody(), "text/html");
>> >
>> > Multipart multipart = new MimeMultipart();
>> > multipart.addBodyPart(bodyPart);
>> >
>> > if (message.getAttachments() != null &&
>> > message.getAttachments().length > 0) {
>> > for (File file : message.getAttachments()) {
>> > logger.debug("Adding {} as an attach
Re: Problem sending email using SSL after upgrading to Wicket 1.5
Martin,
Yes I use smtp props that are similar to what you have shared. Kindly see
my initial post for the smtp properties used by me.
I may sound stupid but the same piece of code runs fine when using
wicket-1.4.x.
And I use the following wicket related dependencies:
- wicket
- wicket-extensions
- wicket-ioc
- wicket-spring
- wicket-datetime
- wicketstuff-annotation
- wicketstuff-objectautocomplete
- wiquery-jquery-ui
All of them use the version 1.5.7. (Yes some of them don't belong to the
wicket project at all but they depend on wicket-1.5.x)
Is there a possibility of a dependency conflict?
NOTE: I found that wicket-ioc depends on "cglib". But even when I excluded
it the problem persists.
On Tue, Aug 14, 2012 at 2:27 PM, Martin Grigorov wrote:
> Hi,
>
> I don't think this is anyhow related to Wicket.
> Here are the GMail SMTP related props I use successfully:
>
> mail.server.host=smtp.gmail.com
> mail.server.port=587
> mail.server.username=my.em...@gmail.com
> mail.server.password=my-passwd
> mail.server.starttls.enable=true
>
> You may also check the docs of SMTPAppender in Logback. There are
> examples for configuring it with GMail. I believe the problem is in
> these settings.
>
> On Tue, Aug 14, 2012 at 5:34 AM, James Eliyezar
> wrote:
> > Greetings to all of you.
> >
> > We recently upgraded our application to Wicket 1.5.
> > However, after upgrading we had problems sending email using SSL from our
> > application.
> > This may not be related to wicket at all but I promise we didn't change
> any
> > dependencies other than wicket's.
> > What amuses me is that it works as expected in our older versions which
> > still use Wicket 1.4.x.
> > Both the older version and the current version were run using the same
> JRE.
> >
> > Here's the code that sends email:
> >
> >
> > public class MailSenderTask implements Runnable
> > {
> > private Properties smtpProperties;
> > private EmailMessage message;
> > private static final Logger logger =
> > LoggerFactory.getLogger(MailSenderTask.class);
> >
> > public MailSenderTask(Properties smtpProperties, EmailMessage
> message)
> > {
> > this.smtpProperties = smtpProperties;
> > this.message = message;
> > }
> >
> > public synchronized void sendMail() throws Exception
> > {
> > try {
> > if (addSSlProvider()) {
> > logger.info("Adding ssl provider");
> > Security.addProvider(new
> > com.sun.net.ssl.internal.ssl.Provider());
> > } else {
> > logger.info("Using plain text connection as ssl/tls is
> not
> > enabled");
> > }
> > Session session = createSession();
> > MimeMessage mimeMessage = new MimeMessage(session);
> > mimeMessage.setSender(new
> InternetAddress(message.getSender()));
> > mimeMessage.setSubject(message.getSubject());
> >
> > if (message.getRecipients().indexOf(',') > 0) {
> > mimeMessage.setRecipients(Message.RecipientType.TO,
> > InternetAddress.parse(message.getRecipients()));
> > } else {
> > mimeMessage.setRecipient(Message.RecipientType.TO, new
> > InternetAddress(message.getRecipients()));
> > }
> >
> > MimeBodyPart bodyPart = new MimeBodyPart();
> > bodyPart.setContent(message.getBody(), "text/html");
> >
> > Multipart multipart = new MimeMultipart();
> > multipart.addBodyPart(bodyPart);
> >
> > if (message.getAttachments() != null &&
> > message.getAttachments().length > 0) {
> > for (File file : message.getAttachments()) {
> > logger.debug("Adding {} as an attachment", file);
> > MimeBodyPart attachmentPart = new MimeBodyPart();
> > attachmentPart.attachFile(file);
> > multipart.addBodyPart(attachmentPart);
> > }
> > }
> >
> > mimeMessage.setContent(multipart);
> >
> > logger.info("Sending mail...");
> > Transport.send(mimeMessage);
> > logger.info("Mail sent to {}", message.getRecipients());
> > } catch (Exception ex) {
> > throw new EmailException("Error occurre
Re: Problem sending email using SSL after upgrading to Wicket 1.5
Hi,
I don't think this is anyhow related to Wicket.
Here are the GMail SMTP related props I use successfully:
mail.server.host=smtp.gmail.com
mail.server.port=587
mail.server.username=my.em...@gmail.com
mail.server.password=my-passwd
mail.server.starttls.enable=true
You may also check the docs of SMTPAppender in Logback. There are
examples for configuring it with GMail. I believe the problem is in
these settings.
On Tue, Aug 14, 2012 at 5:34 AM, James Eliyezar wrote:
> Greetings to all of you.
>
> We recently upgraded our application to Wicket 1.5.
> However, after upgrading we had problems sending email using SSL from our
> application.
> This may not be related to wicket at all but I promise we didn't change any
> dependencies other than wicket's.
> What amuses me is that it works as expected in our older versions which
> still use Wicket 1.4.x.
> Both the older version and the current version were run using the same JRE.
>
> Here's the code that sends email:
>
>
> public class MailSenderTask implements Runnable
> {
> private Properties smtpProperties;
> private EmailMessage message;
> private static final Logger logger =
> LoggerFactory.getLogger(MailSenderTask.class);
>
> public MailSenderTask(Properties smtpProperties, EmailMessage message)
> {
> this.smtpProperties = smtpProperties;
> this.message = message;
> }
>
> public synchronized void sendMail() throws Exception
> {
> try {
> if (addSSlProvider()) {
> logger.info("Adding ssl provider");
> Security.addProvider(new
> com.sun.net.ssl.internal.ssl.Provider());
> } else {
> logger.info("Using plain text connection as ssl/tls is not
> enabled");
> }
> Session session = createSession();
> MimeMessage mimeMessage = new MimeMessage(session);
> mimeMessage.setSender(new InternetAddress(message.getSender()));
> mimeMessage.setSubject(message.getSubject());
>
> if (message.getRecipients().indexOf(',') > 0) {
> mimeMessage.setRecipients(Message.RecipientType.TO,
> InternetAddress.parse(message.getRecipients()));
> } else {
> mimeMessage.setRecipient(Message.RecipientType.TO, new
> InternetAddress(message.getRecipients()));
> }
>
> MimeBodyPart bodyPart = new MimeBodyPart();
> bodyPart.setContent(message.getBody(), "text/html");
>
> Multipart multipart = new MimeMultipart();
> multipart.addBodyPart(bodyPart);
>
> if (message.getAttachments() != null &&
> message.getAttachments().length > 0) {
> for (File file : message.getAttachments()) {
> logger.debug("Adding {} as an attachment", file);
> MimeBodyPart attachmentPart = new MimeBodyPart();
> attachmentPart.attachFile(file);
> multipart.addBodyPart(attachmentPart);
> }
> }
>
> mimeMessage.setContent(multipart);
>
> logger.info("Sending mail...");
> Transport.send(mimeMessage);
> logger.info("Mail sent to {}", message.getRecipients());
> } catch (Exception ex) {
> throw new EmailException("Error occurred while sending mail",
> ex);
> }
> }
>
> private boolean addSSlProvider()
> {
> String sslEnabledProperty =
> smtpProperties.getProperty("mail.smtp.starttls.enable");
> if (StringUtils.isNotEmpty(sslEnabledProperty)) {
> return Boolean.parseBoolean(sslEnabledProperty);
> }
> return false;
> }
>
> private Session createSession()
> {
> Session session = null;
> if
> (Boolean.parseBoolean(smtpProperties.getProperty("mail.smtp.auth"))) {
> logger.info("Creating session with authentication");
> session = createSessionWithAuthentication(smtpProperties);
> } else {
> logger.info("Creating default session");
> session = createDefaultSession(smtpProperties);
> }
> return session;
> }
>
> private Session createDefaultSession(final Properties smtpProperties)
> {
> return Session.getInstance(smtpProperties);
> }
>
> private Session createSessionWithAuthentication(final Properties
> smtpProperties)
> {
> return Session.getInstance(smtpPrope
Problem sending email using SSL after upgrading to Wicket 1.5
Greetings to all of you.
We recently upgraded our application to Wicket 1.5.
However, after upgrading we had problems sending email using SSL from our
application.
This may not be related to wicket at all but I promise we didn't change any
dependencies other than wicket's.
What amuses me is that it works as expected in our older versions which
still use Wicket 1.4.x.
Both the older version and the current version were run using the same JRE.
Here's the code that sends email:
public class MailSenderTask implements Runnable
{
private Properties smtpProperties;
private EmailMessage message;
private static final Logger logger =
LoggerFactory.getLogger(MailSenderTask.class);
public MailSenderTask(Properties smtpProperties, EmailMessage message)
{
this.smtpProperties = smtpProperties;
this.message = message;
}
public synchronized void sendMail() throws Exception
{
try {
if (addSSlProvider()) {
logger.info("Adding ssl provider");
Security.addProvider(new
com.sun.net.ssl.internal.ssl.Provider());
} else {
logger.info("Using plain text connection as ssl/tls is not
enabled");
}
Session session = createSession();
MimeMessage mimeMessage = new MimeMessage(session);
mimeMessage.setSender(new InternetAddress(message.getSender()));
mimeMessage.setSubject(message.getSubject());
if (message.getRecipients().indexOf(',') > 0) {
mimeMessage.setRecipients(Message.RecipientType.TO,
InternetAddress.parse(message.getRecipients()));
} else {
mimeMessage.setRecipient(Message.RecipientType.TO, new
InternetAddress(message.getRecipients()));
}
MimeBodyPart bodyPart = new MimeBodyPart();
bodyPart.setContent(message.getBody(), "text/html");
Multipart multipart = new MimeMultipart();
multipart.addBodyPart(bodyPart);
if (message.getAttachments() != null &&
message.getAttachments().length > 0) {
for (File file : message.getAttachments()) {
logger.debug("Adding {} as an attachment", file);
MimeBodyPart attachmentPart = new MimeBodyPart();
attachmentPart.attachFile(file);
multipart.addBodyPart(attachmentPart);
}
}
mimeMessage.setContent(multipart);
logger.info("Sending mail...");
Transport.send(mimeMessage);
logger.info("Mail sent to {}", message.getRecipients());
} catch (Exception ex) {
throw new EmailException("Error occurred while sending mail",
ex);
}
}
private boolean addSSlProvider()
{
String sslEnabledProperty =
smtpProperties.getProperty("mail.smtp.starttls.enable");
if (StringUtils.isNotEmpty(sslEnabledProperty)) {
return Boolean.parseBoolean(sslEnabledProperty);
}
return false;
}
private Session createSession()
{
Session session = null;
if
(Boolean.parseBoolean(smtpProperties.getProperty("mail.smtp.auth"))) {
logger.info("Creating session with authentication");
session = createSessionWithAuthentication(smtpProperties);
} else {
logger.info("Creating default session");
session = createDefaultSession(smtpProperties);
}
return session;
}
private Session createDefaultSession(final Properties smtpProperties)
{
return Session.getInstance(smtpProperties);
}
private Session createSessionWithAuthentication(final Properties
smtpProperties)
{
return Session.getInstance(smtpProperties,
new Authenticator()
{
@Override
protected PasswordAuthentication
getPasswordAuthentication()
{
return new
PasswordAuthentication(smtpProperties.getProperty("smtp.username"),
smtpProperties.getProperty("smtp.password"));
}
});
}
public void run()
{
if (smtpProperties != null && message != null) {
try {
sendMail();
} catch (Exception ex) {
throw new EmailException("Error", ex);
}
}
}
}
These are the SMTP properties that were set:
mail.smtp.socketFactory.fallback:false
mail.smtp.socketFactory.class:javax.net.ssl.SSLSocketFactory
mail.transport.protocol:smtp
mail.smtp.connectiontimeout:1
mail.smtp.host:smtp.gmail.com
mail.smtp.timeout:1
mail.smtp.starttls.enable:true
mail.smtp.port:465
mail.smtp.auth:true
Re: SSL Links and buttons
Ok. I just saw your last post and remembered this thread:-) Cheers, Ernesto On Wed, Nov 17, 2010 at 1:42 PM, sonxurxo wrote: > > Hi Ernesto, > > I got stuck with the bad resource URL's rewriting, so, due to hurries in my > job, now we have a standalone page with @RequireHttps annotation. I'll try > it again and get deeper in the problem, I don't give up at all ;), but I > need a time for it that I didn't have. Thank you very much for your > interest, I'll keep this thread up-to-date until I get it!! > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3046640.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: SSL Links and buttons
Hi Ernesto, I got stuck with the bad resource URL's rewriting, so, due to hurries in my job, now we have a standalone page with @RequireHttps annotation. I'll try it again and get deeper in the problem, I don't give up at all ;), but I need a time for it that I didn't have. Thank you very much for your interest, I'll keep this thread up-to-date until I get it!! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3046640.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: SSL Links and buttons
Hi,
Did you get this working at the end? The fix we provided is working
fine for us:-)
Cheers,
Ernesto
On Wed, Oct 27, 2010 at 3:53 PM, sonxurxo wrote:
>
> I'm using:
>
> add(CSSPackageResource.getHeaderContribution("styles/main/layout.css"));
>
> literally as I have just written.
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3015516.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: SSL Links and buttons
I'm using:
add(CSSPackageResource.getHeaderContribution("styles/main/layout.css"));
literally as I have just written.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3015516.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: SSL Links and buttons
It works fine for me for CSS, images, JavaScript and so on: it must be
something we are missing on getUrl() method:-(
What's the url you are getting for layout.css? I'm including CSS using
resource references
add(CSSPackageResource.getHeaderContribution(Styles.ESTILOS));
and
public class Styles {
public static final ResourceReference ESTILOS = new
ResourceReference(Styles.class,"estilos.css");
..
}
Ernesto
On Wed, Oct 27, 2010 at 3:03 PM, sonxurxo wrote:
>
> Hi,
>
> It does not work for me. For correctly replace the ports I had to modify a
> bit the SecureForm code, leaving it as follows:
>
> @Override
> protected void onComponentTag(ComponentTag tag) {
> super.onComponentTag(tag);
> String action = tag.getAttribute("action");
> if (!action.startsWith("http"))
> action = RequestUtils.toAbsolutePath(action);
> // rewrite action to use HTTPs
> if (!action.startsWith("https")) {
> action = replacePort("https" + action.substring(4));
> }
> else {
> action = replacePort(action);
> }
> tag.put("action", action);
>
> }
>
> private String replacePort(String action) {
> RequestCycle requestCycle = RequestCycle.get();
> SecureHttpsRequestCycleProcessor processor =
> (SecureHttpsRequestCycleProcessor) requestCycle
> .getProcessor();
> Integer port = processor.getConfig().getHttpPort();
> Integer httpsPort = processor.getConfig().getHttpsPort();
> action = action.replace(":" + Integer.toString(port) + "/",
> ":" + Integer.toString(httpsPort) + "/");
> return action;
> }
>
> but the modification of the getUrl() method of SecureBufferedWebResponse
> doesn't seem to affect the request for the CSS file, but only for the URLs
> of links and buttons in the page (the debugger never entered that point in
> that request). I'll continue trying it and modifications and keep this
> thread informed up-to-date.
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3015404.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: SSL Links and buttons
Hi,
It does not work for me. For correctly replace the ports I had to modify a
bit the SecureForm code, leaving it as follows:
@Override
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
String action = tag.getAttribute("action");
if (!action.startsWith("http"))
action = RequestUtils.toAbsolutePath(action);
// rewrite action to use HTTPs
if (!action.startsWith("https")) {
action = replacePort("https" + action.substring(4));
}
else {
action = replacePort(action);
}
tag.put("action", action);
}
private String replacePort(String action) {
RequestCycle requestCycle = RequestCycle.get();
SecureHttpsRequestCycleProcessor processor =
(SecureHttpsRequestCycleProcessor) requestCycle
.getProcessor();
Integer port = processor.getConfig().getHttpPort();
Integer httpsPort = processor.getConfig().getHttpsPort();
action = action.replace(":" + Integer.toString(port) + "/",
":" + Integer.toString(httpsPort) + "/");
return action;
}
but the modification of the getUrl() method of SecureBufferedWebResponse
doesn't seem to affect the request for the CSS file, but only for the URLs
of links and buttons in the page (the debugger never entered that point in
that request). I'll continue trying it and modifications and keep this
thread informed up-to-date.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3015404.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: SSL Links and buttons
action (I get them from my
> Application class with custom methods).
>
> and the annotation @SemiSecurePage is not needed at all, since it will enter
> the ifs the same, so you can freely remove it.
>
> The issue is that when validation fails, it does not find the CSS because my
> browser is requesting it without the context (e.g.
> http://localhost:9090/styles/main/layout.css instead of
> http://localhost:9090/myapplication/styles/main/layout.css). Does not it
> happen to you? How can I fix that? When does Wicket establish the URL for
> static resources like that this? I'm adding it this way:
>
> add(CSSPackageResource.getHeaderContribution("styles/main/layout.css"));
>
> The rest of the solution works great, I didn't have much time to inspect it
> (I can see the tricky parts :) ) and to check how much
> wicket-version-dependent it can be, but I think it's OK (since it's
> working!).
>
> So the only thing is to fix the CSS issue, do you have any idea of how...?
> Thank you
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3014970.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: SSL Links and buttons
Hi,
I just added
https://issues.apache.org/jira/browse/WICKET-3133
Other answers inline:
> I tried your code and it's working for me, just with one issue I mention at
> the end of this post. I had to make just 3 modifications: the method
> resolve() stays like this:
>
> public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
> {
>
> // if (portConfig.isPreferStateful()) {
> Session.get().bind();
> // }
>
> IRequestTarget target = super.resolve(rc, rp);
> return checkSecure(target);
> }
>
> because I can not find the isPreferStateful() method, and the SecureForm
> onComponentTag() is like this:
>
This method may have been added after 1.4.9: I'm using 1.4.12.
> @Override
> protected void onComponentTag(ComponentTag tag) {
> super.onComponentTag(tag);
> String action = tag.getAttribute("action");
> action = RequestUtils.toAbsolutePath(action);
> if(!action.startsWith("https")) {
> action = "https" + action.substring(4);
> action =
> action.replace(String.valueOf(MeteosixApplication.get().getHttpPort()),
>
> String.valueOf(MeteosixApplication.get().getHttpsPort()));
> }
> tag.put("action", action);
> }
>
> to also substitute the port numbers in the action (I get them from my
> Application class with custom methods).
Ok. That might be a good addition if we want to have some generic solution.
>
> and the annotation @SemiSecurePage is not needed at all, since it will enter
> the ifs the same, so you can freely remove it.
I just added it as an extra check so that we don't have to inspect all
IListenerInterfaceRequestTarget.
>
> The issue is that when validation fails, it does not find the CSS because my
> browser is requesting it without the context (e.g.
> http://localhost:9090/styles/main/layout.css instead of
> http://localhost:9090/myapplication/styles/main/layout.css). Does not it
> happen to you? How can I fix that? When does Wicket establish the URL for
> static resources like that this? I'm adding it this way:
>
> add(CSSPackageResource.getHeaderContribution("styles/main/layout.css"));
>
No this do happens to me: I will try to do some experiments to see
what is missing
Can you try to replace method SecureBufferedWebResponse.getUrl with
protected String getUrl(String protocol, Integer port,
HttpServletRequest request, String queryString)
{
if(queryString.startsWith("http") ||
queryString.startsWith("https"))
return queryString;
StringBuilder result = new StringBuilder();
result.append(protocol);
result.append("://");
result.append(request.getServerName());
if (port != null)
{
result.append(":");
result.append(port);
}
String path = request.getContextPath();
if(path != null && path.length()>0) {
result.append(path);
}
result.append(request.getRequestURI());
if (queryString != null)
{
if(queryString.startsWith("..") ) {
} else if(!queryString.startsWith("?"))
result.append("?");
result.append(queryString);
}
return result.toString();
}
and see if it works now?
> The rest of the solution works great, I didn't have much time to inspect it
> (I can see the tricky parts :) ) and to check how much
> wicket-version-dependent it can be, but I think it's OK (since it's
> working!).
IMHO: It will be very nice if this "corner" use case is included on
default HttpsRequestCycleProcessor. Will try to produce a patch and
attach it issue mentioned before.
No thanks needed: we all benefit from this discussion;-)
Regards,
Ernesto
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: SSL Links and buttons
Hi Ernesto,
I tried your code and it's working for me, just with one issue I mention at
the end of this post. I had to make just 3 modifications: the method
resolve() stays like this:
public IRequestTarget resolve(RequestCycle rc, RequestParameters rp)
{
// if (portConfig.isPreferStateful()) {
Session.get().bind();
// }
IRequestTarget target = super.resolve(rc, rp);
return checkSecure(target);
}
because I can not find the isPreferStateful() method, and the SecureForm
onComponentTag() is like this:
@Override
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
String action = tag.getAttribute("action");
action = RequestUtils.toAbsolutePath(action);
if(!action.startsWith("https")) {
action = "https" + action.substring(4);
action =
action.replace(String.valueOf(MeteosixApplication.get().getHttpPort()),
String.valueOf(MeteosixApplication.get().getHttpsPort()));
}
tag.put("action", action);
}
to also substitute the port numbers in the action (I get them from my
Application class with custom methods).
and the annotation @SemiSecurePage is not needed at all, since it will enter
the ifs the same, so you can freely remove it.
The issue is that when validation fails, it does not find the CSS because my
browser is requesting it without the context (e.g.
http://localhost:9090/styles/main/layout.css instead of
http://localhost:9090/myapplication/styles/main/layout.css). Does not it
happen to you? How can I fix that? When does Wicket establish the URL for
static resources like that this? I'm adding it this way:
add(CSSPackageResource.getHeaderContribution("styles/main/layout.css"));
The rest of the solution works great, I didn't have much time to inspect it
(I can see the tricky parts :) ) and to check how much
wicket-version-dependent it can be, but I think it's OK (since it's
working!).
So the only thing is to fix the CSS issue, do you have any idea of how...?
Thank you
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3014970.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: SSL Links and buttons
t the > sign-in form (included in quite some http-pages) work over https. > Any ideas? > If there's a core developer reading this, is there any plan of "extending" > the @RequireHttps annotation to other Components rather than just pages? > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3001634.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: SSL Links and buttons
ing and > secureForm.hasError() always return false, no matter there are even > wicket-validation errors or not. > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3013201.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: SSL Links and buttons
Hi Ernesto and others, Yes that's what I mentioned before, I'm able to do what you say, or to redirect to the HTTP page but not showing the validation errors, but not both HTTP and show errors. By the way, if you check for secureForm.hasError(), will it catch a situation where there's not literally a validation error but a business-logic error? (e.g. when, in the onSubmit() method of your login form, you check that the password is incorrect, it's not a wicket-validation error, and then you invoke "manually" the error() method of the panel containing the form to show the message but not the error() method of the form itself). Will it detect those situations? I'm trying and secureForm.hasError() always return false, no matter there are even wicket-validation errors or not. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3013201.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: SSL Links and buttons
Hi,
I'm also interested on solving this as I will need to implement a
similar use case in a coming application. The main problem I see in
solving it is that on
protected IRequestTarget checkSecureOutgoing(IRequestTarget target) {
}
even if you check for ListenerInterfaceRequestTarget and your Secure form e.g.
if (target instanceof IListenerInterfaceRequestTarget) {
IListenerInterfaceRequestTarget
interfaceRequestTarget =
(IListenerInterfaceRequestTarget) target;
Component c =
interfaceRequestTarget.getTarget();
if(SecureForm.class.isAssignableFrom(c.getClass())) {
SecureForm secureForm =
(SecureForm)c;
if(secureForm.hasError()) {
return target;
}
}
}
, to return the same target when you have validation errors,
ListenerInterfaceRequestTarget seem to be using logic from
PageRequestTarget
public void respond(RequestCycle requestCycle)
{
// Should page be redirected to?
if (requestCycle.isRedirect())
{
// Redirect to the page
requestCycle.redirectTo(page);
}
else
{
// Let page render itself
page.renderPage();
}
}
to redirect to a "new" version of the page and as the request arrives
over HTTPS then you get redirected to the page, showing validation
errors, but over "https". I don't see yet how to switch it to HTTP.
Regards,
Ernesto
On Mon, Oct 25, 2010 at 8:58 AM, sonxurxo wrote:
>
> Hi all.
> I've been dealing with this and I don't have a working solution yet. The
> problem that my previously posted solution had is that when the form
> validation fails, it falls into an infinite redirect loop.
> Playing with my custom HttpsRequestCycleProcessor all I have achieved is to
> make it redirect to the right page, but "in its HTTPS version", when it
> should be HTTP (remember, HTTPS form embedded in a HTTP page). Or if I point
> my custom HttpsRequestCycleProcessor to redirect it to the HTTP version, it
> falls in that infinite redirect cycle or it loose the form data.
> Any hint? Any idea? How could I override checkSecureIncoming and
> checkSecureOutgoing methods to be aware of those situations? Thank you in
> advance
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3009814.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: SSL Links and buttons
Hi all. I've been dealing with this and I don't have a working solution yet. The problem that my previously posted solution had is that when the form validation fails, it falls into an infinite redirect loop. Playing with my custom HttpsRequestCycleProcessor all I have achieved is to make it redirect to the right page, but "in its HTTPS version", when it should be HTTP (remember, HTTPS form embedded in a HTTP page). Or if I point my custom HttpsRequestCycleProcessor to redirect it to the HTTP version, it falls in that infinite redirect cycle or it loose the form data. Any hint? Any idea? How could I override checkSecureIncoming and checkSecureOutgoing methods to be aware of those situations? Thank you in advance -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3009814.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: SSL Links and buttons
I localized an error in my solution: when validation fails, it enters an
infinite loop of redirects through:
[...]
if (this.isSecureFormRequest(target)) {
redirect = SwitchProtocolRequestTarget.requireProtocol(Protocol.HTTPS);
}
[...]
I don't know how to make it stop when validation fails on that form. If you
have any hints, thank you in advance. If I find a solution I'll also post it
here, of course. Thanks
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005514.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: SSL Links and buttons
By the way, now that it's done and supposing it's OK, wouldn't be a good idea to include something like that in the trunk? Or maybe in an extension? Maybe do the same with some links? It's just an idea, I'm surprised not a lot of people had to lead with this. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005352.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: SSL Links and buttons
Hi all,
I think I finally have the solution, thanks everyone who guide me. Please
correct me if I'm missing something, I tested it quite well and everything
is OK. What I do is the following:
- I have my custom SecureForm class (inherits from Form), as I mentioned
before. It overrides the onComponentTag(ComponentTag tag) method to force it
to use HTTPS. The forms I want to use HTTPS inherit from that class.
- I wrote a custom MyHttpsRequestCycleProcessor, which extends
HttpsRequestCycleProcessor, and rewrites hasSecureAnnotation() and
getPageClass() (leaving them exactly as in HttpsRequestCycleProcessor class,
it's just because they are private and I need them). I create this utility
method:
private boolean isSecureFormRequest(IRequestTarget target) {
if (target instanceof ListenerInterfaceRequestTarget) {
Component c = ((ListenerInterfaceRequestTarget)
target).getTarget();
return SecureForm.class.isAssignableFrom(c.getClass());
}
return false;
}
and override (now actually modifying) the checkSecureIncoming() method. It
now looks like as follows:
protected IRequestTarget checkSecureIncoming(IRequestTarget target) {
if (target != null && target instanceof
SwitchProtocolRequestTarget) {
return target;
}
if (getConfig() == null) {
return target;
}
Class pageClass = getPageClass(target);
if (pageClass != null) {
IRequestTarget redirect = null;
if (hasSecureAnnotation(pageClass) ||
this.isSecureFormRequest(target)) {
redirect =
SwitchProtocolRequestTarget.requireProtocol(Protocol.HTTPS);
} else {
redirect =
SwitchProtocolRequestTarget.requireProtocol(Protocol.HTTP);
}
if (redirect != null) {
return redirect;
}
}
return target;
}
What I do is force HTTPS redirect not only when I find the @HttpsRequired
annotation in the Page, but also when a request is made trough an instance
of SecureForm or any of its possible subclasses.
What's your opinion? Am I missing something? Did I break something that I'll
realize in some weeks? Thank you very much for your very useful help, I just
had to put pieces together!!
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005339.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: SSL Links and buttons
On Thu, Oct 21, 2010 at 11:30 AM, sonxurxo wrote: > > Thank you all for your responses. > Yes, I was thinking about that. How could I achieve that? > I'd like to be able to access the form that generated the request through > the target parameter, but it's not visible. If I could, I'd determine if > it's an instance of my custom SecureForm class and process the request > properly. > Also, I see that when the form is sent using POST, the target argument > received in the checkSecureIncoming(IRequestTarget target) method is an > instance of BookmarkablePageRequestTarget, and I can access there to the > POST parameters which get lost after the redirect, but I don't know what > can > I do with them to keep them, and even more, I don't know if the things I do > there may interfer with other normal request processing. Any hints to do > that? Thanks > >From the current request you can check the protocol (https), the parameters (their names are specific for that form, I guess) and if you recognize that this is the special case then just suppress the normal checkSecureIncoming() (it is protected, so you can provide your own impl). So the POST request will not be immediately redirected to GET, but it will be processed. -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005272.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: SSL Links and buttons
Thank you all for your responses. Yes, I was thinking about that. How could I achieve that? I'd like to be able to access the form that generated the request through the target parameter, but it's not visible. If I could, I'd determine if it's an instance of my custom SecureForm class and process the request properly. Also, I see that when the form is sent using POST, the target argument received in the checkSecureIncoming(IRequestTarget target) method is an instance of BookmarkablePageRequestTarget, and I can access there to the POST parameters which get lost after the redirect, but I don't know what can I do with them to keep them, and even more, I don't know if the things I do there may interfer with other normal request processing. Any hints to do that? Thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005272.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: SSL Links and buttons
Then maybe you'll need to modify org.apache.wicket.protocol.https.HttpsRequestCycleProcessor.checkSecureIncoming(IRequestTarget) to your needs. On Thu, Oct 21, 2010 at 9:56 AM, sonxurxo wrote: > > I use some secure pages annotated with @RequireHttps, but not all the pages > where the login panel will be. For example, the main page or the "general > info page" will be no secured, but the login panel will be there in both > pages. There are also other "profile-dependent" pages that are of course > full secured, and others -as I mentioned in an older post, the registration > page is an example-. > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005153.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: SSL Links and buttons
I use some secure pages annotated with @RequireHttps, but not all the pages where the login panel will be. For example, the main page or the "general info page" will be no secured, but the login panel will be there in both pages. There are also other "profile-dependent" pages that are of course full secured, and others -as I mentioned in an older post, the registration page is an example-. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005153.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: SSL Links and buttons
Since you don't use secure Pages (pages with @RequireHttps) then I see no reason to register HttpsRequestCycleProcessor. On Thu, Oct 21, 2010 at 9:24 AM, sonxurxo wrote: > > Yes, the HttpsRequestCycleProcessor is doing a redirect from HTTPS to HTTP, > both using "POST" and "GET" methods (btw Melinda, as you pointed, this last > ones preserves the values as it was expected but I can not use this > way...). > Is there anything I can do to avoid that? The > checkSecureIncoming(IRequestTarget target) method of that class checks only > that the class (or its superinterfaces) are annotated with RequireHttps, > and > if not, redirects to HTTP. Is there something I can do to sent the form > with > POST? Thank you again in advance > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005126.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: SSL Links and buttons
Yes, the HttpsRequestCycleProcessor is doing a redirect from HTTPS to HTTP, both using "POST" and "GET" methods (btw Melinda, as you pointed, this last ones preserves the values as it was expected but I can not use this way...). Is there anything I can do to avoid that? The checkSecureIncoming(IRequestTarget target) method of that class checks only that the class (or its superinterfaces) are annotated with RequireHttps, and if not, redirects to HTTP. Is there something I can do to sent the form with POST? Thank you again in advance -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3005126.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: SSL Links and buttons
look at the requests and make sure that the httpsrequestcycleprocessor
is not doing a secure->unsecure redirect which would lose the form
values.
-igor
On Wed, Oct 20, 2010 at 12:05 AM, sonxurxo wrote:
>
> Hi Igor, thank you for your response.
>
> I tried what you pointed. The action URL in the form is correctly replaced,
> since I can see it with Firebug. And even Wicket receives the request when
> pressing the submit button, but it fails on validating required fields: it
> does not receive the values, neither with theFormField.getInput() (returns
> "") nor theFormField.getDefaultModelObjectAsString() (returns null).
> Just in case it matters, I'm trying it both with Jetty (http port:9090,
> https port:8443) and with Tomcat (http port:80 -with mod_jk, https
> port:443), so I modified the onComponentTag method you post and my
> SecureForm class now looks like:
>
>
> public class SecureForm extends Form {
>
> public SecureForm(String id) {
> super(id);
> }
>
> �...@override
> protected void onComponentTag(ComponentTag tag) {
> super.onComponentTag(tag);
> String action = tag.getAttribute("action");
> action = RequestUtils.toAbsolutePath(action);
> action = "https" + action.substring(4);
> action = action.replace(MyApplication.get().getHttpPort(),
> MyApplication.get().getHttpsPort());
> tag.put("action", action);
> }
> }
>
>
> but that modification doesn't seem to be a problem since the action URL
> looks OK in both cases (the port number is well replaced). Debugging with
> Firebug I can see that the field values are correctly sent by POST.
> More possible important info: the form is included in a Page that is NOT
> annotated with @RequireHttps.
>
> Am I missing something? Any ideas? Thank you in advance.
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3003364.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: SSL Links and buttons
Thank you Melinda for your response, I didn't try that because, even when querystring (and therefore GET parameters are too) is secured with SSL, there are some reasons that point that it's a bad idea (look at the first answer at http://stackoverflow.com/questions/323200/is-a-https-query-string-secure). Thank you anyway :) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3003805.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: SSL Links and buttons
Can you try using
E.M.D
On Wed, Oct 20, 2010 at 9:05 AM, sonxurxo wrote:
>
> Hi Igor, thank you for your response.
>
> I tried what you pointed. The action URL in the form is correctly replaced,
> since I can see it with Firebug. And even Wicket receives the request when
> pressing the submit button, but it fails on validating required fields: it
> does not receive the values, neither with theFormField.getInput() (returns
> "") nor theFormField.getDefaultModelObjectAsString() (returns null).
> Just in case it matters, I'm trying it both with Jetty (http port:9090,
> https port:8443) and with Tomcat (http port:80 -with mod_jk, https
> port:443), so I modified the onComponentTag method you post and my
> SecureForm class now looks like:
>
>
> public class SecureForm extends Form {
>
>public SecureForm(String id) {
>super(id);
>}
>
>@Override
>protected void onComponentTag(ComponentTag tag) {
>super.onComponentTag(tag);
>String action = tag.getAttribute("action");
>action = RequestUtils.toAbsolutePath(action);
>action = "https" + action.substring(4);
>action = action.replace(MyApplication.get().getHttpPort(),
>MyApplication.get().getHttpsPort());
>tag.put("action", action);
>}
> }
>
>
> but that modification doesn't seem to be a problem since the action URL
> looks OK in both cases (the port number is well replaced). Debugging with
> Firebug I can see that the field values are correctly sent by POST.
> More possible important info: the form is included in a Page that is NOT
> annotated with @RequireHttps.
>
> Am I missing something? Any ideas? Thank you in advance.
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3003364.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: SSL Links and buttons
Hi Igor, thank you for your response.
I tried what you pointed. The action URL in the form is correctly replaced,
since I can see it with Firebug. And even Wicket receives the request when
pressing the submit button, but it fails on validating required fields: it
does not receive the values, neither with theFormField.getInput() (returns
"") nor theFormField.getDefaultModelObjectAsString() (returns null).
Just in case it matters, I'm trying it both with Jetty (http port:9090,
https port:8443) and with Tomcat (http port:80 -with mod_jk, https
port:443), so I modified the onComponentTag method you post and my
SecureForm class now looks like:
public class SecureForm extends Form {
public SecureForm(String id) {
super(id);
}
@Override
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
String action = tag.getAttribute("action");
action = RequestUtils.toAbsolutePath(action);
action = "https" + action.substring(4);
action = action.replace(MyApplication.get().getHttpPort(),
MyApplication.get().getHttpsPort());
tag.put("action", action);
}
}
but that modification doesn't seem to be a problem since the action URL
looks OK in both cases (the port number is well replaced). Debugging with
Firebug I can see that the field values are correctly sent by POST.
More possible important info: the form is included in a Page that is NOT
annotated with @RequireHttps.
Am I missing something? Any ideas? Thank you in advance.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3003364.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: SSL Links and buttons
so far i dont think there are any plans to support ssl forms outside
of @RequireHttps
here is something that might work for you though:
class secureform extends form {
oncomponenttag(tag) {
super.oncomponenttag(tag);
string act=tag.get('action");
act=rqeuestutils.toabsoluteurl(act);
act="https"+act.substring(4);
tag.put("action", act);
}
}
-igor
On Tue, Oct 19, 2010 at 1:15 AM, sonxurxo wrote:
>
> Hi all,
> This question applies to Wicket 1.4.9.
> I have an app where I have a Sign-in component (Panel) that is shown in
> (almost) every page of the site. I'd like all the app to work over http, and
> that form to work over https. Since the @RequireHttps annotation only works
> on pages and not Components, how can I achieve that?
> I have some other pages (e.g. registration page) that is fully working over
> https with the mentioned annotation, everything is OK. But I can not get the
> sign-in form (included in quite some http-pages) work over https.
> Any ideas?
> If there's a core developer reading this, is there any plan of "extending"
> the @RequireHttps annotation to other Components rather than just pages?
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3001634.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
SSL Links and buttons
Hi all, This question applies to Wicket 1.4.9. I have an app where I have a Sign-in component (Panel) that is shown in (almost) every page of the site. I'd like all the app to work over http, and that form to work over https. Since the @RequireHttps annotation only works on pages and not Components, how can I achieve that? I have some other pages (e.g. registration page) that is fully working over https with the mentioned annotation, everything is OK. But I can not get the sign-in form (included in quite some http-pages) work over https. Any ideas? If there's a core developer reading this, is there any plan of "extending" the @RequireHttps annotation to other Components rather than just pages? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/SSL-Links-and-buttons-tp3001634p3001634.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: Submitting form via AJAX over SSL - RESEND
see HttpsRequestCycleProcessor -igor On Tue, Jul 20, 2010 at 7:12 AM, Jeffrey Schneller wrote: > > How can I submit a form via AJAX over SSL? I have a login form that > appears via Ajax and I want the form submission to be under SSL when it > is submitted via AJAX. How can I go about doing this? > > > > Thanks. > > > > > > > > > - > 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
Submitting form via AJAX over SSL - RESEND
How can I submit a form via AJAX over SSL? I have a login form that appears via Ajax and I want the form submission to be under SSL when it is submitted via AJAX. How can I go about doing this? Thanks. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Submitting form via AJAX over SSL
How can I submit a form via AJAX over SSL? I have a login form that appears via Ajax and I want the form submission to be under SSL when it is submitted via AJAX. How can I go about doing this? Thanks.
Re: mod_proxy + ssl + HttpsRequestCycleProcessor
The solution seems to be an extra header with the mod_header module and an extra filter before the wicket filter. With the later we can check the extra header, and overwrite the scheme to "https" if the header is present. Seems to be working for now... Regards, Istvan On Thu, Mar 4, 2010 at 6:04 PM, Istvan Soos wrote: > Hi, > > We are using HttpsRequestCycleProcessor + @RequireHttps annotation in > our local dev environment (the server is a jetty executed directly > from Eclipse). In the production environment, we have Apache + > mod_proxy, and I'd prefer if Apache could handle the SSL part (in that > case we are not required to configure SSL on the application server - > glassfish v3). Is there any best practice how to achieve this? > > Thanks and regards, > Istvan > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: mod_proxy + ssl + HttpsRequestCycleProcessor
That is ok, however in production I still would like to benefit of the @RequireHttps. Will it work? I suppose there should be a setup that uses mod_headers to inject a header in the request or something like that, but I'm only guessing this... Istvan On Thu, Mar 4, 2010 at 6:23 PM, Josh Chappelle wrote: > In your Application class you could check to see if you are running in > Production or Development mode. If you are running in Development mode then > use the HttpsRequestCycleProcessor. Otherwise use the default > RequestCycleProcessor. > > Josh > > -Original Message- > From: Istvan Soos [mailto:istvan.s...@gmail.com] > Sent: Thursday, March 04, 2010 11:05 AM > To: users@wicket.apache.org > Subject: mod_proxy + ssl + HttpsRequestCycleProcessor > > Hi, > > We are using HttpsRequestCycleProcessor + @RequireHttps annotation in > our local dev environment (the server is a jetty executed directly > from Eclipse). In the production environment, we have Apache + > mod_proxy, and I'd prefer if Apache could handle the SSL part (in that > case we are not required to configure SSL on the application server - > glassfish v3). Is there any best practice how to achieve this? > > Thanks and regards, > Istvan > > - > 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
RE: mod_proxy + ssl + HttpsRequestCycleProcessor
In your Application class you could check to see if you are running in Production or Development mode. If you are running in Development mode then use the HttpsRequestCycleProcessor. Otherwise use the default RequestCycleProcessor. Josh -Original Message- From: Istvan Soos [mailto:istvan.s...@gmail.com] Sent: Thursday, March 04, 2010 11:05 AM To: users@wicket.apache.org Subject: mod_proxy + ssl + HttpsRequestCycleProcessor Hi, We are using HttpsRequestCycleProcessor + @RequireHttps annotation in our local dev environment (the server is a jetty executed directly from Eclipse). In the production environment, we have Apache + mod_proxy, and I'd prefer if Apache could handle the SSL part (in that case we are not required to configure SSL on the application server - glassfish v3). Is there any best practice how to achieve this? Thanks and regards, Istvan - 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
mod_proxy + ssl + HttpsRequestCycleProcessor
Hi, We are using HttpsRequestCycleProcessor + @RequireHttps annotation in our local dev environment (the server is a jetty executed directly from Eclipse). In the production environment, we have Apache + mod_proxy, and I'd prefer if Apache could handle the SSL part (in that case we are not required to configure SSL on the application server - glassfish v3). Is there any best practice how to achieve this? Thanks and regards, Istvan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proxying SSL on Apache to HTTP on Jetty + Wicket
Thanks Nino, you are correct.
In the Jetty tutorial says:
"...extending the Connector class of your choice, eg the
SelectChannelConnector, and implement the customize..."
public void customize(org.mortbay.io.EndPoint endpoint, Request
request) throws IOException
{
request.setScheme("https");
super.customize(endpoint, request);
}
but this don't work and i change to:
public void customize(final EndPoint endpoint, final Request
request) throws IOException {
super.customize(endpoint, request);
if ("https".equals(request.getHeader("scheme"))) {
request.setScheme("https");
}
}
Now this works. Thanks Nino.
2009/11/11 nino martinez wael :
> I think last time this came up it ended out being some issue with jetty?
>
> 2009/11/11 Rangel Preis
>
>> I extends HttpsRequestCycleProcessor and SwitchProtocolRequestTarget
>> to make my custom HttpsRequestCycleProcessor
>> In the method getUrl from SwitchProtocolRequestTarget i just remove the
>> port:
>>
>> if (port != null) {
>> result.append(":");
>> result.append(port);
>> }
>>
>> But don't work, the url are correct but the page don't load i think i
>> miss something in apache.
>>
>> Anyone make something like this?
>>
>> Thanks.
>>
>> 2009/11/10 Rangel Preis :
>> > The unique solution that i found is extends HttpsRequestCycleProcessor
>> > to change only the protocol.
>> >
>> > Any other ideia? Thanks All.
>> >
>> > 2009/11/10 Rangel Preis :
>> >> The situation here is:
>> >>
>> >> https http
>> >> -> Apache ---> Jetty
>> >>
>> >>
>> >> Using wicket in my WicketApplication I put
>> >>
>> >> private static final HttpsConfig HTTPS_CONFIG = new
>> >> HttpsConfig(HTTP_PORT, HTTPS_PORT);
>> >>
>> >> �...@override
>> >> protected IRequestCycleProcessor newRequestCycleProcessor() {
>> >> return new HttpsRequestCycleProcessor(HTTPS_CONFIG);
>> >> }
>> >>
>> >> And in my LoginPage.java i have @RequireHttps
>> >>
>> >> When i try to run the system with this config i get a error because
>> >> Wicket assumes the HTTPS control and try to change the URL (port and
>> >> replace http to https)
>> >>
>> >> How i say to wicket to just change the protocol to HTTPS? And don't
>> >> change the port?
>> >>
>> >> Thanks
>> >>
>> >
>>
>> -
>> 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: Proxying SSL on Apache to HTTP on Jetty + Wicket
I think last time this came up it ended out being some issue with jetty?
2009/11/11 Rangel Preis
> I extends HttpsRequestCycleProcessor and SwitchProtocolRequestTarget
> to make my custom HttpsRequestCycleProcessor
> In the method getUrl from SwitchProtocolRequestTarget i just remove the
> port:
>
> if (port != null) {
> result.append(":");
> result.append(port);
> }
>
> But don't work, the url are correct but the page don't load i think i
> miss something in apache.
>
> Anyone make something like this?
>
> Thanks.
>
> 2009/11/10 Rangel Preis :
> > The unique solution that i found is extends HttpsRequestCycleProcessor
> > to change only the protocol.
> >
> > Any other ideia? Thanks All.
> >
> > 2009/11/10 Rangel Preis :
> >> The situation here is:
> >>
> >> https http
> >> -> Apache ---> Jetty
> >>
> >>
> >> Using wicket in my WicketApplication I put
> >>
> >> private static final HttpsConfig HTTPS_CONFIG = new
> >> HttpsConfig(HTTP_PORT, HTTPS_PORT);
> >>
> >>@Override
> >>protected IRequestCycleProcessor newRequestCycleProcessor() {
> >>return new HttpsRequestCycleProcessor(HTTPS_CONFIG);
> >>}
> >>
> >> And in my LoginPage.java i have @RequireHttps
> >>
> >> When i try to run the system with this config i get a error because
> >> Wicket assumes the HTTPS control and try to change the URL (port and
> >> replace http to https)
> >>
> >> How i say to wicket to just change the protocol to HTTPS? And don't
> >> change the port?
> >>
> >> Thanks
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Proxying SSL on Apache to HTTP on Jetty + Wicket
I extends HttpsRequestCycleProcessor and SwitchProtocolRequestTarget
to make my custom HttpsRequestCycleProcessor
In the method getUrl from SwitchProtocolRequestTarget i just remove the port:
if (port != null) {
result.append(":");
result.append(port);
}
But don't work, the url are correct but the page don't load i think i
miss something in apache.
Anyone make something like this?
Thanks.
2009/11/10 Rangel Preis :
> The unique solution that i found is extends HttpsRequestCycleProcessor
> to change only the protocol.
>
> Any other ideia? Thanks All.
>
> 2009/11/10 Rangel Preis :
>> The situation here is:
>>
>> https http
>> -> Apache ---> Jetty
>>
>>
>> Using wicket in my WicketApplication I put
>>
>> private static final HttpsConfig HTTPS_CONFIG = new
>> HttpsConfig(HTTP_PORT, HTTPS_PORT);
>>
>> �...@override
>> protected IRequestCycleProcessor newRequestCycleProcessor() {
>> return new HttpsRequestCycleProcessor(HTTPS_CONFIG);
>> }
>>
>> And in my LoginPage.java i have @RequireHttps
>>
>> When i try to run the system with this config i get a error because
>> Wicket assumes the HTTPS control and try to change the URL (port and
>> replace http to https)
>>
>> How i say to wicket to just change the protocol to HTTPS? And don't
>> change the port?
>>
>> Thanks
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proxying SSL on Apache to HTTP on Jetty + Wicket
The unique solution that i found is extends HttpsRequestCycleProcessor
to change only the protocol.
Any other ideia? Thanks All.
2009/11/10 Rangel Preis :
> The situation here is:
>
> https http
> -> Apache ---> Jetty
>
>
> Using wicket in my WicketApplication I put
>
> private static final HttpsConfig HTTPS_CONFIG = new
> HttpsConfig(HTTP_PORT, HTTPS_PORT);
>
> �...@override
> protected IRequestCycleProcessor newRequestCycleProcessor() {
> return new HttpsRequestCycleProcessor(HTTPS_CONFIG);
> }
>
> And in my LoginPage.java i have @RequireHttps
>
> When i try to run the system with this config i get a error because
> Wicket assumes the HTTPS control and try to change the URL (port and
> replace http to https)
>
> How i say to wicket to just change the protocol to HTTPS? And don't
> change the port?
>
> Thanks
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Proxying SSL on Apache to HTTP on Jetty + Wicket
The situation here is:
https http
-> Apache ---> Jetty
Using wicket in my WicketApplication I put
private static final HttpsConfig HTTPS_CONFIG = new
HttpsConfig(HTTP_PORT, HTTPS_PORT);
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new HttpsRequestCycleProcessor(HTTPS_CONFIG);
}
And in my LoginPage.java i have @RequireHttps
When i try to run the system with this config i get a error because
Wicket assumes the HTTPS control and try to change the URL (port and
replace http to https)
How i say to wicket to just change the protocol to HTTPS? And don't
change the port?
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Modal window and SSL
Still have some problems.
we use Wicket 1.3.6
This is the JS for creating the modal:
if (Wicket.Browser.isIELessThan7() ||
!Wicket.Browser.isIE()) {
s+= ""+
"";
} else {
s+= ""+
"";
}
I changed also the src to 0: without success. (after looking at
WICKET-855<https://issues.apache.org/jira/browse/WICKET-855>
)
Igor,
there is no call to any resource that is in an http:// path.
Please advice,
Eyal Golan
egola...@gmail.com
Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74
P Save a tree. Please don't print this e-mail unless it's really necessary
On Wed, Aug 19, 2009 at 11:49 PM, Eyal Golan wrote:
> Thanks Igor and Peter.Peter,
> we did change the JS that builds the ModalWindow. I'll look into it.
> Thanks,
>
> Eyal Golan
> egola...@gmail.com
>
> Visit: http://jvdrums.sourceforge.net/
> LinkedIn: http://www.linkedin.com/in/egolan74
>
> P Save a tree. Please don't print this e-mail unless it's really necessary
>
>
> On Wed, Aug 19, 2009 at 8:56 PM, Peter Ertl wrote:
>
>> I remember this issue begin fixed already:
>> https://issues.apache.org/jira/browse/WICKET-855
>>
>> did someone change ModalWindow in the meantime?
>>
>> Am 19.08.2009 um 17:13 schrieb Igor Vaynberg:
>>
>>
>> it just means that you are on a https page but it links to some http
>>> resources, eg images or javascripts.
>>>
>>> so make sure when you are on a https page all your resources are
>>> brought in via relative urls and do not start with http://
>>>
>>> one specific example is that you can be on an https page but you
>>> include an website analytics script via an http url.
>>>
>>> -igor
>>>
>>> On Wed, Aug 19, 2009 at 4:51 AM, Eyal Golan wrote:
>>>
>>>> Hello all,
>>>> We are having a problem when we work on an SSL environment.
>>>> Whenever we open a modal popup window, there's this annoying message of
>>>> IE
>>>> that the user is trying to open both secure and non secure content.
>>>> We changed the IE settings and the message is gone.
>>>> But I want to understand what's causing it?
>>>>
>>>> I googled a bit about it and found some tips on changing the
>>>> IREquestCycleProcessor:
>>>> http://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html
>>>> It this what we should do?
>>>>
>>>> BTW,
>>>> does anyone know how to run the embedded Jetty with SSL?
>>>>
>>>> Thanks
>>>>
>>>> Eyal Golan
>>>> egola...@gmail.com
>>>>
>>>> Visit: http://jvdrums.sourceforge.net/
>>>> LinkedIn: http://www.linkedin.com/in/egolan74
>>>>
>>>> P Save a tree. Please don't print this e-mail unless it's really
>>>> necessary
>>>>
>>>>
>>> -
>>> 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: Modal window and SSL
Thanks Igor and Peter.Peter, we did change the JS that builds the ModalWindow. I'll look into it. Thanks, Eyal Golan egola...@gmail.com Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 P Save a tree. Please don't print this e-mail unless it's really necessary On Wed, Aug 19, 2009 at 8:56 PM, Peter Ertl wrote: > I remember this issue begin fixed already: > https://issues.apache.org/jira/browse/WICKET-855 > > did someone change ModalWindow in the meantime? > > Am 19.08.2009 um 17:13 schrieb Igor Vaynberg: > > > it just means that you are on a https page but it links to some http >> resources, eg images or javascripts. >> >> so make sure when you are on a https page all your resources are >> brought in via relative urls and do not start with http:// >> >> one specific example is that you can be on an https page but you >> include an website analytics script via an http url. >> >> -igor >> >> On Wed, Aug 19, 2009 at 4:51 AM, Eyal Golan wrote: >> >>> Hello all, >>> We are having a problem when we work on an SSL environment. >>> Whenever we open a modal popup window, there's this annoying message of >>> IE >>> that the user is trying to open both secure and non secure content. >>> We changed the IE settings and the message is gone. >>> But I want to understand what's causing it? >>> >>> I googled a bit about it and found some tips on changing the >>> IREquestCycleProcessor: >>> http://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html >>> It this what we should do? >>> >>> BTW, >>> does anyone know how to run the embedded Jetty with SSL? >>> >>> Thanks >>> >>> Eyal Golan >>> egola...@gmail.com >>> >>> Visit: http://jvdrums.sourceforge.net/ >>> LinkedIn: http://www.linkedin.com/in/egolan74 >>> >>> P Save a tree. Please don't print this e-mail unless it's really >>> necessary >>> >>> >> - >> 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: Modal window and SSL
I remember this issue begin fixed already: https://issues.apache.org/jira/browse/WICKET-855 did someone change ModalWindow in the meantime? Am 19.08.2009 um 17:13 schrieb Igor Vaynberg: it just means that you are on a https page but it links to some http resources, eg images or javascripts. so make sure when you are on a https page all your resources are brought in via relative urls and do not start with http:// one specific example is that you can be on an https page but you include an website analytics script via an http url. -igor On Wed, Aug 19, 2009 at 4:51 AM, Eyal Golan wrote: Hello all, We are having a problem when we work on an SSL environment. Whenever we open a modal popup window, there's this annoying message of IE that the user is trying to open both secure and non secure content. We changed the IE settings and the message is gone. But I want to understand what's causing it? I googled a bit about it and found some tips on changing the IREquestCycleProcessor: http://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html It this what we should do? BTW, does anyone know how to run the embedded Jetty with SSL? Thanks Eyal Golan egola...@gmail.com Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 P Save a tree. Please don't print this e-mail unless it's really necessary - 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: Modal window and SSL
it just means that you are on a https page but it links to some http resources, eg images or javascripts. so make sure when you are on a https page all your resources are brought in via relative urls and do not start with http:// one specific example is that you can be on an https page but you include an website analytics script via an http url. -igor On Wed, Aug 19, 2009 at 4:51 AM, Eyal Golan wrote: > Hello all, > We are having a problem when we work on an SSL environment. > Whenever we open a modal popup window, there's this annoying message of IE > that the user is trying to open both secure and non secure content. > We changed the IE settings and the message is gone. > But I want to understand what's causing it? > > I googled a bit about it and found some tips on changing the > IREquestCycleProcessor: > http://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html > It this what we should do? > > BTW, > does anyone know how to run the embedded Jetty with SSL? > > Thanks > > Eyal Golan > egola...@gmail.com > > Visit: http://jvdrums.sourceforge.net/ > LinkedIn: http://www.linkedin.com/in/egolan74 > > P Save a tree. Please don't print this e-mail unless it's really necessary > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Modal window and SSL
Hello all, We are having a problem when we work on an SSL environment. Whenever we open a modal popup window, there's this annoying message of IE that the user is trying to open both secure and non secure content. We changed the IE settings and the message is gone. But I want to understand what's causing it? I googled a bit about it and found some tips on changing the IREquestCycleProcessor: http://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html It this what we should do? BTW, does anyone know how to run the embedded Jetty with SSL? Thanks Eyal Golan egola...@gmail.com Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 P Save a tree. Please don't print this e-mail unless it's really necessary
Re: SSL on pages
s/SecureRequestCycleProcessor/HttpsRequestCycleProcessor/ the javadoc of which shows how to install it -igor On Sun, Aug 9, 2009 at 9:37 AM, hill180 wrote: > I looked at that and found the sample code for this in the Javadocs, > unfortunately got stuck at SecureRequestCycleProcessor > > In the java docs, it has this a class to instantiate, but either I am > supposed to create something and extend another class, or something... > either way, I can't get passed this. currently I am just using the web.xml > method but would like to use the @RequireHttps annotation. > > jose > > On Aug 9, 2009, at 9:26 AM, Igor Vaynberg wrote: > >> see @RequireHttps >> >> -igor >> >> On Sat, Aug 8, 2009 at 12:34 PM, Jose Hernandez >> wrote: >>> >>> What is the recommended method on securing certain pages via SSL with >>> Wicket >>> 1.4.0? >>> >>> Thanks! >>> >>> jose >>> >>> >>> >>> >>> - >>> 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
Re: SSL on pages
I looked at that and found the sample code for this in the Javadocs, unfortunately got stuck at SecureRequestCycleProcessor In the java docs, it has this a class to instantiate, but either I am supposed to create something and extend another class, or something... either way, I can't get passed this. currently I am just using the web.xml method but would like to use the @RequireHttps annotation. jose On Aug 9, 2009, at 9:26 AM, Igor Vaynberg wrote: see @RequireHttps -igor On Sat, Aug 8, 2009 at 12:34 PM, Jose Hernandez wrote: What is the recommended method on securing certain pages via SSL with Wicket 1.4.0? Thanks! jose - 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: SSL on pages
see @RequireHttps -igor On Sat, Aug 8, 2009 at 12:34 PM, Jose Hernandez wrote: > What is the recommended method on securing certain pages via SSL with Wicket > 1.4.0? > > Thanks! > > jose > > > > > - > 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
SSL on pages
What is the recommended method on securing certain pages via SSL with Wicket 1.4.0? Thanks! jose - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Require SSL and 1.4.0
As a new user, I am not sure I understand, I need to setup
@requireHTTPS to work and I have the following Code:
What am I doing wrong? I have Wicket 1.4.0
"error SecureRequestCycleProcessor cannot be resolved to a type"
package com.test.sslstuff2;
import org.apache.wicket.protocol.http.WebApplication;
import org.apache.wicket.protocol.https.HttpsConfig;
import org.apache.wicket.request.IRequestCycleProcessor;
/**
* Application object for your web application. If you want to run
this application without deploying, run the Start class.
*
* @see com.test.sslstuff2.Start#main(String[])
*/
public class WicketApplication extends WebApplication
{
public WicketApplication()
{
}
@Override
protected IRequestCycleProcessor newRequestCycleProcessor()
{
HttpsConfig config = new HttpsConfig(80,443);
return new SecureRequestCycleProcessor(config);
}
public Class getHomePage()
{
return HomePage.class;
}
}
and the Home Page:
package com.test.sslstuff2;
import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.protocol.https.RequireHttps;
/**
* Homepage
*/
@RequireHttps
public class HomePage extends WebPage {
private static final long serialVersionUID = 1L;
public HomePage(final PageParameters parameters) {
add(new Label("message", "If you see this message wicket is properly
configured and running"));
}
}
THANKS
Require SSL and 1.4.0
As a new user, I am not sure I understand, I need to setup
@requireHTTPS to work and I have the following Code:
What am I doing wrong? I have Wicket 1.4.0
"error SecureRequestCycleProcessor cannot be resolved to a type"
package com.test.sslstuff2;
import org.apache.wicket.protocol.http.WebApplication;
import org.apache.wicket.protocol.https.HttpsConfig;
import org.apache.wicket.request.IRequestCycleProcessor;
/**
* Application object for your web application. If you want to run
this application without deploying, run the Start class.
*
* @see com.test.sslstuff2.Start#main(String[])
*/
public class WicketApplication extends WebApplication
{
public WicketApplication()
{
}
@Override
protected IRequestCycleProcessor newRequestCycleProcessor()
{
HttpsConfig config = new HttpsConfig(80,443);
return new SecureRequestCycleProcessor(config);
}
public Class getHomePage()
{
return HomePage.class;
}
}
and the Home Page:
package com.test.sslstuff2;
import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.protocol.https.RequireHttps;
/**
* Homepage
*/
@RequireHttps
public class HomePage extends WebPage {
private static final long serialVersionUID = 1L;
public HomePage(final PageParameters parameters) {
add(new Label("message", "If you see this message wicket is properly
configured and running"));
}
}
THANKS
Re: AW: SSL - ajax login
according to some, it has to do with non-port 80 requests appearing more suspicous that port-80, and just in combination with firefox <= 3.0. did you try deploying your site to http://localhost:80 and https://localhost:443 ? this worked for me. firefox 3.5 did not complain about port 8080/8443 though. i have no idea. you might want to google it. -igor On Tue, Jul 28, 2009 at 1:43 AM, Arthur Leigh Allen wrote: i use my own (graphic) buttons in wicket. after getting rid of my own code and just using a modified AjaxFallbackButton with overridden getCallbackUrl() method, the form was submitted but i could see an error in the error console of firefox (translated by me): security error: content from http://localhost:8080/projectname/?wicket:interface=:0:2::: is not allowed to load data from https://localhost:8443/projectname/?wicket:interface=:0:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:2:IBehaviorListener:0:&random=0.573852961623538 error: uncaught exception: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "http://localhost:8080/projectname/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js Line: 884"] - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AW: SSL - ajax login
i have no idea. you might want to google it.
-igor
On Tue, Jul 28, 2009 at 1:43 AM, Arthur Leigh
Allen wrote:
> i use my own (graphic) buttons in wicket.
> after getting rid of my own code and just using a modified AjaxFallbackButton
> with overridden getCallbackUrl() method,
> the form was submitted but i could see an error in the error console of
> firefox (translated by me):
>
> security error: content from
> http://localhost:8080/projectname/?wicket:interface=:0:2::: is not allowed to
> load data from
> https://localhost:8443/projectname/?wicket:interface=:0:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:2:IBehaviorListener:0:&random=0.573852961623538
>
> error: uncaught exception: [Exception... "Access to restricted URI denied"
> code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location:
> "http://localhost:8080/projectname/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
> Line: 884"]
>
> is it about cross domain (http and https) AJAX queries?
>
>
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Montag, den 27. Juli 2009, 18:24:20 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> hmm, it might be like you said - ajax request with an untrusted cert
> might be failing.
>
> it looks from the console like wicket is trying to hit that url, what
> you can do is set a breakpoint in wicketfilter and see if that request
> ever reaches the server.
>
> -igor
>
> On Mon, Jul 27, 2009 at 4:56 AM, Arthur Leigh
> Allen wrote:
>> Hi again Igor,
>>
>> I did the following now:
>> I called the website directly with https://localhost:8443/projectname and
>> then I performed a login and it worked.
>>
>> Any idea?
>>
>> Thx Arthur
>>
>>
>>
>>
>>
>> Von: Igor Vaynberg
>> An: users@wicket.apache.org
>> Gesendet: Sonntag, den 26. Juli 2009, 22:22:22 Uhr
>> Betreff: Re: AW: SSL - ajax login
>>
>> the href is not a problem; you seeing # appended to the end of the url
>> is the correct behavior. what should have happened was the ajax call
>> to that https url in the background.
>>
>> so what you should be looking into is why the ajax call with that
>> https url was never made or response from it not processed, since we
>> know the url itself works - because you pasted it into the browser and
>> it worked. maybe wicket ajax console can give you a clue, firebug also
>> has facilities that let you monitor requests being made. you should
>> see a call to that https url when you click the link.
>>
>> -igor
>>
>> On Sun, Jul 26, 2009 at 1:15 PM, Arthur Leigh
>> Allen wrote:
>>> Hi Igor,
>>>
>>> I used Firebug to have a look at the onClick event.
>>> I've inspected two links, one usual ajax link and one for the ssl login.
>>>
>>>
>>>
>>> Regarding the first link:
>>> href="?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::ILinkListener::"
>>>
>>> onClick="var
>>> wcall=wicketAjaxGet('?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::IBehaviorListener:0:',null,null,
>>> function() {return Wicket.$('link141') != null;}.bind(this));return
>>> !wcall;"
>>>
>>>
>>>
>>> Regarding the ssl login link:
>>> href="#"
>>>
>>> onClick="var wcall=wicketSubmitFormById('loginForm13b',
>>> 'https://localhost:8443/projectname/?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true',
>>> 'buttonLogin:container:link' ,null,null, function() {return
>>> Wicket.$$(this)&&Wicket.$$('loginForm13b')}.bind(this));;; return false;"
>>>
>>>
>>>
>>> I clicked on the ssl login link and the page jumped to the anchor # but the
>>> form is not submitted. The symbol # was appended to the address bar of the
>>> browser.
>>> I copied the url in the onClick event and entered it manually in the
>>> address bar of my browser. The xml code for the ajax response was shown in
>>> the browser - as known from wicket ajax debug.
>>>
>>> I guess the problem is the href attribute. I would expect to see
AW: AW: SSL - ajax login
i use my own (graphic) buttons in wicket.
after getting rid of my own code and just using a modified AjaxFallbackButton
with overridden getCallbackUrl() method,
the form was submitted but i could see an error in the error console of firefox
(translated by me):
security error: content from
http://localhost:8080/projectname/?wicket:interface=:0:2::: is not allowed to
load data from
https://localhost:8443/projectname/?wicket:interface=:0:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:2:IBehaviorListener:0:&random=0.573852961623538
error: uncaught exception: [Exception... "Access to restricted URI denied"
code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location:
"http://localhost:8080/projectname/resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
Line: 884"]
is it about cross domain (http and https) AJAX queries?
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Montag, den 27. Juli 2009, 18:24:20 Uhr
Betreff: Re: AW: SSL - ajax login
hmm, it might be like you said - ajax request with an untrusted cert
might be failing.
it looks from the console like wicket is trying to hit that url, what
you can do is set a breakpoint in wicketfilter and see if that request
ever reaches the server.
-igor
On Mon, Jul 27, 2009 at 4:56 AM, Arthur Leigh
Allen wrote:
> Hi again Igor,
>
> I did the following now:
> I called the website directly with https://localhost:8443/projectname and
> then I performed a login and it worked.
>
> Any idea?
>
> Thx Arthur
>
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Sonntag, den 26. Juli 2009, 22:22:22 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> the href is not a problem; you seeing # appended to the end of the url
> is the correct behavior. what should have happened was the ajax call
> to that https url in the background.
>
> so what you should be looking into is why the ajax call with that
> https url was never made or response from it not processed, since we
> know the url itself works - because you pasted it into the browser and
> it worked. maybe wicket ajax console can give you a clue, firebug also
> has facilities that let you monitor requests being made. you should
> see a call to that https url when you click the link.
>
> -igor
>
> On Sun, Jul 26, 2009 at 1:15 PM, Arthur Leigh
> Allen wrote:
>> Hi Igor,
>>
>> I used Firebug to have a look at the onClick event.
>> I've inspected two links, one usual ajax link and one for the ssl login.
>>
>>
>>
>> Regarding the first link:
>> href="?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::ILinkListener::"
>>
>> onClick="var
>> wcall=wicketAjaxGet('?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::IBehaviorListener:0:',null,null,
>> function() {return Wicket.$('link141') != null;}.bind(this));return !wcall;"
>>
>>
>>
>> Regarding the ssl login link:
>> href="#"
>>
>> onClick="var wcall=wicketSubmitFormById('loginForm13b',
>> 'https://localhost:8443/projectname/?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true',
>> 'buttonLogin:container:link' ,null,null, function() {return
>> Wicket.$$(this)&&Wicket.$$('loginForm13b')}.bind(this));;; return false;"
>>
>>
>>
>> I clicked on the ssl login link and the page jumped to the anchor # but the
>> form is not submitted. The symbol # was appended to the address bar of the
>> browser.
>> I copied the url in the onClick event and entered it manually in the address
>> bar of my browser. The xml code for the ajax response was shown in the
>> browser - as known from wicket ajax debug.
>>
>> I guess the problem is the href attribute. I would expect to see an url like
>> https://localhost:8443/projectname/wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::
>> [etc.]
>>
>> Do you have any idea how I can solve the problem?
>>
>> Thx,
>> Arthur
>>
>>
>>
>>
>>
>>
>>
>>
>> Von: Igor Vaynberg
>> An: users@wicket.apache.org
>> Gesendet: Freitag, den 24. Juli 2009, 21:51:48 Uhr
>> Betreff: Re: AW: SSL - ajax login
>>
>>
Re: AW: SSL - ajax login
hmm, it might be like you said - ajax request with an untrusted cert
might be failing.
it looks from the console like wicket is trying to hit that url, what
you can do is set a breakpoint in wicketfilter and see if that request
ever reaches the server.
-igor
On Mon, Jul 27, 2009 at 4:56 AM, Arthur Leigh
Allen wrote:
> Hi again Igor,
>
> I did the following now:
> I called the website directly with https://localhost:8443/projectname and
> then I performed a login and it worked.
>
> Any idea?
>
> Thx Arthur
>
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Sonntag, den 26. Juli 2009, 22:22:22 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> the href is not a problem; you seeing # appended to the end of the url
> is the correct behavior. what should have happened was the ajax call
> to that https url in the background.
>
> so what you should be looking into is why the ajax call with that
> https url was never made or response from it not processed, since we
> know the url itself works - because you pasted it into the browser and
> it worked. maybe wicket ajax console can give you a clue, firebug also
> has facilities that let you monitor requests being made. you should
> see a call to that https url when you click the link.
>
> -igor
>
> On Sun, Jul 26, 2009 at 1:15 PM, Arthur Leigh
> Allen wrote:
>> Hi Igor,
>>
>> I used Firebug to have a look at the onClick event.
>> I've inspected two links, one usual ajax link and one for the ssl login.
>>
>>
>>
>> Regarding the first link:
>> href="?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::ILinkListener::"
>>
>> onClick="var
>> wcall=wicketAjaxGet('?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::IBehaviorListener:0:',null,null,
>> function() {return Wicket.$('link141') != null;}.bind(this));return !wcall;"
>>
>>
>>
>> Regarding the ssl login link:
>> href="#"
>>
>> onClick="var wcall=wicketSubmitFormById('loginForm13b',
>> 'https://localhost:8443/projectname/?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true',
>> 'buttonLogin:container:link' ,null,null, function() {return
>> Wicket.$$(this)&&Wicket.$$('loginForm13b')}.bind(this));;; return false;"
>>
>>
>>
>> I clicked on the ssl login link and the page jumped to the anchor # but the
>> form is not submitted. The symbol # was appended to the address bar of the
>> browser.
>> I copied the url in the onClick event and entered it manually in the address
>> bar of my browser. The xml code for the ajax response was shown in the
>> browser - as known from wicket ajax debug.
>>
>> I guess the problem is the href attribute. I would expect to see an url like
>> https://localhost:8443/projectname/wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::
>> [etc.]
>>
>> Do you have any idea how I can solve the problem?
>>
>> Thx,
>> Arthur
>>
>>
>>
>>
>>
>>
>>
>>
>> Von: Igor Vaynberg
>> An: users@wicket.apache.org
>> Gesendet: Freitag, den 24. Juli 2009, 21:51:48 Uhr
>> Betreff: Re: AW: SSL - ajax login
>>
>> whatever url you see when hovering over the link is not the url used
>> for ajax - not necessarily. you should inspect the onclick handlers.
>>
>> -igor
>>
>> On Fri, Jul 24, 2009 at 12:20 PM, Arthur Leigh
>> Allen wrote:
>>> no, sorry... the url is not changing to http://locahost:8080/projectname/#
>>> but when I hold the mouse pointer over the link, I see the url in the
>>> status bar. When I hold the mouse pointer over other links, I see very long
>>> urls a la
>>> http://localhost:8080/projectname/;jsessionid=wicket:interface.
>>>
>>> But as you suggested, I'll debug the javascript to see the url
>>> modifications.
>>> Thank you for your support Igor!
>>>
>>> Have a nice weekend.
>>> Greetz, Arthur
>>>
>>>
>>>
>>>
>>> Von: Igor Vaynberg
>>> An: users@wicket.apache.org
>>> Gesendet: Freitag, den 24. Juli 2009, 17:30:27 Uhr
&g
AW: AW: SSL - ajax login
Hi again Igor,
I did the following now:
I called the website directly with https://localhost:8443/projectname and then
I performed a login and it worked.
Any idea?
Thx Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Sonntag, den 26. Juli 2009, 22:22:22 Uhr
Betreff: Re: AW: SSL - ajax login
the href is not a problem; you seeing # appended to the end of the url
is the correct behavior. what should have happened was the ajax call
to that https url in the background.
so what you should be looking into is why the ajax call with that
https url was never made or response from it not processed, since we
know the url itself works - because you pasted it into the browser and
it worked. maybe wicket ajax console can give you a clue, firebug also
has facilities that let you monitor requests being made. you should
see a call to that https url when you click the link.
-igor
On Sun, Jul 26, 2009 at 1:15 PM, Arthur Leigh
Allen wrote:
> Hi Igor,
>
> I used Firebug to have a look at the onClick event.
> I've inspected two links, one usual ajax link and one for the ssl login.
>
>
>
> Regarding the first link:
> href="?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::ILinkListener::"
>
> onClick="var
> wcall=wicketAjaxGet('?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::IBehaviorListener:0:',null,null,
> function() {return Wicket.$('link141') != null;}.bind(this));return !wcall;"
>
>
>
> Regarding the ssl login link:
> href="#"
>
> onClick="var wcall=wicketSubmitFormById('loginForm13b',
> 'https://localhost:8443/projectname/?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true',
> 'buttonLogin:container:link' ,null,null, function() {return
> Wicket.$$(this)&&Wicket.$$('loginForm13b')}.bind(this));;; return false;"
>
>
>
> I clicked on the ssl login link and the page jumped to the anchor # but the
> form is not submitted. The symbol # was appended to the address bar of the
> browser.
> I copied the url in the onClick event and entered it manually in the address
> bar of my browser. The xml code for the ajax response was shown in the
> browser - as known from wicket ajax debug.
>
> I guess the problem is the href attribute. I would expect to see an url like
> https://localhost:8443/projectname/wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::
> [etc.]
>
> Do you have any idea how I can solve the problem?
>
> Thx,
> Arthur
>
>
>
>
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Freitag, den 24. Juli 2009, 21:51:48 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> whatever url you see when hovering over the link is not the url used
> for ajax - not necessarily. you should inspect the onclick handlers.
>
> -igor
>
> On Fri, Jul 24, 2009 at 12:20 PM, Arthur Leigh
> Allen wrote:
>> no, sorry... the url is not changing to http://locahost:8080/projectname/#
>> but when I hold the mouse pointer over the link, I see the url in the status
>> bar. When I hold the mouse pointer over other links, I see very long urls a
>> la http://localhost:8080/projectname/;jsessionid=wicket:interface.
>>
>> But as you suggested, I'll debug the javascript to see the url modifications.
>> Thank you for your support Igor!
>>
>> Have a nice weekend.
>> Greetz, Arthur
>>
>>
>>
>>
>> Von: Igor Vaynberg
>> An: users@wicket.apache.org
>> Gesendet: Freitag, den 24. Juli 2009, 17:30:27 Uhr
>> Betreff: Re: AW: SSL - ajax login
>>
>> no, i havent tried it myself. i never had to do an ajax login.
>>
>> the url in the browser changes to http://locahost:8080/projectname/# ?
>> thats fine. the main part is what the actual ajax url is used - you
>> wont see that in the browser's bar. i suggest you use firebug or
>> something similar to walk the javascript and see why your *ajax* url
>> is being mangled.
>>
>> obviously if you return just "https://localhost:8443/projectname"; that
>> will not work because that doesnt have the listener interface target
>> that will hit the behavior in your button.
>>
>> -igor
>>
>>
>> On Fri, Jul 24, 2009 at 2:19 AM, Arthur Leigh
>> Allen w
AW: AW: SSL - ajax login
I'll try to find out more.
Here is the output from wicket debug console:
---
SSL-Link clicked:
INFO: focus set on link34
INFO: Using XMLHttpRequest transport
INFO:
INFO: Initiating Ajax POST request on
https://localhost:8443/projectname/;jsessionid=039EAC776571BA623EA885F798AC6A10?wicket:interface=:0:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::IBehaviorListener:0:&random=0.30097839823986994
INFO: Invoking pre-call handler(s)... (<-- no answer/response)
INFO: focus removed from link76
INFO: focus set on link7b
INFO: Channel busy - postponing... (<-- shown when a different link is clicked)
Usual Link clicked:
INFO: focus set on link7b
INFO: Using XMLHttpRequest transport
INFO:
INFO: Initiating Ajax GET request on
?wicket:interface=:2:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::IBehaviorListener:0:&random=0.39846398226416335
INFO: Invoking pre-call handler(s)...
INFO: Received ajax response (20795 characters)
INFO:
...
INFO: Response parsed. Now invoking steps...
INFO: setHistoryItem: 1
INFO: setHistoryItem: 2
INFO: Response processed successfully.
INFO: Invoking post-call handler(s)...
INFO: Couldn't set focus on not on the page anymore
---
btw: I'm using an own made ssl certificate for testing purposes, so it's not
trustable.
Could it be because of that?
For example: When using a non ajax ssl link the browser (IE) ask me if I'd like
to proceed.
Only if I proceed, the website is loaded/shown.
If it's an ajax ssl call, maybe there is no way to ask the user whether he want
to proceed or not.
Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Sonntag, den 26. Juli 2009, 22:22:22 Uhr
Betreff: Re: AW: SSL - ajax login
the href is not a problem; you seeing # appended to the end of the url
is the correct behavior. what should have happened was the ajax call
to that https url in the background.
so what you should be looking into is why the ajax call with that
https url was never made or response from it not processed, since we
know the url itself works - because you pasted it into the browser and
it worked. maybe wicket ajax console can give you a clue, firebug also
has facilities that let you monitor requests being made. you should
see a call to that https url when you click the link.
-igor
On Sun, Jul 26, 2009 at 1:15 PM, Arthur Leigh
Allen wrote:
> Hi Igor,
>
> I used Firebug to have a look at the onClick event.
> I've inspected two links, one usual ajax link and one for the ssl login.
>
>
>
> Regarding the first link:
> href="?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::ILinkListener::"
>
> onClick="var
> wcall=wicketAjaxGet('?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::IBehaviorListener:0:',null,null,
> function() {return Wicket.$('link141') != null;}.bind(this));return !wcall;"
>
>
>
> Regarding the ssl login link:
> href="#"
>
> onClick="var wcall=wicketSubmitFormById('loginForm13b',
> 'https://localhost:8443/projectname/?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true',
> 'buttonLogin:container:link' ,null,null, function() {return
> Wicket.$$(this)&&Wicket.$$('loginForm13b')}.bind(this));;; return false;"
>
>
>
> I clicked on the ssl login link and the page jumped to the anchor # but the
> form is not submitted. The symbol # was appended to the address bar of the
> browser.
> I copied the url in the onClick event and entered it manually in the address
> bar of my browser. The xml code for the ajax response was shown in the
> browser - as known from wicket ajax debug.
>
> I guess the problem is the href attribute. I would expect to see an url like
> https://localhost:8443/projectname/wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::
> [etc.]
>
> Do you have any idea how I can solve the problem?
>
> Thx,
> Arthur
>
>
>
>
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Freitag, den 24. Juli 2009, 21:51:48 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> whatever url you see when hovering over the link is not the url used
> for ajax - not necessarily. you should inspect the onclick handlers.
>
> -igor
>
> On Fri, Jul 24, 2009 at 12:20 PM, Arthur Leigh
> Allen wrote:
>> no, sorry... the url is not changing to http://locahost:8080/proj
Re: AW: SSL - ajax login
the href is not a problem; you seeing # appended to the end of the url
is the correct behavior. what should have happened was the ajax call
to that https url in the background.
so what you should be looking into is why the ajax call with that
https url was never made or response from it not processed, since we
know the url itself works - because you pasted it into the browser and
it worked. maybe wicket ajax console can give you a clue, firebug also
has facilities that let you monitor requests being made. you should
see a call to that https url when you click the link.
-igor
On Sun, Jul 26, 2009 at 1:15 PM, Arthur Leigh
Allen wrote:
> Hi Igor,
>
> I used Firebug to have a look at the onClick event.
> I've inspected two links, one usual ajax link and one for the ssl login.
>
>
>
> Regarding the first link:
> href="?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::ILinkListener::"
>
> onClick="var
> wcall=wicketAjaxGet('?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::IBehaviorListener:0:',null,null,
> function() {return Wicket.$('link141') != null;}.bind(this));return !wcall;"
>
>
>
> Regarding the ssl login link:
> href="#"
>
> onClick="var wcall=wicketSubmitFormById('loginForm13b',
> 'https://localhost:8443/projectname/?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true',
> 'buttonLogin:container:link' ,null,null, function() {return
> Wicket.$$(this)&&Wicket.$$('loginForm13b')}.bind(this));;; return false;"
>
>
>
> I clicked on the ssl login link and the page jumped to the anchor # but the
> form is not submitted. The symbol # was appended to the address bar of the
> browser.
> I copied the url in the onClick event and entered it manually in the address
> bar of my browser. The xml code for the ajax response was shown in the
> browser - as known from wicket ajax debug.
>
> I guess the problem is the href attribute. I would expect to see an url like
> https://localhost:8443/projectname/wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::
> [etc.]
>
> Do you have any idea how I can solve the problem?
>
> Thx,
> Arthur
>
>
>
>
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Freitag, den 24. Juli 2009, 21:51:48 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> whatever url you see when hovering over the link is not the url used
> for ajax - not necessarily. you should inspect the onclick handlers.
>
> -igor
>
> On Fri, Jul 24, 2009 at 12:20 PM, Arthur Leigh
> Allen wrote:
>> no, sorry... the url is not changing to http://locahost:8080/projectname/#
>> but when I hold the mouse pointer over the link, I see the url in the status
>> bar. When I hold the mouse pointer over other links, I see very long urls a
>> la http://localhost:8080/projectname/;jsessionid=wicket:interface.
>>
>> But as you suggested, I'll debug the javascript to see the url modifications.
>> Thank you for your support Igor!
>>
>> Have a nice weekend.
>> Greetz, Arthur
>>
>>
>>
>>
>> Von: Igor Vaynberg
>> An: users@wicket.apache.org
>> Gesendet: Freitag, den 24. Juli 2009, 17:30:27 Uhr
>> Betreff: Re: AW: SSL - ajax login
>>
>> no, i havent tried it myself. i never had to do an ajax login.
>>
>> the url in the browser changes to http://locahost:8080/projectname/# ?
>> thats fine. the main part is what the actual ajax url is used - you
>> wont see that in the browser's bar. i suggest you use firebug or
>> something similar to walk the javascript and see why your *ajax* url
>> is being mangled.
>>
>> obviously if you return just "https://localhost:8443/projectname"; that
>> will not work because that doesnt have the listener interface target
>> that will hit the behavior in your button.
>>
>> -igor
>>
>>
>> On Fri, Jul 24, 2009 at 2:19 AM, Arthur Leigh
>> Allen wrote:
>>> Hi Igor,
>>>
>>> I tried to do it as simple as possible so I returned
>>> https://localhost:8443/projectname in the overridden method getCallbackUrl
>>> of AjaxFormSubmitBehavior. The result was the same. The link pointed to the
>>> url http://locahost:8080/projectname/#. It seems
AW: AW: SSL - ajax login
btw: the xml code I saw showed me, that the login was successfully executed because login content was presented in the xml code. Von: Igor Vaynberg An: users@wicket.apache.org Gesendet: Freitag, den 24. Juli 2009, 21:51:48 Uhr Betreff: Re: AW: SSL - ajax login whatever url you see when hovering over the link is not the url used for ajax - not necessarily. you should inspect the onclick handlers. -igor On Fri, Jul 24, 2009 at 12:20 PM, Arthur Leigh Allen wrote: > no, sorry... the url is not changing to http://locahost:8080/projectname/# > but when I hold the mouse pointer over the link, I see the url in the status > bar. When I hold the mouse pointer over other links, I see very long urls a > la http://localhost:8080/projectname/;jsessionid=wicket:interface. > > But as you suggested, I'll debug the javascript to see the url modifications. > Thank you for your support Igor! > > Have a nice weekend. > Greetz, Arthur > > > > > Von: Igor Vaynberg > An: users@wicket.apache.org > Gesendet: Freitag, den 24. Juli 2009, 17:30:27 Uhr > Betreff: Re: AW: SSL - ajax login > > no, i havent tried it myself. i never had to do an ajax login. > > the url in the browser changes to http://locahost:8080/projectname/# ? > thats fine. the main part is what the actual ajax url is used - you > wont see that in the browser's bar. i suggest you use firebug or > something similar to walk the javascript and see why your *ajax* url > is being mangled. > > obviously if you return just "https://localhost:8443/projectname"; that > will not work because that doesnt have the listener interface target > that will hit the behavior in your button. > > -igor > > > On Fri, Jul 24, 2009 at 2:19 AM, Arthur Leigh > Allen wrote: >> Hi Igor, >> >> I tried to do it as simple as possible so I returned >> https://localhost:8443/projectname in the overridden method getCallbackUrl >> of AjaxFormSubmitBehavior. The result was the same. The link pointed to the >> url http://locahost:8080/projectname/#. It seems to me that only relative >> pathes can be returned, else the standard url will be used. >> >> I wanted to understand how the given url is used in wicket. I found the >> method wicketAjaxGet in wicket-ajax.js. There the url is passed to >> Wicket.Ajax.Call(...). I couldn't trace the call deeper because I couldn't >> find Call() in any javascript file. >> >> Have you tried it yourself Igor? Does it work? >> I'm using wicket 1.3.5. Does it depend on the version I use? >> >> Is there a different entry point to manipulate the url for ajax calls? >> >> Thx again >> Arthur >> >> >> >> >> Von: Igor Vaynberg >> An: users@wicket.apache.org >> Gesendet: Donnerstag, den 23. Juli 2009, 16:37:22 Uhr >> Betreff: Re: AW: SSL - ajax login >> >> javascript invokes the url you give it, so it looked like it should >> work. you might have to trace deeper to see whats going on. >> >> -igor >> >> On Thu, Jul 23, 2009 at 4:41 AM, Arthur Leigh >> Allen wrote: >>> Hi Igor, >>> >>> I did it as you said. >>> I took the code from AjaxFallbackButton and I copied it to an own class. >>> In the constructor I overwrite the getCallbackUrl() method of the >>> AjaxFormSubmitBehavior. >>> I added the value https://localhost:8443/projectname/ as a prefix to >>> super.getCallbackUrl(). >>> By the way: getCallbackUrl() returns a long relative url beginning with >>> ";sessionid". >>> So my url is https://localhost:8443/projectname/;sessionid... >>> >>> When starting tomcat and accessing the website, the url wasn't applied. >>> When clicking the link, the url http://localhost:8080/projectname/# was >>> called. >>> I believe it's the wrong place to manipulate the url. Maybe it is expected >>> to return a relative path >>> beginning with ";sessionid". That url is maybe manipulated at a different >>> place, so in my case the >>> end result would be >>> http://localhost:8080/projectname/https://localhost:8443/projectname/;sessionid. >>> That would result in an error and maybe >>> http://localhost:8080/projectname/# is used therefore. >>> >>> Am I wrong? >>> >>> Thx >>> Arthur >>> >>> >>> >>> >>> >>> Von: Igor Vaynberg >>> An: users@wick
AW: AW: SSL - ajax login
Hi Igor,
I used Firebug to have a look at the onClick event.
I've inspected two links, one usual ajax link and one for the ssl login.
Regarding the first link:
href="?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::ILinkListener::"
onClick="var
wcall=wicketAjaxGet('?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:linkForgotLogin:container:link::IBehaviorListener:0:',null,null,
function() {return Wicket.$('link141') != null;}.bind(this));return !wcall;"
Regarding the ssl login link:
href="#"
onClick="var wcall=wicketSubmitFormById('loginForm13b',
'https://localhost:8443/projectname/?wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true',
'buttonLogin:container:link' ,null,null, function() {return
Wicket.$$(this)&&Wicket.$$('loginForm13b')}.bind(this));;; return false;"
I clicked on the ssl login link and the page jumped to the anchor # but the
form is not submitted. The symbol # was appended to the address bar of the
browser.
I copied the url in the onClick event and entered it manually in the address
bar of my browser. The xml code for the ajax response was shown in the browser
- as known from wicket ajax debug.
I guess the problem is the href attribute. I would expect to see an url like
https://localhost:8443/projectname/wicket:interface=:6:content:container:areaTop:2:panelTop:container:loginForm:buttonLogin:container:link::
[etc.]
Do you have any idea how I can solve the problem?
Thx,
Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Freitag, den 24. Juli 2009, 21:51:48 Uhr
Betreff: Re: AW: SSL - ajax login
whatever url you see when hovering over the link is not the url used
for ajax - not necessarily. you should inspect the onclick handlers.
-igor
On Fri, Jul 24, 2009 at 12:20 PM, Arthur Leigh
Allen wrote:
> no, sorry... the url is not changing to http://locahost:8080/projectname/#
> but when I hold the mouse pointer over the link, I see the url in the status
> bar. When I hold the mouse pointer over other links, I see very long urls a
> la http://localhost:8080/projectname/;jsessionid=wicket:interface.
>
> But as you suggested, I'll debug the javascript to see the url modifications.
> Thank you for your support Igor!
>
> Have a nice weekend.
> Greetz, Arthur
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Freitag, den 24. Juli 2009, 17:30:27 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> no, i havent tried it myself. i never had to do an ajax login.
>
> the url in the browser changes to http://locahost:8080/projectname/# ?
> thats fine. the main part is what the actual ajax url is used - you
> wont see that in the browser's bar. i suggest you use firebug or
> something similar to walk the javascript and see why your *ajax* url
> is being mangled.
>
> obviously if you return just "https://localhost:8443/projectname"; that
> will not work because that doesnt have the listener interface target
> that will hit the behavior in your button.
>
> -igor
>
>
> On Fri, Jul 24, 2009 at 2:19 AM, Arthur Leigh
> Allen wrote:
>> Hi Igor,
>>
>> I tried to do it as simple as possible so I returned
>> https://localhost:8443/projectname in the overridden method getCallbackUrl
>> of AjaxFormSubmitBehavior. The result was the same. The link pointed to the
>> url http://locahost:8080/projectname/#. It seems to me that only relative
>> pathes can be returned, else the standard url will be used.
>>
>> I wanted to understand how the given url is used in wicket. I found the
>> method wicketAjaxGet in wicket-ajax.js. There the url is passed to
>> Wicket.Ajax.Call(...). I couldn't trace the call deeper because I couldn't
>> find Call() in any javascript file.
>>
>> Have you tried it yourself Igor? Does it work?
>> I'm using wicket 1.3.5. Does it depend on the version I use?
>>
>> Is there a different entry point to manipulate the url for ajax calls?
>>
>> Thx again
>> Arthur
>>
>>
>>
>>
>> Von: Igor Vaynberg
>> An: users@wicket.apache.org
>> Gesendet: Donnerstag, den 23. Juli 2009, 16:37:22 Uhr
>> Betreff: Re: AW: SSL - ajax login
>>
>> javascript invokes the url you give it, so it looked like it should
>> work. you might have to trace deeper to see whats going on.
>>
>> -igor
>&g
Re: AW: SSL - ajax login
whatever url you see when hovering over the link is not the url used for ajax - not necessarily. you should inspect the onclick handlers. -igor On Fri, Jul 24, 2009 at 12:20 PM, Arthur Leigh Allen wrote: > no, sorry... the url is not changing to http://locahost:8080/projectname/# > but when I hold the mouse pointer over the link, I see the url in the status > bar. When I hold the mouse pointer over other links, I see very long urls a > la http://localhost:8080/projectname/;jsessionid=wicket:interface. > > But as you suggested, I'll debug the javascript to see the url modifications. > Thank you for your support Igor! > > Have a nice weekend. > Greetz, Arthur > > > > > Von: Igor Vaynberg > An: users@wicket.apache.org > Gesendet: Freitag, den 24. Juli 2009, 17:30:27 Uhr > Betreff: Re: AW: SSL - ajax login > > no, i havent tried it myself. i never had to do an ajax login. > > the url in the browser changes to http://locahost:8080/projectname/# ? > thats fine. the main part is what the actual ajax url is used - you > wont see that in the browser's bar. i suggest you use firebug or > something similar to walk the javascript and see why your *ajax* url > is being mangled. > > obviously if you return just "https://localhost:8443/projectname"; that > will not work because that doesnt have the listener interface target > that will hit the behavior in your button. > > -igor > > > On Fri, Jul 24, 2009 at 2:19 AM, Arthur Leigh > Allen wrote: >> Hi Igor, >> >> I tried to do it as simple as possible so I returned >> https://localhost:8443/projectname in the overridden method getCallbackUrl >> of AjaxFormSubmitBehavior. The result was the same. The link pointed to the >> url http://locahost:8080/projectname/#. It seems to me that only relative >> pathes can be returned, else the standard url will be used. >> >> I wanted to understand how the given url is used in wicket. I found the >> method wicketAjaxGet in wicket-ajax.js. There the url is passed to >> Wicket.Ajax.Call(...). I couldn't trace the call deeper because I couldn't >> find Call() in any javascript file. >> >> Have you tried it yourself Igor? Does it work? >> I'm using wicket 1.3.5. Does it depend on the version I use? >> >> Is there a different entry point to manipulate the url for ajax calls? >> >> Thx again >> Arthur >> >> >> >> >> Von: Igor Vaynberg >> An: users@wicket.apache.org >> Gesendet: Donnerstag, den 23. Juli 2009, 16:37:22 Uhr >> Betreff: Re: AW: SSL - ajax login >> >> javascript invokes the url you give it, so it looked like it should >> work. you might have to trace deeper to see whats going on. >> >> -igor >> >> On Thu, Jul 23, 2009 at 4:41 AM, Arthur Leigh >> Allen wrote: >>> Hi Igor, >>> >>> I did it as you said. >>> I took the code from AjaxFallbackButton and I copied it to an own class. >>> In the constructor I overwrite the getCallbackUrl() method of the >>> AjaxFormSubmitBehavior. >>> I added the value https://localhost:8443/projectname/ as a prefix to >>> super.getCallbackUrl(). >>> By the way: getCallbackUrl() returns a long relative url beginning with >>> ";sessionid". >>> So my url is https://localhost:8443/projectname/;sessionid... >>> >>> When starting tomcat and accessing the website, the url wasn't applied. >>> When clicking the link, the url http://localhost:8080/projectname/# was >>> called. >>> I believe it's the wrong place to manipulate the url. Maybe it is expected >>> to return a relative path >>> beginning with ";sessionid". That url is maybe manipulated at a different >>> place, so in my case the >>> end result would be >>> http://localhost:8080/projectname/https://localhost:8443/projectname/;sessionid. >>> That would result in an error and maybe >>> http://localhost:8080/projectname/# is used therefore. >>> >>> Am I wrong? >>> >>> Thx >>> Arthur >>> >>> >>> >>> >>> >>> Von: Igor Vaynberg >>> An: users@wicket.apache.org >>> Gesendet: Mittwoch, den 22. Juli 2009, 18:31:27 Uhr >>> Betreff: Re: AW: SSL - ajax login >>> >>> ah, i thought i replied already because i looked into this yesterday. >>> >>> you will have to roll your own button. i would recomm
AW: AW: SSL - ajax login
no, sorry... the url is not changing to http://locahost:8080/projectname/# but when I hold the mouse pointer over the link, I see the url in the status bar. When I hold the mouse pointer over other links, I see very long urls a la http://localhost:8080/projectname/;jsessionid=wicket:interface. But as you suggested, I'll debug the javascript to see the url modifications. Thank you for your support Igor! Have a nice weekend. Greetz, Arthur Von: Igor Vaynberg An: users@wicket.apache.org Gesendet: Freitag, den 24. Juli 2009, 17:30:27 Uhr Betreff: Re: AW: SSL - ajax login no, i havent tried it myself. i never had to do an ajax login. the url in the browser changes to http://locahost:8080/projectname/# ? thats fine. the main part is what the actual ajax url is used - you wont see that in the browser's bar. i suggest you use firebug or something similar to walk the javascript and see why your *ajax* url is being mangled. obviously if you return just "https://localhost:8443/projectname"; that will not work because that doesnt have the listener interface target that will hit the behavior in your button. -igor On Fri, Jul 24, 2009 at 2:19 AM, Arthur Leigh Allen wrote: > Hi Igor, > > I tried to do it as simple as possible so I returned > https://localhost:8443/projectname in the overridden method getCallbackUrl of > AjaxFormSubmitBehavior. The result was the same. The link pointed to the url > http://locahost:8080/projectname/#. It seems to me that only relative pathes > can be returned, else the standard url will be used. > > I wanted to understand how the given url is used in wicket. I found the > method wicketAjaxGet in wicket-ajax.js. There the url is passed to > Wicket.Ajax.Call(...). I couldn't trace the call deeper because I couldn't > find Call() in any javascript file. > > Have you tried it yourself Igor? Does it work? > I'm using wicket 1.3.5. Does it depend on the version I use? > > Is there a different entry point to manipulate the url for ajax calls? > > Thx again > Arthur > > > > > Von: Igor Vaynberg > An: users@wicket.apache.org > Gesendet: Donnerstag, den 23. Juli 2009, 16:37:22 Uhr > Betreff: Re: AW: SSL - ajax login > > javascript invokes the url you give it, so it looked like it should > work. you might have to trace deeper to see whats going on. > > -igor > > On Thu, Jul 23, 2009 at 4:41 AM, Arthur Leigh > Allen wrote: >> Hi Igor, >> >> I did it as you said. >> I took the code from AjaxFallbackButton and I copied it to an own class. >> In the constructor I overwrite the getCallbackUrl() method of the >> AjaxFormSubmitBehavior. >> I added the value https://localhost:8443/projectname/ as a prefix to >> super.getCallbackUrl(). >> By the way: getCallbackUrl() returns a long relative url beginning with >> ";sessionid". >> So my url is https://localhost:8443/projectname/;sessionid... >> >> When starting tomcat and accessing the website, the url wasn't applied. >> When clicking the link, the url http://localhost:8080/projectname/# was >> called. >> I believe it's the wrong place to manipulate the url. Maybe it is expected >> to return a relative path >> beginning with ";sessionid". That url is maybe manipulated at a different >> place, so in my case the >> end result would be >> http://localhost:8080/projectname/https://localhost:8443/projectname/;sessionid. >> That would result in an error and maybe >> http://localhost:8080/projectname/# is used therefore. >> >> Am I wrong? >> >> Thx >> Arthur >> >> >> >> >> >> Von: Igor Vaynberg >> An: users@wicket.apache.org >> Gesendet: Mittwoch, den 22. Juli 2009, 18:31:27 Uhr >> Betreff: Re: AW: SSL - ajax login >> >> ah, i thought i replied already because i looked into this yesterday. >> >> you will have to roll your own button. i would recommend looking at >> the sourcecode of the default button. when you add the >> formsubmitbehavior in your button you can override getcallbackurl() >> and append https to it. >> >> -igor >> >> On Wed, Jul 22, 2009 at 2:37 AM, Arthur Leigh >> Allen wrote: >>> Hi again, >>> >>> I need to know if it's possible to switch to SSL via button or form. >>> Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because >>> we will go online within the next 10-14 days. >>> >>> Can anyone give me a prompt answer please? >>> >>> Thx & Best r
Re: AW: SSL - ajax login
no, i havent tried it myself. i never had to do an ajax login.
the url in the browser changes to http://locahost:8080/projectname/# ?
thats fine. the main part is what the actual ajax url is used - you
wont see that in the browser's bar. i suggest you use firebug or
something similar to walk the javascript and see why your *ajax* url
is being mangled.
obviously if you return just "https://localhost:8443/projectname"; that
will not work because that doesnt have the listener interface target
that will hit the behavior in your button.
-igor
On Fri, Jul 24, 2009 at 2:19 AM, Arthur Leigh
Allen wrote:
> Hi Igor,
>
> I tried to do it as simple as possible so I returned
> https://localhost:8443/projectname in the overridden method getCallbackUrl of
> AjaxFormSubmitBehavior. The result was the same. The link pointed to the url
> http://locahost:8080/projectname/#. It seems to me that only relative pathes
> can be returned, else the standard url will be used.
>
> I wanted to understand how the given url is used in wicket. I found the
> method wicketAjaxGet in wicket-ajax.js. There the url is passed to
> Wicket.Ajax.Call(...). I couldn't trace the call deeper because I couldn't
> find Call() in any javascript file.
>
> Have you tried it yourself Igor? Does it work?
> I'm using wicket 1.3.5. Does it depend on the version I use?
>
> Is there a different entry point to manipulate the url for ajax calls?
>
> Thx again
> Arthur
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Donnerstag, den 23. Juli 2009, 16:37:22 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> javascript invokes the url you give it, so it looked like it should
> work. you might have to trace deeper to see whats going on.
>
> -igor
>
> On Thu, Jul 23, 2009 at 4:41 AM, Arthur Leigh
> Allen wrote:
>> Hi Igor,
>>
>> I did it as you said.
>> I took the code from AjaxFallbackButton and I copied it to an own class.
>> In the constructor I overwrite the getCallbackUrl() method of the
>> AjaxFormSubmitBehavior.
>> I added the value https://localhost:8443/projectname/ as a prefix to
>> super.getCallbackUrl().
>> By the way: getCallbackUrl() returns a long relative url beginning with
>> ";sessionid".
>> So my url is https://localhost:8443/projectname/;sessionid...
>>
>> When starting tomcat and accessing the website, the url wasn't applied.
>> When clicking the link, the url http://localhost:8080/projectname/# was
>> called.
>> I believe it's the wrong place to manipulate the url. Maybe it is expected
>> to return a relative path
>> beginning with ";sessionid". That url is maybe manipulated at a different
>> place, so in my case the
>> end result would be
>> http://localhost:8080/projectname/https://localhost:8443/projectname/;sessionid.
>> That would result in an error and maybe
>> http://localhost:8080/projectname/# is used therefore.
>>
>> Am I wrong?
>>
>> Thx
>> Arthur
>>
>>
>>
>>
>>
>> Von: Igor Vaynberg
>> An: users@wicket.apache.org
>> Gesendet: Mittwoch, den 22. Juli 2009, 18:31:27 Uhr
>> Betreff: Re: AW: SSL - ajax login
>>
>> ah, i thought i replied already because i looked into this yesterday.
>>
>> you will have to roll your own button. i would recommend looking at
>> the sourcecode of the default button. when you add the
>> formsubmitbehavior in your button you can override getcallbackurl()
>> and append https to it.
>>
>> -igor
>>
>> On Wed, Jul 22, 2009 at 2:37 AM, Arthur Leigh
>> Allen wrote:
>>> Hi again,
>>>
>>> I need to know if it's possible to switch to SSL via button or form.
>>> Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
>>> we will go online within the next 10-14 days.
>>>
>>> Can anyone give me a prompt answer please?
>>>
>>> Thx & Best regards
>>> Arthur
>>>
>>>
>>>
>>>
>>> Von: Arthur Leigh Allen
>>> An: users@wicket.apache.org
>>> Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
>>> Betreff: AW: SSL - ajax login
>>>
>>> Hello Igor,
>>>
>>> thanks for your early reply.
>>> Yes, my login form is submitted via ajax.
>>>
>>> public class BasePage {
>>>
>>> public void switchViaAjax(...) { ... }
>>> public void navigateViaAjax(...) { ... }
>>&
AW: AW: AW: SSL - ajax login
"I wanted to understand how the given url is used in wicket. I found the method
wicketAjaxGet in wicket-ajax.js. There the url is passed to
Wicket.Ajax.Call(...). I couldn't trace the call deeper because I couldn't find
Call() in any javascript file."
Sorry I was blind yesterday, I found it today
However I would appreciate a response to the other questions.
Thx
Arthur
Von: Arthur Leigh Allen
An: users@wicket.apache.org
Gesendet: Freitag, den 24. Juli 2009, 11:19:23 Uhr
Betreff: AW: AW: SSL - ajax login
Hi Igor,
I tried to do it as simple as possible so I returned
https://localhost:8443/projectname in the overridden method getCallbackUrl of
AjaxFormSubmitBehavior. The result was the same. The link pointed to the url
http://locahost:8080/projectname/#. It seems to me that only relative pathes
can be returned, else the standard url will be used.
I wanted to understand how the given url is used in wicket. I found the method
wicketAjaxGet in wicket-ajax.js. There the url is passed to
Wicket.Ajax.Call(...). I couldn't trace the call deeper because I couldn't find
Call() in any javascript file.
Have you tried it yourself Igor? Does it work?
I'm using wicket 1.3.5. Does it depend on the version I use?
Is there a different entry point to manipulate the url for ajax calls?
Thx again
Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Donnerstag, den 23. Juli 2009, 16:37:22 Uhr
Betreff: Re: AW: SSL - ajax login
javascript invokes the url you give it, so it looked like it should
work. you might have to trace deeper to see whats going on.
-igor
On Thu, Jul 23, 2009 at 4:41 AM, Arthur Leigh
Allen wrote:
> Hi Igor,
>
> I did it as you said.
> I took the code from AjaxFallbackButton and I copied it to an own class.
> In the constructor I overwrite the getCallbackUrl() method of the
> AjaxFormSubmitBehavior.
> I added the value https://localhost:8443/projectname/ as a prefix to
> super.getCallbackUrl().
> By the way: getCallbackUrl() returns a long relative url beginning with
> ";sessionid".
> So my url is https://localhost:8443/projectname/;sessionid...
>
> When starting tomcat and accessing the website, the url wasn't applied.
> When clicking the link, the url http://localhost:8080/projectname/# was
> called.
> I believe it's the wrong place to manipulate the url. Maybe it is expected to
> return a relative path
> beginning with ";sessionid". That url is maybe manipulated at a different
> place, so in my case the
> end result would be
> http://localhost:8080/projectname/https://localhost:8443/projectname/;sessionid.
> That would result in an error and maybe
> http://localhost:8080/projectname/# is used therefore.
>
> Am I wrong?
>
> Thx
> Arthur
>
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Mittwoch, den 22. Juli 2009, 18:31:27 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> ah, i thought i replied already because i looked into this yesterday.
>
> you will have to roll your own button. i would recommend looking at
> the sourcecode of the default button. when you add the
> formsubmitbehavior in your button you can override getcallbackurl()
> and append https to it.
>
> -igor
>
> On Wed, Jul 22, 2009 at 2:37 AM, Arthur Leigh
> Allen wrote:
>> Hi again,
>>
>> I need to know if it's possible to switch to SSL via button or form.
>> Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
>> we will go online within the next 10-14 days.
>>
>> Can anyone give me a prompt answer please?
>>
>> Thx & Best regards
>> Arthur
>>
>>
>>
>>
>> Von: Arthur Leigh Allen
>> An: users@wicket.apache.org
>> Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
>> Betreff: AW: SSL - ajax login
>>
>> Hello Igor,
>>
>> thanks for your early reply.
>> Yes, my login form is submitted via ajax.
>>
>> public class BasePage {
>>
>> public void switchViaAjax(...) { ... }
>> public void navigateViaAjax(...) { ... }
>>
>> }
>>
>> @RequireHttps
>> public class SSLForm extends Form { ... }
>>
>> public class LoginPanel {
>>
>> public LoginPanel() { ... }
>>
>> public create() {
>> SSLForm form = new SSLForm("loginForm");
>> form.add(username);
>> form.add(password);
>>
>> AjaxFallbackButton loginButton = new
>> AjaxFallbackButton("loginButton", form) {
>> prote
AW: AW: SSL - ajax login
Hi Igor,
I tried to do it as simple as possible so I returned
https://localhost:8443/projectname in the overridden method getCallbackUrl of
AjaxFormSubmitBehavior. The result was the same. The link pointed to the url
http://locahost:8080/projectname/#. It seems to me that only relative pathes
can be returned, else the standard url will be used.
I wanted to understand how the given url is used in wicket. I found the method
wicketAjaxGet in wicket-ajax.js. There the url is passed to
Wicket.Ajax.Call(...). I couldn't trace the call deeper because I couldn't find
Call() in any javascript file.
Have you tried it yourself Igor? Does it work?
I'm using wicket 1.3.5. Does it depend on the version I use?
Is there a different entry point to manipulate the url for ajax calls?
Thx again
Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Donnerstag, den 23. Juli 2009, 16:37:22 Uhr
Betreff: Re: AW: SSL - ajax login
javascript invokes the url you give it, so it looked like it should
work. you might have to trace deeper to see whats going on.
-igor
On Thu, Jul 23, 2009 at 4:41 AM, Arthur Leigh
Allen wrote:
> Hi Igor,
>
> I did it as you said.
> I took the code from AjaxFallbackButton and I copied it to an own class.
> In the constructor I overwrite the getCallbackUrl() method of the
> AjaxFormSubmitBehavior.
> I added the value https://localhost:8443/projectname/ as a prefix to
> super.getCallbackUrl().
> By the way: getCallbackUrl() returns a long relative url beginning with
> ";sessionid".
> So my url is https://localhost:8443/projectname/;sessionid...
>
> When starting tomcat and accessing the website, the url wasn't applied.
> When clicking the link, the url http://localhost:8080/projectname/# was
> called.
> I believe it's the wrong place to manipulate the url. Maybe it is expected to
> return a relative path
> beginning with ";sessionid". That url is maybe manipulated at a different
> place, so in my case the
> end result would be
> http://localhost:8080/projectname/https://localhost:8443/projectname/;sessionid.
> That would result in an error and maybe
> http://localhost:8080/projectname/# is used therefore.
>
> Am I wrong?
>
> Thx
> Arthur
>
>
>
>
> ________
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Mittwoch, den 22. Juli 2009, 18:31:27 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> ah, i thought i replied already because i looked into this yesterday.
>
> you will have to roll your own button. i would recommend looking at
> the sourcecode of the default button. when you add the
> formsubmitbehavior in your button you can override getcallbackurl()
> and append https to it.
>
> -igor
>
> On Wed, Jul 22, 2009 at 2:37 AM, Arthur Leigh
> Allen wrote:
>> Hi again,
>>
>> I need to know if it's possible to switch to SSL via button or form.
>> Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
>> we will go online within the next 10-14 days.
>>
>> Can anyone give me a prompt answer please?
>>
>> Thx & Best regards
>> Arthur
>>
>>
>>
>>
>> Von: Arthur Leigh Allen
>> An: users@wicket.apache.org
>> Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
>> Betreff: AW: SSL - ajax login
>>
>> Hello Igor,
>>
>> thanks for your early reply.
>> Yes, my login form is submitted via ajax.
>>
>> public class BasePage {
>>
>> public void switchViaAjax(...) { ... }
>> public void navigateViaAjax(...) { ... }
>>
>> }
>>
>> @RequireHttps
>> public class SSLForm extends Form { ... }
>>
>> public class LoginPanel {
>>
>> public LoginPanel() { ... }
>>
>> public create() {
>> SSLForm form = new SSLForm("loginForm");
>> form.add(username);
>> form.add(password);
>>
>> AjaxFallbackButton loginButton = new
>> AjaxFallbackButton("loginButton", form) {
>> protected void onSubmit(AjaxRequestTarget target, Form form) {
>> // perform login => login is done via http
>> }
>> }
>> }
>> }
>>
>> As you said @RequireSSL is for pages.
>> Do you have any idea how I can remove @RequireHttps from the top of my
>> BasePage and switch to https on login?
>> Currently I think the only way to provide a ssl ajax call is to show the
>> base page via ssl as a starting basis.
>>
>> Therefore I have to use @RequireSSL on the Base
Re: AW: SSL - ajax login
javascript invokes the url you give it, so it looked like it should
work. you might have to trace deeper to see whats going on.
-igor
On Thu, Jul 23, 2009 at 4:41 AM, Arthur Leigh
Allen wrote:
> Hi Igor,
>
> I did it as you said.
> I took the code from AjaxFallbackButton and I copied it to an own class.
> In the constructor I overwrite the getCallbackUrl() method of the
> AjaxFormSubmitBehavior.
> I added the value https://localhost:8443/projectname/ as a prefix to
> super.getCallbackUrl().
> By the way: getCallbackUrl() returns a long relative url beginning with
> ";sessionid".
> So my url is https://localhost:8443/projectname/;sessionid...
>
> When starting tomcat and accessing the website, the url wasn't applied.
> When clicking the link, the url http://localhost:8080/projectname/# was
> called.
> I believe it's the wrong place to manipulate the url. Maybe it is expected to
> return a relative path
> beginning with ";sessionid". That url is maybe manipulated at a different
> place, so in my case the
> end result would be
> http://localhost:8080/projectname/https://localhost:8443/projectname/;sessionid.
> That would result in an error and maybe
> http://localhost:8080/projectname/# is used therefore.
>
> Am I wrong?
>
> Thx
> Arthur
>
>
>
>
> ____
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Mittwoch, den 22. Juli 2009, 18:31:27 Uhr
> Betreff: Re: AW: SSL - ajax login
>
> ah, i thought i replied already because i looked into this yesterday.
>
> you will have to roll your own button. i would recommend looking at
> the sourcecode of the default button. when you add the
> formsubmitbehavior in your button you can override getcallbackurl()
> and append https to it.
>
> -igor
>
> On Wed, Jul 22, 2009 at 2:37 AM, Arthur Leigh
> Allen wrote:
>> Hi again,
>>
>> I need to know if it's possible to switch to SSL via button or form.
>> Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
>> we will go online within the next 10-14 days.
>>
>> Can anyone give me a prompt answer please?
>>
>> Thx & Best regards
>> Arthur
>>
>>
>>
>>
>> Von: Arthur Leigh Allen
>> An: users@wicket.apache.org
>> Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
>> Betreff: AW: SSL - ajax login
>>
>> Hello Igor,
>>
>> thanks for your early reply.
>> Yes, my login form is submitted via ajax.
>>
>> public class BasePage {
>>
>> public void switchViaAjax(...) { ... }
>> public void navigateViaAjax(...) { ... }
>>
>> }
>>
>> @RequireHttps
>> public class SSLForm extends Form { ... }
>>
>> public class LoginPanel {
>>
>> public LoginPanel() { ... }
>>
>> public create() {
>> SSLForm form = new SSLForm("loginForm");
>> form.add(username);
>> form.add(password);
>>
>> AjaxFallbackButton loginButton = new
>> AjaxFallbackButton("loginButton", form) {
>> protected void onSubmit(AjaxRequestTarget target, Form form) {
>> // perform login => login is done via http
>> }
>> }
>> }
>> }
>>
>> As you said @RequireSSL is for pages.
>> Do you have any idea how I can remove @RequireHttps from the top of my
>> BasePage and switch to https on login?
>> Currently I think the only way to provide a ssl ajax call is to show the
>> base page via ssl as a starting basis.
>>
>> Therefore I have to use @RequireSSL on the BasePage but that means every
>> communication is done via ssl
>> and that means more server ballast and a slower page refresh.
>>
>> Greetings
>> Arthur
>>
>>
>>
>>
>> Von: Igor Vaynberg
>> An: users@wicket.apache.org
>> Gesendet: Dienstag, den 21. Juli 2009, 18:08:48 Uhr
>> Betreff: Re: SSL - ajax login
>>
>> @RequreHttps is meant to be a page-level feature, so it doesnt fit your
>> usecase.
>>
>> is your login form submitted via ajax?
>>
>> show us the code to sslform, your login form - making sure to include
>> the code to the component that submits it.
>>
>> -igor
>>
>> On Tue, Jul 21, 2009 at 8:34 AM, Arthur Leigh
>> Allen wrote:
>>> Hello folks,
>>>
>>> I'm using wicket 1.4 RC7 now and I have a question regarding the usage of
>>> ssl.
>>>
AW: AW: SSL - ajax login
Hi Igor,
I did it as you said.
I took the code from AjaxFallbackButton and I copied it to an own class.
In the constructor I overwrite the getCallbackUrl() method of the
AjaxFormSubmitBehavior.
I added the value https://localhost:8443/projectname/ as a prefix to
super.getCallbackUrl().
By the way: getCallbackUrl() returns a long relative url beginning with
";sessionid".
So my url is https://localhost:8443/projectname/;sessionid...
When starting tomcat and accessing the website, the url wasn't applied.
When clicking the link, the url http://localhost:8080/projectname/# was called.
I believe it's the wrong place to manipulate the url. Maybe it is expected to
return a relative path
beginning with ";sessionid". That url is maybe manipulated at a different
place, so in my case the
end result would be
http://localhost:8080/projectname/https://localhost:8443/projectname/;sessionid.
That would result in an error and maybe http://localhost:8080/projectname/# is
used therefore.
Am I wrong?
Thx
Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Mittwoch, den 22. Juli 2009, 18:31:27 Uhr
Betreff: Re: AW: SSL - ajax login
ah, i thought i replied already because i looked into this yesterday.
you will have to roll your own button. i would recommend looking at
the sourcecode of the default button. when you add the
formsubmitbehavior in your button you can override getcallbackurl()
and append https to it.
-igor
On Wed, Jul 22, 2009 at 2:37 AM, Arthur Leigh
Allen wrote:
> Hi again,
>
> I need to know if it's possible to switch to SSL via button or form.
> Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
> we will go online within the next 10-14 days.
>
> Can anyone give me a prompt answer please?
>
> Thx & Best regards
> Arthur
>
>
>
>
> Von: Arthur Leigh Allen
> An: users@wicket.apache.org
> Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
> Betreff: AW: SSL - ajax login
>
> Hello Igor,
>
> thanks for your early reply.
> Yes, my login form is submitted via ajax.
>
> public class BasePage {
>
> public void switchViaAjax(...) { ... }
> public void navigateViaAjax(...) { ... }
>
> }
>
> @RequireHttps
> public class SSLForm extends Form { ... }
>
> public class LoginPanel {
>
> public LoginPanel() { ... }
>
> public create() {
> SSLForm form = new SSLForm("loginForm");
> form.add(username);
> form.add(password);
>
> AjaxFallbackButton loginButton = new
> AjaxFallbackButton("loginButton", form) {
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> // perform login => login is done via http
> }
> }
> }
> }
>
> As you said @RequireSSL is for pages.
> Do you have any idea how I can remove @RequireHttps from the top of my
> BasePage and switch to https on login?
> Currently I think the only way to provide a ssl ajax call is to show the
> base page via ssl as a starting basis.
>
> Therefore I have to use @RequireSSL on the BasePage but that means every
> communication is done via ssl
> and that means more server ballast and a slower page refresh.
>
> Greetings
> Arthur
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Dienstag, den 21. Juli 2009, 18:08:48 Uhr
> Betreff: Re: SSL - ajax login
>
> @RequreHttps is meant to be a page-level feature, so it doesnt fit your
> usecase.
>
> is your login form submitted via ajax?
>
> show us the code to sslform, your login form - making sure to include
> the code to the component that submits it.
>
> -igor
>
> On Tue, Jul 21, 2009 at 8:34 AM, Arthur Leigh
> Allen wrote:
>> Hello folks,
>>
>> I'm using wicket 1.4 RC7 now and I have a question regarding the usage of
>> ssl.
>> I use the HttpsRequestCycleProcessor with the annotation @RequireHttps.
>>
>> Imagine the following case like it is realized on different sites like
>> web.de or gmx.de as well as xing.com.
>> The first call will result in a http url. If you enter your login name and
>> your password and submit the form,
>> then the form will be send via https.
>>
>> I only have one page. Everything on my page is exchanged via ajax. The login
>> is also done via ajax.
>> Currently I use the annotation above for my BasePage but from the first
>> call, the whole communication
>> is done with ssl.
>>
>> What I would like to realize is: Using the @RequireHttps annotation on forms
>> or sub
AW: AW: SSL - ajax login
that's a good hint, thanks a lot
i already switched back to wicket 1.3.5 because there are too many changes and
the time is too short to makes such changes now
i'll try your suggestion
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Mittwoch, den 22. Juli 2009, 18:31:27 Uhr
Betreff: Re: AW: SSL - ajax login
ah, i thought i replied already because i looked into this yesterday.
you will have to roll your own button. i would recommend looking at
the sourcecode of the default button. when you add the
formsubmitbehavior in your button you can override getcallbackurl()
and append https to it.
-igor
On Wed, Jul 22, 2009 at 2:37 AM, Arthur Leigh
Allen wrote:
> Hi again,
>
> I need to know if it's possible to switch to SSL via button or form.
> Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
> we will go online within the next 10-14 days.
>
> Can anyone give me a prompt answer please?
>
> Thx & Best regards
> Arthur
>
>
>
>
> Von: Arthur Leigh Allen
> An: users@wicket.apache.org
> Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
> Betreff: AW: SSL - ajax login
>
> Hello Igor,
>
> thanks for your early reply.
> Yes, my login form is submitted via ajax.
>
> public class BasePage {
>
> public void switchViaAjax(...) { ... }
> public void navigateViaAjax(...) { ... }
>
> }
>
> @RequireHttps
> public class SSLForm extends Form { ... }
>
> public class LoginPanel {
>
> public LoginPanel() { ... }
>
> public create() {
> SSLForm form = new SSLForm("loginForm");
> form.add(username);
> form.add(password);
>
> AjaxFallbackButton loginButton = new
> AjaxFallbackButton("loginButton", form) {
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> // perform login => login is done via http
> }
> }
> }
> }
>
> As you said @RequireSSL is for pages.
> Do you have any idea how I can remove @RequireHttps from the top of my
> BasePage and switch to https on login?
> Currently I think the only way to provide a ssl ajax call is to show the
> base page via ssl as a starting basis.
>
> Therefore I have to use @RequireSSL on the BasePage but that means every
> communication is done via ssl
> and that means more server ballast and a slower page refresh.
>
> Greetings
> Arthur
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Dienstag, den 21. Juli 2009, 18:08:48 Uhr
> Betreff: Re: SSL - ajax login
>
> @RequreHttps is meant to be a page-level feature, so it doesnt fit your
> usecase.
>
> is your login form submitted via ajax?
>
> show us the code to sslform, your login form - making sure to include
> the code to the component that submits it.
>
> -igor
>
> On Tue, Jul 21, 2009 at 8:34 AM, Arthur Leigh
> Allen wrote:
>> Hello folks,
>>
>> I'm using wicket 1.4 RC7 now and I have a question regarding the usage of
>> ssl.
>> I use the HttpsRequestCycleProcessor with the annotation @RequireHttps.
>>
>> Imagine the following case like it is realized on different sites like
>> web.de or gmx.de as well as xing.com.
>> The first call will result in a http url. If you enter your login name and
>> your password and submit the form,
>> then the form will be send via https.
>>
>> I only have one page. Everything on my page is exchanged via ajax. The login
>> is also done via ajax.
>> Currently I use the annotation above for my BasePage but from the first
>> call, the whole communication
>> is done with ssl.
>>
>> What I would like to realize is: Using the @RequireHttps annotation on forms
>> or submit buttons.
>> I implemented an own SSLForm class extending the wicket form class with the
>> annotation.
>> But when I use the SSLForm for my login, the communication is done without
>> ssl.
>> I would like to use my page via http, but the ajax login should be done with
>> ssl.
>>
>> The only thing I can do now is:
>> -page completely with ssl
>> -page completely without ssl
>>
>> I would appreciate any help.
>>
>> Best regards,
>> Arthur
>>
>>
>>
>
> -
> 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: AW: SSL - ajax login
ah, i thought i replied already because i looked into this yesterday.
you will have to roll your own button. i would recommend looking at
the sourcecode of the default button. when you add the
formsubmitbehavior in your button you can override getcallbackurl()
and append https to it.
-igor
On Wed, Jul 22, 2009 at 2:37 AM, Arthur Leigh
Allen wrote:
> Hi again,
>
> I need to know if it's possible to switch to SSL via button or form.
> Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
> we will go online within the next 10-14 days.
>
> Can anyone give me a prompt answer please?
>
> Thx & Best regards
> Arthur
>
>
>
>
> Von: Arthur Leigh Allen
> An: users@wicket.apache.org
> Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
> Betreff: AW: SSL - ajax login
>
> Hello Igor,
>
> thanks for your early reply.
> Yes, my login form is submitted via ajax.
>
> public class BasePage {
>
> public void switchViaAjax(...) { ... }
> public void navigateViaAjax(...) { ... }
>
> }
>
> @RequireHttps
> public class SSLForm extends Form { ... }
>
> public class LoginPanel {
>
> public LoginPanel() { ... }
>
> public create() {
> SSLForm form = new SSLForm("loginForm");
> form.add(username);
> form.add(password);
>
> AjaxFallbackButton loginButton = new
> AjaxFallbackButton("loginButton", form) {
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> // perform login => login is done via http
> }
> }
> }
> }
>
> As you said @RequireSSL is for pages.
> Do you have any idea how I can remove @RequireHttps from the top of my
> BasePage and switch to https on login?
> Currently I think the only way to provide a ssl ajax call is to show the
> base page via ssl as a starting basis.
>
> Therefore I have to use @RequireSSL on the BasePage but that means every
> communication is done via ssl
> and that means more server ballast and a slower page refresh.
>
> Greetings
> Arthur
>
>
>
>
> Von: Igor Vaynberg
> An: users@wicket.apache.org
> Gesendet: Dienstag, den 21. Juli 2009, 18:08:48 Uhr
> Betreff: Re: SSL - ajax login
>
> @RequreHttps is meant to be a page-level feature, so it doesnt fit your
> usecase.
>
> is your login form submitted via ajax?
>
> show us the code to sslform, your login form - making sure to include
> the code to the component that submits it.
>
> -igor
>
> On Tue, Jul 21, 2009 at 8:34 AM, Arthur Leigh
> Allen wrote:
>> Hello folks,
>>
>> I'm using wicket 1.4 RC7 now and I have a question regarding the usage of
>> ssl.
>> I use the HttpsRequestCycleProcessor with the annotation @RequireHttps.
>>
>> Imagine the following case like it is realized on different sites like
>> web.de or gmx.de as well as xing.com.
>> The first call will result in a http url. If you enter your login name and
>> your password and submit the form,
>> then the form will be send via https.
>>
>> I only have one page. Everything on my page is exchanged via ajax. The login
>> is also done via ajax.
>> Currently I use the annotation above for my BasePage but from the first
>> call, the whole communication
>> is done with ssl.
>>
>> What I would like to realize is: Using the @RequireHttps annotation on forms
>> or submit buttons.
>> I implemented an own SSLForm class extending the wicket form class with the
>> annotation.
>> But when I use the SSLForm for my login, the communication is done without
>> ssl.
>> I would like to use my page via http, but the ajax login should be done with
>> ssl.
>>
>> The only thing I can do now is:
>> -page completely with ssl
>> -page completely without ssl
>>
>> I would appreciate any help.
>>
>> Best regards,
>> Arthur
>>
>>
>>
>
> -
> 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: AW: AW: SSL - ajax login
You can always use the current url and replace http:// with https://
then redirect to it...
WebRequest
and
WebRequest.getHttpServletRequest()
provides you with all you need.
if you do it in ajax you could use
window.location.href
to force the redirect from client side...
Am 22.07.2009 um 11:37 schrieb Arthur Leigh Allen:
Hi again,
I need to know if it's possible to switch to SSL via button or form.
Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
we will go online within the next 10-14 days.
Can anyone give me a prompt answer please?
Thx & Best regards
Arthur
Von: Arthur Leigh Allen
An: users@wicket.apache.org
Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
Betreff: AW: SSL - ajax login
Hello Igor,
thanks for your early reply.
Yes, my login form is submitted via ajax.
public class BasePage {
public void switchViaAjax(...) { ... }
public void navigateViaAjax(...) { ... }
}
@RequireHttps
public class SSLForm extends Form { ... }
public class LoginPanel {
public LoginPanel() { ... }
public create() {
SSLForm form = new SSLForm("loginForm");
form.add(username);
form.add(password);
AjaxFallbackButton loginButton = new
AjaxFallbackButton("loginButton", form) {
protected void onSubmit(AjaxRequestTarget target, Form
form) {
// perform login => login is done via http
}
}
}
}
As you said @RequireSSL is for pages.
Do you have any idea how I can remove @RequireHttps from the top of
my BasePage and switch to https on login?
Currently I think the only way to provide a ssl ajax call is to show
the base page via ssl as a starting basis.
Therefore I have to use @RequireSSL on the BasePage but that means
every communication is done via ssl
and that means more server ballast and a slower page refresh.
Greetings
Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Dienstag, den 21. Juli 2009, 18:08:48 Uhr
Betreff: Re: SSL - ajax login
@RequreHttps is meant to be a page-level feature, so it doesnt fit
your usecase.
is your login form submitted via ajax?
show us the code to sslform, your login form - making sure to include
the code to the component that submits it.
-igor
On Tue, Jul 21, 2009 at 8:34 AM, Arthur Leigh
Allen wrote:
Hello folks,
I'm using wicket 1.4 RC7 now and I have a question regarding the
usage of ssl.
I use the HttpsRequestCycleProcessor with the annotation
@RequireHttps.
Imagine the following case like it is realized on different sites
like web.de or gmx.de as well as xing.com.
The first call will result in a http url. If you enter your login
name and your password and submit the form,
then the form will be send via https.
I only have one page. Everything on my page is exchanged via ajax.
The login is also done via ajax.
Currently I use the annotation above for my BasePage but from the
first call, the whole communication
is done with ssl.
What I would like to realize is: Using the @RequireHttps annotation
on forms or submit buttons.
I implemented an own SSLForm class extending the wicket form class
with the annotation.
But when I use the SSLForm for my login, the communication is done
without ssl.
I would like to use my page via http, but the ajax login should be
done with ssl.
The only thing I can do now is:
-page completely with ssl
-page completely without ssl
I would appreciate any help.
Best regards,
Arthur
-
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
AW: AW: SSL - ajax login
Hi again,
I need to know if it's possible to switch to SSL via button or form.
Otherwise I have to switch back to wicket 1.3.5. I'm in hurry because
we will go online within the next 10-14 days.
Can anyone give me a prompt answer please?
Thx & Best regards
Arthur
Von: Arthur Leigh Allen
An: users@wicket.apache.org
Gesendet: Dienstag, den 21. Juli 2009, 19:18:18 Uhr
Betreff: AW: SSL - ajax login
Hello Igor,
thanks for your early reply.
Yes, my login form is submitted via ajax.
public class BasePage {
public void switchViaAjax(...) { ... }
public void navigateViaAjax(...) { ... }
}
@RequireHttps
public class SSLForm extends Form { ... }
public class LoginPanel {
public LoginPanel() { ... }
public create() {
SSLForm form = new SSLForm("loginForm");
form.add(username);
form.add(password);
AjaxFallbackButton loginButton = new AjaxFallbackButton("loginButton",
form) {
protected void onSubmit(AjaxRequestTarget target, Form form) {
// perform login => login is done via http
}
}
}
}
As you said @RequireSSL is for pages.
Do you have any idea how I can remove @RequireHttps from the top of my BasePage
and switch to https on login?
Currently I think the only way to provide a ssl ajax call is to show the
base page via ssl as a starting basis.
Therefore I have to use @RequireSSL on the BasePage but that means every
communication is done via ssl
and that means more server ballast and a slower page refresh.
Greetings
Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Dienstag, den 21. Juli 2009, 18:08:48 Uhr
Betreff: Re: SSL - ajax login
@RequreHttps is meant to be a page-level feature, so it doesnt fit your usecase.
is your login form submitted via ajax?
show us the code to sslform, your login form - making sure to include
the code to the component that submits it.
-igor
On Tue, Jul 21, 2009 at 8:34 AM, Arthur Leigh
Allen wrote:
> Hello folks,
>
> I'm using wicket 1.4 RC7 now and I have a question regarding the usage of ssl.
> I use the HttpsRequestCycleProcessor with the annotation @RequireHttps.
>
> Imagine the following case like it is realized on different sites like web.de
> or gmx.de as well as xing.com.
> The first call will result in a http url. If you enter your login name and
> your password and submit the form,
> then the form will be send via https.
>
> I only have one page. Everything on my page is exchanged via ajax. The login
> is also done via ajax.
> Currently I use the annotation above for my BasePage but from the first call,
> the whole communication
> is done with ssl.
>
> What I would like to realize is: Using the @RequireHttps annotation on forms
> or submit buttons.
> I implemented an own SSLForm class extending the wicket form class with the
> annotation.
> But when I use the SSLForm for my login, the communication is done without
> ssl.
> I would like to use my page via http, but the ajax login should be done with
> ssl.
>
> The only thing I can do now is:
> -page completely with ssl
> -page completely without ssl
>
> I would appreciate any help.
>
> Best regards,
> Arthur
>
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
AW: SSL - ajax login
Hello Igor,
thanks for your early reply.
Yes, my login form is submitted via ajax.
public class BasePage {
public void switchViaAjax(...) { ... }
public void navigateViaAjax(...) { ... }
}
@RequireHttps
public class SSLForm extends Form { ... }
public class LoginPanel {
public LoginPanel() { ... }
public create() {
SSLForm form = new SSLForm("loginForm");
form.add(username);
form.add(password);
AjaxFallbackButton loginButton = new AjaxFallbackButton("loginButton",
form) {
protected void onSubmit(AjaxRequestTarget target, Form form) {
// perform login => login is done via http
}
}
}
}
As you said @RequireSSL is for pages.
Do you have any idea how I can remove @RequireHttps from the top of my BasePage
and switch to https on login?
Currently I think the only way to provide a ssl ajax call is to show the
base page via ssl as a starting basis.
Therefore I have to use @RequireSSL on the BasePage but that means every
communication is done via ssl
and that means more server ballast and a slower page refresh.
Greetings
Arthur
Von: Igor Vaynberg
An: users@wicket.apache.org
Gesendet: Dienstag, den 21. Juli 2009, 18:08:48 Uhr
Betreff: Re: SSL - ajax login
@RequreHttps is meant to be a page-level feature, so it doesnt fit your usecase.
is your login form submitted via ajax?
show us the code to sslform, your login form - making sure to include
the code to the component that submits it.
-igor
On Tue, Jul 21, 2009 at 8:34 AM, Arthur Leigh
Allen wrote:
> Hello folks,
>
> I'm using wicket 1.4 RC7 now and I have a question regarding the usage of ssl.
> I use the HttpsRequestCycleProcessor with the annotation @RequireHttps.
>
> Imagine the following case like it is realized on different sites like web.de
> or gmx.de as well as xing.com.
> The first call will result in a http url. If you enter your login name and
> your password and submit the form,
> then the form will be send via https.
>
> I only have one page. Everything on my page is exchanged via ajax. The login
> is also done via ajax.
> Currently I use the annotation above for my BasePage but from the first call,
> the whole communication
> is done with ssl.
>
> What I would like to realize is: Using the @RequireHttps annotation on forms
> or submit buttons.
> I implemented an own SSLForm class extending the wicket form class with the
> annotation.
> But when I use the SSLForm for my login, the communication is done without
> ssl.
> I would like to use my page via http, but the ajax login should be done with
> ssl.
>
> The only thing I can do now is:
> -page completely with ssl
> -page completely without ssl
>
> I would appreciate any help.
>
> Best regards,
> Arthur
>
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: SSL - ajax login
@RequreHttps is meant to be a page-level feature, so it doesnt fit your usecase. is your login form submitted via ajax? show us the code to sslform, your login form - making sure to include the code to the component that submits it. -igor On Tue, Jul 21, 2009 at 8:34 AM, Arthur Leigh Allen wrote: > Hello folks, > > I'm using wicket 1.4 RC7 now and I have a question regarding the usage of ssl. > I use the HttpsRequestCycleProcessor with the annotation @RequireHttps. > > Imagine the following case like it is realized on different sites like web.de > or gmx.de as well as xing.com. > The first call will result in a http url. If you enter your login name and > your password and submit the form, > then the form will be send via https. > > I only have one page. Everything on my page is exchanged via ajax. The login > is also done via ajax. > Currently I use the annotation above for my BasePage but from the first call, > the whole communication > is done with ssl. > > What I would like to realize is: Using the @RequireHttps annotation on forms > or submit buttons. > I implemented an own SSLForm class extending the wicket form class with the > annotation. > But when I use the SSLForm for my login, the communication is done without > ssl. > I would like to use my page via http, but the ajax login should be done with > ssl. > > The only thing I can do now is: > -page completely with ssl > -page completely without ssl > > I would appreciate any help. > > Best regards, > Arthur > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
SSL - ajax login
Hello folks, I'm using wicket 1.4 RC7 now and I have a question regarding the usage of ssl. I use the HttpsRequestCycleProcessor with the annotation @RequireHttps. Imagine the following case like it is realized on different sites like web.de or gmx.de as well as xing.com. The first call will result in a http url. If you enter your login name and your password and submit the form, then the form will be send via https. I only have one page. Everything on my page is exchanged via ajax. The login is also done via ajax. Currently I use the annotation above for my BasePage but from the first call, the whole communication is done with ssl. What I would like to realize is: Using the @RequireHttps annotation on forms or submit buttons. I implemented an own SSLForm class extending the wicket form class with the annotation. But when I use the SSLForm for my login, the communication is done without ssl. I would like to use my page via http, but the ajax login should be done with ssl. The only thing I can do now is: -page completely with ssl -page completely without ssl I would appreciate any help. Best regards, Arthur
SSL switching
Hello,I have implemented the SSL switching method as described in http://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html that rewrites the URL and does a redirect. In does work to a point but I have a few questions: 1) when the redirect occurs a new session is started, is this correct or have I done something wrong? 2) Are cookies carried over from the original request to the new one? I have tried debugging this but I get lost in the deeper parts of the request cycle and just cant work out what should be happening. thanks in advance Chris D -- Voicemail that's yours to keep! Sign up @ www.hullomail.com Chris Davis Senior Developer HulloMail Ltd e) chris.da...@hullomail.com p) +44(0)207 382 6270 http://twitter.com/hullomail
Re: Wicket Application bypassing- Internet Explorer file do wnloads over SSL do not work w ith the cache control headers
after a couple of weeks reading a myriad of posts, mailing lists and posible
solutions, I came up with a solution that worked for me
I developed a web application using wicket, this application have some links
to a static resources, specifically pdf and excel files, (License
Agreements, Privacy Policies, etc.), when I started to use SSL, none of
these static resources could be viewed in IE, (others browsers work fine),
this is due to an "IE feature", (in Microsoft words, by design, weird
behavior by design), that makes the resource unavailable through SSL.
I needed a general solution that could be applied to all the posible static
resources in my application, so, I came up with a filter that intercepts all
the requests for those static resources, (pdf, xls, etc), and set the
apropriate headers to avoid the problem with IE, after try a zillion
combination of headers, (pragma, content-cache, expiration, etc, none of
them worked for me), I found a solution, just use the response.reset()
method and voila that's all
this is a reduced version of the filter I came up with, for the sake of
brevity.
public class HttpsHeaderFilter implements Filter {
private FilterConfig config = null;
public void init(FilterConfig config) throws ServletException {
this.config = config;
}
public void destroy() {
config = null;
}
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException
{
response.reset() ;
chain.doFilter(request, response );
}
}
and in the web.xml, I configured the url for the appropiate resources I
wanted to filter.
I think that the reset could work better after the doFilter() call, (I'm
going to test that).
as I told before, I even tried to set the headers in the filter but it
didn't work either.
at the end it came out in the simplest way . lol.
Hope it helps to save some time and sleep hours to somebody else, I spent
quite a few of mine working around Microsoft's "design" .
--
View this message in context:
http://www.nabble.com/Wicket-Application-bypassing--Internet-Explorer-file-downloads-over-SSL-do-not-work-with-the-cache-control-headers%E2%80%8F-tp22519881p22552462.html
Sent from the Wicket - User 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 Application bypassing- Internet Explorer file do wnloads over SSL do not work w ith the cache control headers
Thanks Igor, I already tried that, but for some estrange reason the response
continues showing cache-control=no-cache and pragma=no-cache(using
FiddlerTool http analizer) even when the filter is setting those headers
with a different information (The filter is writting the log file - Log4j so
it is working).
I know that setting the headers in wicket works (I have some resourceLinks
that works fine), so, it is possible that DownloadLinks uses a wicket
callback? I'll have to change my application but I think it'll take less
time that find the filter error.
Thanks,
Alexa
igor.vaynberg wrote:
>
> external links do not use a wicket callback, you have to install a
> filter that intercepts those urls and sets the headers
>
> -igor
>
> On Sat, Mar 14, 2009 at 10:11 PM, Alexita wrote:
>>
>> Hi,
>> I have a basic Internet banking application developed in wicket,
>> everything
>> works fine on test, but in production with https, all links which try to
>> download a pdf were broken. That's an IE bug, but Microsoft is not
>> interested in fixing it(all other browsers work ok).
>>
>> I know the solution is set the response headers as follows:
>> response.setHeader("Cache-Control", "must-revalidate");
>> response.setHeader( "Pragma", "public" );
>>
>> Wicket allows to override response's headers (setHeaders(WebResponse
>> response)) but only for "webpage" subclasses.
>>
>> I using ExternalLinks added to a form not related at all with the
>> webPage,
>> There's any way to override those headers?
>> I tried to do directly in the HTML as a META tags, but doesn't work
>> either.
>>
>> or there are a better way to bypass this problem?? (not using IE is not
>> an
>> option)
>>
>> Thanks in advance for any information you can provide.
>>
>> Alexa
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-Application-bypassing--Internet-Explorer-file-downloads-over-SSL-do-not-work-with-the-cache-control-headers%E2%80%8F-tp22519881p22519881.html
>> Sent from the Wicket - User 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
>
>
>
--
View this message in context:
http://www.nabble.com/Wicket-Application-bypassing--Internet-Explorer-file-downloads-over-SSL-do-not-work-with-the-cache-control-headers%E2%80%8F-tp22519881p22551521.html
Sent from the Wicket - User 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 Application bypassing- Internet Explorer file downloads over SSL do not work with the cache control h eaders
Use Apache HTTPD for handling external components. Alternatively you may use
httpd as web server and delegate incoming requests (for wicket app!) to app
server via AJP. HTPD provides great control over response (setting cache
control in your case!). I always prefer HTTPD mounted external contents
(image, files etc.).
Warm Regards,
Anirban Basak
Ph : 91 33 2357 7177 Extn: 277
-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Sent: Sunday, March 15, 2009 11:08 AM
To: users@wicket.apache.org
Subject: Re: Wicket Application bypassing- Internet Explorer file downloads
over SSL do not work with the cache control headers
external links do not use a wicket callback, you have to install a
filter that intercepts those urls and sets the headers
-igor
On Sat, Mar 14, 2009 at 10:11 PM, Alexita wrote:
>
> Hi,
> I have a basic Internet banking application developed in wicket,
everything
> works fine on test, but in production with https, all links which try to
> download a pdf were broken. That's an IE bug, but Microsoft is not
> interested in fixing it(all other browsers work ok).
>
> I know the solution is set the response headers as follows:
> response.setHeader("Cache-Control", "must-revalidate");
> response.setHeader( "Pragma", "public" );
>
> Wicket allows to override response's headers (setHeaders(WebResponse
> response)) but only for "webpage" subclasses.
>
> I using ExternalLinks added to a form not related at all with the webPage,
> There's any way to override those headers?
> I tried to do directly in the HTML as a META tags, but doesn't work
either.
>
> or there are a better way to bypass this problem?? (not using IE is not an
> option)
>
> Thanks in advance for any information you can provide.
>
> Alexa
> --
> View this message in context:
http://www.nabble.com/Wicket-Application-bypassing--Internet-Explorer-file-d
ownloads-over-SSL-do-not-work-with-the-cache-control-headers%E2%80%8F-tp2251
9881p22519881.html
> Sent from the Wicket - User 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
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.237 / Virus Database: 270.11.13/1999 - Release Date: 03/13/09
05:59:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.0.237 / Virus Database: 270.11.13/1999 - Release Date: 03/15/09
14:07:00
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
