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: 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
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: 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
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: 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 lucastol...@hotmail.com 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
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 matt...@welchkin.net 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 matt...@welchkin.net: 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 mgrigo...@apache.orgwrote: 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 matt...@welchkin.net 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
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 michael.ha...@1und1.dewrote: 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 matt...@welchkin.net: 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
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 T extends IRequestableComponent boolean
isInstantiationAuthorized(ClassT 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 T extends IRequestableComponent boolean
isInstantiationAuthorized(ClassT 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 T extends IRequestableComponent boolean
isInstantiationAuthorized(ClassT 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
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 ja...@mcruncher.com 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 mgrigo...@apache.orgwrote:
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 ja...@mcruncher.com
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:
pre
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
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 ja...@mcruncher.com 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:
pre
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
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 mgrigo...@apache.orgwrote:
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 ja...@mcruncher.com
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:
pre
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
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:
pre
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);
}
}
}
}
/pre
These are the SMTP properties that were set:
pre
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
mail.smtp.socketFactory.port:465
mail.smtp.quitwait:false
smtp.username:f...@gmail.com
smtp.password: bar
/pre
This is the exception thrown:
pre
Caused by: javax.mail.MessagingException: Could not connect
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
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
). 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,
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
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 sonxu...@gmail.com 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
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
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
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
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
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
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 sonxu...@gmail.com 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
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
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 sonxu...@gmail.com 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
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
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 sonxu...@gmail.com 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
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
On Thu, Oct 21, 2010 at 11:30 AM, sonxurxo sonxu...@gmail.com 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
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
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
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
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 SecureFormT extends FormT {
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
Can you try using
form wicket:id=form method=get
/form
E.M.D
On Wed, Oct 20, 2010 at 9:05 AM, sonxurxo sonxu...@gmail.com 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 SecureFormT extends FormT {
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
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
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 sonxu...@gmail.com 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 SecureFormT extends FormT {
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
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: 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 sonxu...@gmail.com 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
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
Re: Submitting form via AJAX over SSL - RESEND
see HttpsRequestCycleProcessor -igor On Tue, Jul 20, 2010 at 7:12 AM, Jeffrey Schneller jeffrey.schnel...@envisa.com 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
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 istvan.s...@gmail.com 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
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: 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
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 jchappe...@4redi.com 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: 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 nino.martinez.w...@gmail.com:
I think last time this came up it ended out being some issue with jetty?
2009/11/11 Rangel Preis rangel...@gmail.com
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 rangel...@gmail.com:
The unique solution that i found is extends HttpsRequestCycleProcessor
to change only the protocol.
Any other ideia? Thanks All.
2009/11/10 Rangel Preis rangel...@gmail.com:
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 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 rangel...@gmail.com:
The unique solution that i found is extends HttpsRequestCycleProcessor
to change only the protocol.
Any other ideia? Thanks All.
2009/11/10 Rangel Preis rangel...@gmail.com:
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 think last time this came up it ended out being some issue with jetty?
2009/11/11 Rangel Preis rangel...@gmail.com
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 rangel...@gmail.com:
The unique solution that i found is extends HttpsRequestCycleProcessor
to change only the protocol.
Any other ideia? Thanks All.
2009/11/10 Rangel Preis rangel...@gmail.com:
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: 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 rangel...@gmail.com:
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+= iframe src='\/\/:' frameborder=\0\
id='+idContent+' allowtransparency=\false\ style=\height: 200px\+
/iframe;
} else {
s+= iframe src='about:blank' frameborder=\0\
id='+idContent+' allowtransparency=\false\ style=\height: 200px\+
/iframe;
}
I changed also the src to 0: without success. (after looking at
WICKET-855https://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 egola...@gmail.com 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 pe...@gmx.org 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 Golanegola...@gmail.com 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
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: 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 Golanegola...@gmail.com 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
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 Golanegola...@gmail.com 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 pe...@gmx.org 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 Golanegola...@gmail.com 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
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
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 Hernandezj...@expertoffice.net 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
s/SecureRequestCycleProcessor/HttpsRequestCycleProcessor/ the javadoc of which shows how to install it -igor On Sun, Aug 9, 2009 at 9:37 AM, hill180hill...@gmail.com 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 Hernandezj...@expertoffice.net 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
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 ClassHomePage 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 ClassHomePage 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 Allenarthurleigh.al...@yahoo.de 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
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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:
?xml version=1.0 encoding=UTF-8?ajax-response.../ajax-response
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de wrote:
Hi Igor,
I tried to do it as simple as possible so I returned
https://localhost:8443/projectname in the overridden method getCallbackUrl
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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 igor.vaynb...@gmail.com 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 Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com 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 Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com 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 Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com 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 Allenarthurleigh.al...@yahoo.de 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
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de
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 igor.vaynb...@gmail.com
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
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 arthurleigh.al...@yahoo.de
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de
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
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de
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
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de
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
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 Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com 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 Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com 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 Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com 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 Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de 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
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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
Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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 arthurleigh.al...@yahoo.de
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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: 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 arthurleigh.al...@yahoo.de
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 arthurleigh.al...@yahoo.de
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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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
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
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 Allenarthurleigh.al...@yahoo.de 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 igor.vaynb...@gmail.com
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
Allenarthurleigh.al...@yahoo.de 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 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 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 ctgog...@hotmail.com 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
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 ctgog...@hotmail.com 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 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.
pre
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 );
}
}
/pre
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
Wicket Application bypassing- Internet Explorer file down loads over SSL do not work wi th the cache control headers
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
Re: Wicket Application bypassing- Internet Explorer file downloads over SSL do not work with the cache control h eaders
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 ctgog...@hotmail.com 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
Re: SSL pages and links
Only a cent: security-constraint on web.xml can work only on certain URIs security-constraint display-nameSSL/display-name web-resource-collection web-resource-nameMake sure login path is secured/web-resource-name descriptionWe like ssl web services/description url-pattern/sec/*/url-pattern /web-resource-collection web-resource-collection web-resource-nameWeb Services/web-resource-name descriptionWe like ssl web services/description url-pattern/ws/*/url-pattern /web-resource-collection user-data-constraint description/ transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint In this application, my LoginPage is mounted under /sec/ Once logged in though, There is no way back from https to http. Marcelo On Fri, Feb 20, 2009 at 7:04 PM, novotny novo...@gridsphere.org wrote: Hi, I need to secure some pages as well as providing a login link that uses HTTPS. I read thru the document http://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html but it seems there are several approaches and various source code some of which doesn't compile. I am using wicket 1.4 with generics support. Can someone please share with me there working configuration for setting secure links and pages? Also this is such a critical piece of functionality for any enterprise site that maybe one of the wicket gurus could cleanup the documentation or even provide classes as part of the core wicket code to do this kind of thing. For the record, I tried the very last approach Edit (Wicket 1.3.x) alternative:, but it seems to ignore my components that are not pages that are annotated with @RequireSSL (e.g. I created a SecureBookmarkablePageLink that extends BookmarkablePageLink and has the annotation at the top) Thanks, Jason -- View this message in context: http://www.nabble.com/SSL-pages-and-links-tp22130162p22130162.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 -- Marcelo Morales - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
SSL pages and links
Hi, I need to secure some pages as well as providing a login link that uses HTTPS. I read thru the document http://cwiki.apache.org/WICKET/how-to-switch-to-ssl-mode.html but it seems there are several approaches and various source code some of which doesn't compile. I am using wicket 1.4 with generics support. Can someone please share with me there working configuration for setting secure links and pages? Also this is such a critical piece of functionality for any enterprise site that maybe one of the wicket gurus could cleanup the documentation or even provide classes as part of the core wicket code to do this kind of thing. For the record, I tried the very last approach Edit (Wicket 1.3.x) alternative:, but it seems to ignore my components that are not pages that are annotated with @RequireSSL (e.g. I created a SecureBookmarkablePageLink that extends BookmarkablePageLink and has the annotation at the top) Thanks, Jason -- View this message in context: http://www.nabble.com/SSL-pages-and-links-tp22130162p22130162.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
SSL support for WebApplication in development branch ..
Hi - I am looking at the following wiki - http://cwiki.apache.org/confluence/display/WICKET/How+to+switch+to+SSL+mode#HowtoswitchtoSSLmode-Edit(Wicket1.3.x)%3A . The wiki lists a whole number of options to add SSL support to a web application including that of the links of controls etc. (Button / Link etc). I was curious if any of these things are already incorporated in the development branch already that could be picked up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
