Re: where is wicket-contrib-gmap3 1.3.4

2008-10-20 Thread overseastars

Sorry I got some of my words missing.   I mean the latest
wicket-contrib-gmap2-1.4 is not compatible with wicket-1.3.4.

So the only way is to checkout the svn and DIY that jar file???



overseastars wrote:
 
 Hi
 
 I'm using wicket 1.3.4 which is not compatible with wicket-contrib-gmap2
 
 Could anyone please tell me where i can find that jar file
 

-- 
View this message in context: 
http://www.nabble.com/where-is-wicket-contrib-gmap3-1.3.4-tp20063260p20063753.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Recommended validation method

2008-10-20 Thread Igor Vaynberg
public class mywebpage extends webpage {
  @SpringBean private Dao dao;

  public mywebpage() {
 add(new textfield(foo).add(new ivalidatiorstring() {
 public void validate(ivalidatablestring v) {
string value=v.getvalue();
if (!dao.valueunique(value)) {
 validatable.error(new
validationerror().addmessagekey(error.unique).setvariable(value,
value));
}}):}

thats all there is to it

-igor

On Sun, Oct 19, 2008 at 8:34 PM, claym [EMAIL PROTECTED] wrote:


 I'm fairly new, so help me out here...

 I've got a basic register a user form.

 I'd like to validate a couple of the fields (email, username) against the
 database.

 Database access provided by a @SpringBean service/dao object.

 Where/how is the recommended way of doing this type of validation? In the
 onSubmit? Some sort of custom validator?

 Thanks!
 --
 View this message in context:
 http://www.nabble.com/Recommended-validation-method-tp20062724p20062724.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: where is wicket-contrib-gmap3 1.3.4

2008-10-20 Thread Martin Funk
2008/10/20 overseastars [EMAIL PROTECTED]


 Sorry I got some of my words missing.   I mean the latest
 wicket-contrib-gmap2-1.4 is not compatible with wicket-1.3.4.

 So the only way is to checkout the svn and DIY that jar file???

If you wan't to stay 'on the edge' you can check out trunk, modify the
dependency to wicket in the build.xml to the version you need and let the
compiler guide you to the places that need to be patched.
It's only a couple of places were the use of generics needs to be droped.
Sorry for the inconveniance.

mf





 overseastars wrote:
 
  Hi
 
  I'm using wicket 1.3.4 which is not compatible with wicket-contrib-gmap2
 
  Could anyone please tell me where i can find that jar file
 

 --
 View this message in context:
 http://www.nabble.com/where-is-wicket-contrib-gmap3-1.3.4-tp20063260p20063753.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




wicket-ioc/cglib constructor injection

2008-10-20 Thread Jan Kriesten

Hi,

wicket-ioc/cglib (using 1.3-snapshot) has problems when it comes to creating
proxies for constructor injection (and also when it comes to enhance final 
classes):

Caused by: java.lang.IllegalArgumentException: Superclass has no null
constructors but no arguments were given
at net.sf.cglib.proxy.Enhancer.emitConstructors(Enhancer.java:721)
at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:499)
at
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
at
org.apache.wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.java:173)
at
org.apache.wicket.guice.GuiceComponentInjector.inject(GuiceComponentInjector.java:114)


Is there a way around this or could the above cases just handled to not be
enhanced at all?

Best regards, --- Jan.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: wicket-ioc/cglib constructor injection

2008-10-20 Thread Igor Vaynberg
add a package private default constructor to your class.

these are all well known limitations of proxying classes, you should try to
make sure your injected dependencies are interfaces or you something like
salve so no proxies are needed.

-igor

On Sun, Oct 19, 2008 at 11:53 PM, Jan Kriesten [EMAIL PROTECTED]wrote:


 Hi,

 wicket-ioc/cglib (using 1.3-snapshot) has problems when it comes to
 creating
 proxies for constructor injection (and also when it comes to enhance final
 classes):

 Caused by: java.lang.IllegalArgumentException: Superclass has no null
 constructors but no arguments were given
at net.sf.cglib.proxy.Enhancer.emitConstructors(Enhancer.java:721)
at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:499)
at

 net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at

 net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
at

 org.apache.wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.java:173)
at

 org.apache.wicket.guice.GuiceComponentInjector.inject(GuiceComponentInjector.java:114)


 Is there a way around this or could the above cases just handled to not be
 enhanced at all?

 Best regards, --- Jan.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: where is wicket-contrib-gmap3 1.3.4

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

Hmm theres no 1.3 snap..

So yes currently no other way..

overseastars wrote:

Sorry I got some of my words missing.   I mean the latest
wicket-contrib-gmap2-1.4 is not compatible with wicket-1.3.4.

So the only way is to checkout the svn and DIY that jar file???



overseastars wrote:
  

Hi

I'm using wicket 1.3.4 which is not compatible with wicket-contrib-gmap2

Could anyone please tell me where i can find that jar file




  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Pages or components... how do u decide?

2008-10-20 Thread Jörn Zaefferer
A URL is quite a strong argument for using pages. With the
wicket-annotations project its dead-easy to make pages bookmarkable,
just add @MountPath(path=/path/to/page).

Jörn

On Sun, Oct 19, 2008 at 11:55 PM, Ned Collyer [EMAIL PROTECTED] wrote:

 I use markup inheritance for some pages, but I try to avoid making new pages
 (after all, what do they give you that a panel does not (other than an
 URL)?)

 I do use markup inheritance for components A LOT!!



 jwcarman wrote:

 Are you using one page and just passing in your content component?
 Are you not using markup inheritance?

 On Thu, Oct 16, 2008 at 5:16 PM, Ned Collyer [EMAIL PROTECTED]
 wrote:

 The system I'm building at the moment has almost everything pushed down
 into
 components.  Most of the functionality is achieved by a single base page
 which takes a component in its constructor.

 For Bookmarkable pages, I extend this base page, and pass a component to
 the
 super.

 How do _you_ separate concerns?  Is there a best practice?

 A benefit of using a page is that it can be accessed with getPage()
 regardless of how deep in the hierarchy you are... so I guess it could be
 useful for storing the primary model for that section of the site.

 Anyway, I'm interested in hearing how others deal with Page vs
 Components,
 and how they structure their applications.

 So many ways of skinning a cat :)

 Rgds

 Ned
 --
 View this message in context:
 http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20016807.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context: 
 http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20060673.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: tomcat 6

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

Check you dependencies..

I just use jetty when running from eclipse, much simpler.. Just run 
start jar or debug start jar.. etc..


Leucht, Axel wrote:

Hi,

I'm currently trying to get a HelloWorld application running with wicket 1.3.4.

I'm doing all my web development from within the Eclipse IDE (3.4 Ganymede), so 
I suspect setup of the project should be easy.
When the server environment is set to tomcat 5.5.27 the HelloWorldApplication 
runs fine but NOT under tomcat 6.0.16!

There is no clue in the logs stating that wicket is started in development mode 
which it is when started under tc 5.5.27. The application does run when I start 
tomcat 6.0.16 in standalone mode (outside Eclipse).

Does someone knows what to do to make it run from within Eclipse?

/Axel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Pages or components... how do u decide?

2008-10-20 Thread Ned Collyer

I use those annotations - they are awesome :)

If you could annotate a panel to be bookmarkable.. that'd be interesting. 
So the panel COULD be embeded into other components, or used standalone as a
page.

Currently I achieve this by creating a new page class which instantiates and
passes the panel to the super.

Anyway, i thought it was an interesting thing to discuss.


Jörn Zaefferer-2 wrote:
 
 A URL is quite a strong argument for using pages. With the
 wicket-annotations project its dead-easy to make pages bookmarkable,
 just add @MountPath(path=/path/to/page).
 
 Jörn
 

-- 
View this message in context: 
http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20065174.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: wicket-ioc/cglib constructor injection

2008-10-20 Thread Jan Kriesten

Hi Igor,

 add a package private default constructor to your class.

default constructor wont work in this case.

 these are all well known limitations of proxying classes, you should try to
 make sure your injected dependencies are interfaces or you something like
 salve so no proxies are needed.

Defining an interface for the class results in wicket-ioc not injecting the
original class/constructor at all. So there's a flaw with this approach.

Best regards, --- Jan.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



CSRF Protection: double submitted cookie

2008-10-20 Thread Jörn Zaefferer
Hi,

my application currently uses CryptedUrlWebRequestCodingStrategy to
protect against CRSF attacks. Afaik 1.3.5 will include an update that
generates the key based on user sessions:
http://issues.apache.org/jira/browse/WICKET-1782
According to Johan Compagner, there are still issues with that
approach, though I don't know if that has been fixed:
http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593

Anyway, the point of this mail is to bring up a different strategy for
CSRF protection, the double-submitted-cookie. Discussion of that are
here http://www.codinghorror.com/blog/archives/001175.html which links
to this article, including a whitepaper:
http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

The basic idea is:

When a user visits a site, the site should generate a
(cryptographically strong) pseudorandom value and set it as a cookie
on the user's machine. The site should require every form submission
to include this pseudorandom value as a form value and also as a
cookie value. When a POST request is sent to the site, the request
should only be considered valid if the form value and the cookie value
are the same. When an attacker submits a form on behalf of a user, he
can only modify the values of the form. An attacker cannot read any
data sent from the server or modify cookie values, per the same-origin
policy. This means that while an attacker can send any value he wants
with the form, he will be unable to modify or read the value stored in
the cookie. Since the cookie value and the form value must be the
same, the attacker will be unable to successfully submit a form unless
he is able to guess the pseudorandom value.

For Wicket, this would mean: Generate a pseudorandom value and set is
as a session cookie, when the cookie doesn't yet exist. Insert a
hidden input into each form with the generated value. Validate that
the value equals the cookie when submitting a form. The input and
validation can be abstracted into a Form subclass (or even add it to
Wicket's Form class...).

That really easy to implement, is much more efficient (generate only
one value per user/browser session, store it on the client, not the
server) and is now the most common strategy to protect against CSRF
attacks. I've read a lot about CSRF, and this strategy seems the only
one both easy enough to implement and without holes.

What do you think? Should Wicket support that out-of-the-box?

Jörn


Re: CSRF Protection: double submitted cookie

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

for me +1 if it does not interfere with other stuff.

Jörn Zaefferer wrote:

Hi,

my application currently uses CryptedUrlWebRequestCodingStrategy to
protect against CRSF attacks. Afaik 1.3.5 will include an update that
generates the key based on user sessions:
http://issues.apache.org/jira/browse/WICKET-1782
According to Johan Compagner, there are still issues with that
approach, though I don't know if that has been fixed:
http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593

Anyway, the point of this mail is to bring up a different strategy for
CSRF protection, the double-submitted-cookie. Discussion of that are
here http://www.codinghorror.com/blog/archives/001175.html which links
to this article, including a whitepaper:
http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

The basic idea is:

When a user visits a site, the site should generate a
(cryptographically strong) pseudorandom value and set it as a cookie
on the user's machine. The site should require every form submission
to include this pseudorandom value as a form value and also as a
cookie value. When a POST request is sent to the site, the request
should only be considered valid if the form value and the cookie value
are the same. When an attacker submits a form on behalf of a user, he
can only modify the values of the form. An attacker cannot read any
data sent from the server or modify cookie values, per the same-origin
policy. This means that while an attacker can send any value he wants
with the form, he will be unable to modify or read the value stored in
the cookie. Since the cookie value and the form value must be the
same, the attacker will be unable to successfully submit a form unless
he is able to guess the pseudorandom value.

For Wicket, this would mean: Generate a pseudorandom value and set is
as a session cookie, when the cookie doesn't yet exist. Insert a
hidden input into each form with the generated value. Validate that
the value equals the cookie when submitting a form. The input and
validation can be abstracted into a Form subclass (or even add it to
Wicket's Form class...).

That really easy to implement, is much more efficient (generate only
one value per user/browser session, store it on the client, not the
server) and is now the most common strategy to protect against CSRF
attacks. I've read a lot about CSRF, and this strategy seems the only
one both easy enough to implement and without holes.

What do you think? Should Wicket support that out-of-the-box?

Jörn
  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: CSRF Protection: double submitted cookie

2008-10-20 Thread Johan Compagner
what i dont get
if an attacker wants to submit the form. and it can get to the form it can
do the post
but you say it cant access the cookie. But if the cookie value is just
compared to the form post value
we have to make sure that the name of the cookie cant be guessed right? So
what should the name be?

Because if the name would be wicket-form-uuid then couldnt the attacker
also just generate that cookie?

I guess there is a cookie per form (there can be many forms on the same page
or different active pages)
and that cookie must be regenerated/set on every form render?

johan


On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer 
[EMAIL PROTECTED] wrote:

 Hi,

 my application currently uses CryptedUrlWebRequestCodingStrategy to
 protect against CRSF attacks. Afaik 1.3.5 will include an update that
 generates the key based on user sessions:
 http://issues.apache.org/jira/browse/WICKET-1782
 According to Johan Compagner, there are still issues with that
 approach, though I don't know if that has been fixed:
 http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593

 Anyway, the point of this mail is to bring up a different strategy for
 CSRF protection, the double-submitted-cookie. Discussion of that are
 here http://www.codinghorror.com/blog/archives/001175.html which links
 to this article, including a whitepaper:

 http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

 The basic idea is:

 When a user visits a site, the site should generate a
 (cryptographically strong) pseudorandom value and set it as a cookie
 on the user's machine. The site should require every form submission
 to include this pseudorandom value as a form value and also as a
 cookie value. When a POST request is sent to the site, the request
 should only be considered valid if the form value and the cookie value
 are the same. When an attacker submits a form on behalf of a user, he
 can only modify the values of the form. An attacker cannot read any
 data sent from the server or modify cookie values, per the same-origin
 policy. This means that while an attacker can send any value he wants
 with the form, he will be unable to modify or read the value stored in
 the cookie. Since the cookie value and the form value must be the
 same, the attacker will be unable to successfully submit a form unless
 he is able to guess the pseudorandom value.

 For Wicket, this would mean: Generate a pseudorandom value and set is
 as a session cookie, when the cookie doesn't yet exist. Insert a
 hidden input into each form with the generated value. Validate that
 the value equals the cookie when submitting a form. The input and
 validation can be abstracted into a Form subclass (or even add it to
 Wicket's Form class...).

 That really easy to implement, is much more efficient (generate only
 one value per user/browser session, store it on the client, not the
 server) and is now the most common strategy to protect against CSRF
 attacks. I've read a lot about CSRF, and this strategy seems the only
 one both easy enough to implement and without holes.

 What do you think? Should Wicket support that out-of-the-box?

 Jörn



Ajax refresh custom WebComponent fail (an external image by Igor Vaynberg)

2008-10-20 Thread bryan0101







I'm trying to refresh a custom components describe in
http://cwiki.apache.org/WICKET/how-to-load-an-external-image.html
http://cwiki.apache.org/WICKET/how-to-load-an-external-image.html 
.
It's an External image wrapped in a link (clickable image)

nbsp;

The StaticImage part works great. 

Minor difference:nbsp; Instead
of wrapping in ExternalLink,
I just wrap it in Link to opened in a popup, and the popup calls back
the page's function with ajaxrequest. 


WIth the requestTarget, one would
think it should be able to ajax refresh the component. Ive tried
Component.replaceWith(newComponent) by creating a
new StaticImage Component, no luck. I've tried
changing the
Model, the
model and/or URL got changed, but the image refused to refresh no
matter what. 


Next I'm tempted to just try and wrap all this in a Panel and do a
replaceWith and see, but this is heavy and I try not to do that.

If there are other options I'd glad to try out. Thanks


The StaticImage class:


public class StaticImage extends WebComponent

{

nbsp;nbsp; private static final long serialVersionUID =
-7600332611457262341L;


nbsp;nbsp; public StaticImage(String id, IModel model)

nbsp;nbsp; {

nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; super(id, model);

nbsp;nbsp; }


nbsp; 

nbsp;nbsp; public void resetDefaultModelObject (String url)

nbsp;nbsp; {

nbsp;nbsp;nbsp; nbsp;nbsp; setDefaultModelObject(new Model(url));

nbsp;nbsp; }


nbsp;nbsp; protected void onComponentTag(ComponentTag tag)

nbsp;nbsp; {

nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; checkComponentTag(tag, img);

nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; super.onComponentTag(tag);

nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; String url =
getDefaultModelObjectAsString();

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; url = url + ((url.indexOf(?)
gt;= 0) ? amp; : ?);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; url = url + wicket:antiCache= +
System.currentTimeMillis();


nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; tag.put(src, url);


nbsp;nbsp; }

}



The code to create the StaticImage


nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; ...

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; mainImg = new StaticImage
(mainImg,new
Model(http://img519.imageshack.us/test1.gif;));

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; mainImg.setOutputMarkupId(true);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; 

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; mainImgDiv = new
WebMarkupContainer(mainImgDiv);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp;
mainImgDiv.setOutputMarkupId(true);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; 

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; mainImgUploadLink = new
Link(mainImgUpload)

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; {

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; public void
onClick()

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; {

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp;
nbsp;nbsp;nbsp; setResponsePage(new PopupPage(CurrentPanel.this));

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; }

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; };


nbsp;nbsp;nbsp; nbsp;nbsp;nbsp;
mainImgUploadLink.setOutputMarkupId(true);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; mainImgUploadLink.add(mainImg);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; mainImgDiv.add(mainImgUploadLink);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; panelForm.add(mainImgDiv);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; ...



The code to refresh



public void onPopupClose (AjaxRequestTarget target)

nbsp;nbsp;nbsp; {

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; if (mainImgFile != null)

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; {

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; String newImg
= http://img519.imageshack.us/newtest.gif;;

nbsp;nbsp;nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;
mainImg.resetDefaultModelObject(newImg);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; 

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp;
target.addComponent(newImgComp);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp;
target.addComponent(mainImgUploadLink);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; nbsp;nbsp;nbsp;
target.addComponent(mainImgDiv);

nbsp;nbsp;nbsp; nbsp;nbsp;nbsp; }

nbsp;nbsp;nbsp; }


Any help would be greatly appreciated. Thanks.







-- 
View this message in context: 
http://www.nabble.com/Ajax-refresh-custom-WebComponent-fail-%28an-external-image-by-Igor-Vaynberg%29-tp20066916p20066916.html
Sent from the Wicket - User mailing list archive at Nabble.com.


Re: CSRF Protection: double submitted cookie

2008-10-20 Thread Jörn Zaefferer
No, the cookie is subject to the same-origin-policy, both in reading
and writing. The request is authenticated because the session cookie
is set, but its invalid when the form itself is missing the value.
Combining the attack with XSS would give access to the cookie, but
then he could just as well hijack the session directly.

In other words: With CSRF alone there is no way for the attacker to
read the cookie, therefore its enough to use just one.

Their whitepaper may do a better job of explaining the techniquie:
http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf
Solutions are described on page 8ff.

Jörn

On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED] wrote:
 what i dont get
 if an attacker wants to submit the form. and it can get to the form it can
 do the post
 but you say it cant access the cookie. But if the cookie value is just
 compared to the form post value
 we have to make sure that the name of the cookie cant be guessed right? So
 what should the name be?

 Because if the name would be wicket-form-uuid then couldnt the attacker
 also just generate that cookie?

 I guess there is a cookie per form (there can be many forms on the same page
 or different active pages)
 and that cookie must be regenerated/set on every form render?

 johan


 On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer 
 [EMAIL PROTECTED] wrote:

 Hi,

 my application currently uses CryptedUrlWebRequestCodingStrategy to
 protect against CRSF attacks. Afaik 1.3.5 will include an update that
 generates the key based on user sessions:
 http://issues.apache.org/jira/browse/WICKET-1782
 According to Johan Compagner, there are still issues with that
 approach, though I don't know if that has been fixed:
 http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593

 Anyway, the point of this mail is to bring up a different strategy for
 CSRF protection, the double-submitted-cookie. Discussion of that are
 here http://www.codinghorror.com/blog/archives/001175.html which links
 to this article, including a whitepaper:

 http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

 The basic idea is:

 When a user visits a site, the site should generate a
 (cryptographically strong) pseudorandom value and set it as a cookie
 on the user's machine. The site should require every form submission
 to include this pseudorandom value as a form value and also as a
 cookie value. When a POST request is sent to the site, the request
 should only be considered valid if the form value and the cookie value
 are the same. When an attacker submits a form on behalf of a user, he
 can only modify the values of the form. An attacker cannot read any
 data sent from the server or modify cookie values, per the same-origin
 policy. This means that while an attacker can send any value he wants
 with the form, he will be unable to modify or read the value stored in
 the cookie. Since the cookie value and the form value must be the
 same, the attacker will be unable to successfully submit a form unless
 he is able to guess the pseudorandom value.

 For Wicket, this would mean: Generate a pseudorandom value and set is
 as a session cookie, when the cookie doesn't yet exist. Insert a
 hidden input into each form with the generated value. Validate that
 the value equals the cookie when submitting a form. The input and
 validation can be abstracted into a Form subclass (or even add it to
 Wicket's Form class...).

 That really easy to implement, is much more efficient (generate only
 one value per user/browser session, store it on the client, not the
 server) and is now the most common strategy to protect against CSRF
 attacks. I've read a lot about CSRF, and this strategy seems the only
 one both easy enough to implement and without holes.

 What do you think? Should Wicket support that out-of-the-box?

 Jörn




Re: CSRF Protection: double submitted cookie

2008-10-20 Thread Jörn Zaefferer
I've looked at CSRFGuard, the approach has several of the drawbacks
described in the paper. Its much less effective then the
double-submitted-cookie, eg. it involves buffering and rewriting the
response to modify forms. It generates values for each rendered form
and stores it in the user session
(http://www.owasp.org/index.php/How_CSRFGuard_Works). The
double-submitted-cookie doesn't require any serverstate at all.

I'm not sure what happens when you open multiple tabs/windows, but
considering that the value is stored in the session, it probably
breaks. Again something the cookie pattern isn't affected by.

Jörn

On Mon, Oct 20, 2008 at 12:42 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
 I found this interesting:

 Don't forget OWASP CSRFTester and CSRFGuard
 http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks#comment-100619
 Comment by Jeff Williams http://www.owasp.org on September 29th, 2008 at
 9:53 am.

 OWASP has made two tools available to help with CSRF problems. The first is
 CSRFTester which will allow you to test your website for CSRF problems. The
 tool allows you to create multi-step test cases and has been used to
 transfer funds, create accounts, issue checks, etc...

 The second tool is called CSRFGuard, and it's a Java EE filter that can be
 placed in front of an entire application to provide CSRF protection.
 CSRFGuard uses javascript to insert tokens into forms and links, and then
 validates the token in every request.

 You can find both free tools at http://www.owasp.org.;


 Especially the part about the filter. If it's compatible with wicket and a
 okay approach, I'd say forget about these things...




 Johan Compagner wrote:

 what i dont get
 if an attacker wants to submit the form. and it can get to the form it can
 do the post
 but you say it cant access the cookie. But if the cookie value is just
 compared to the form post value
 we have to make sure that the name of the cookie cant be guessed right? So
 what should the name be?

 Because if the name would be wicket-form-uuid then couldnt the attacker
 also just generate that cookie?

 I guess there is a cookie per form (there can be many forms on the same
 page
 or different active pages)
 and that cookie must be regenerated/set on every form render?

 johan


 On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer 
 [EMAIL PROTECTED] wrote:



 Hi,

 my application currently uses CryptedUrlWebRequestCodingStrategy to
 protect against CRSF attacks. Afaik 1.3.5 will include an update that
 generates the key based on user sessions:
 http://issues.apache.org/jira/browse/WICKET-1782
 According to Johan Compagner, there are still issues with that
 approach, though I don't know if that has been fixed:
 http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593

 Anyway, the point of this mail is to bring up a different strategy for
 CSRF protection, the double-submitted-cookie. Discussion of that are
 here http://www.codinghorror.com/blog/archives/001175.html which links
 to this article, including a whitepaper:


 http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

 The basic idea is:

 When a user visits a site, the site should generate a
 (cryptographically strong) pseudorandom value and set it as a cookie
 on the user's machine. The site should require every form submission
 to include this pseudorandom value as a form value and also as a
 cookie value. When a POST request is sent to the site, the request
 should only be considered valid if the form value and the cookie value
 are the same. When an attacker submits a form on behalf of a user, he
 can only modify the values of the form. An attacker cannot read any
 data sent from the server or modify cookie values, per the same-origin
 policy. This means that while an attacker can send any value he wants
 with the form, he will be unable to modify or read the value stored in
 the cookie. Since the cookie value and the form value must be the
 same, the attacker will be unable to successfully submit a form unless
 he is able to guess the pseudorandom value.

 For Wicket, this would mean: Generate a pseudorandom value and set is
 as a session cookie, when the cookie doesn't yet exist. Insert a
 hidden input into each form with the generated value. Validate that
 the value equals the cookie when submitting a form. The input and
 validation can be abstracted into a Form subclass (or even add it to
 Wicket's Form class...).

 That really easy to implement, is much more efficient (generate only
 one value per user/browser session, store it on the client, not the
 server) and is now the most common strategy to protect against CSRF
 attacks. I've read a lot about CSRF, and this strategy seems the only
 one both easy enough to implement and without holes.

 What do you think? Should Wicket support that out-of-the-box?

 Jörn





 --
 -Wicket for love

 Nino 

Re: CSRF Protection: double submitted cookie

2008-10-20 Thread Johan Compagner
hmm i will read the paper then
I stil dont get it how it is possible with 1 cookie, that then can never
change when it is first generated
and all the forms also just have that value right?

But it is also for double submit protection right? So the cookie has to
change right?
But how can you then have 1 cookie? for all the forms?
If i submit one and that is rerendered or redirected to another page.
(so it has a new cookie so the double submit cant happen)
But if a new cookie is set then all other forms are also suddenly invalid..
and that looks pretty wrong to me

johan


On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer 
[EMAIL PROTECTED] wrote:

 No, the cookie is subject to the same-origin-policy, both in reading
 and writing. The request is authenticated because the session cookie
 is set, but its invalid when the form itself is missing the value.
 Combining the attack with XSS would give access to the cookie, but
 then he could just as well hijack the session directly.

 In other words: With CSRF alone there is no way for the attacker to
 read the cookie, therefore its enough to use just one.

 Their whitepaper may do a better job of explaining the techniquie:
 http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf
 Solutions are described on page 8ff.

 Jörn

 On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  what i dont get
  if an attacker wants to submit the form. and it can get to the form it
 can
  do the post
  but you say it cant access the cookie. But if the cookie value is just
  compared to the form post value
  we have to make sure that the name of the cookie cant be guessed right?
 So
  what should the name be?
 
  Because if the name would be wicket-form-uuid then couldnt the attacker
  also just generate that cookie?
 
  I guess there is a cookie per form (there can be many forms on the same
 page
  or different active pages)
  and that cookie must be regenerated/set on every form render?
 
  johan
 
 
  On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer 
  [EMAIL PROTECTED] wrote:
 
  Hi,
 
  my application currently uses CryptedUrlWebRequestCodingStrategy to
  protect against CRSF attacks. Afaik 1.3.5 will include an update that
  generates the key based on user sessions:
  http://issues.apache.org/jira/browse/WICKET-1782
  According to Johan Compagner, there are still issues with that
  approach, though I don't know if that has been fixed:
  http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593
 
  Anyway, the point of this mail is to bring up a different strategy for
  CSRF protection, the double-submitted-cookie. Discussion of that are
  here http://www.codinghorror.com/blog/archives/001175.html which links
  to this article, including a whitepaper:
 
 
 http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks
 
  The basic idea is:
 
  When a user visits a site, the site should generate a
  (cryptographically strong) pseudorandom value and set it as a cookie
  on the user's machine. The site should require every form submission
  to include this pseudorandom value as a form value and also as a
  cookie value. When a POST request is sent to the site, the request
  should only be considered valid if the form value and the cookie value
  are the same. When an attacker submits a form on behalf of a user, he
  can only modify the values of the form. An attacker cannot read any
  data sent from the server or modify cookie values, per the same-origin
  policy. This means that while an attacker can send any value he wants
  with the form, he will be unable to modify or read the value stored in
  the cookie. Since the cookie value and the form value must be the
  same, the attacker will be unable to successfully submit a form unless
  he is able to guess the pseudorandom value.
 
  For Wicket, this would mean: Generate a pseudorandom value and set is
  as a session cookie, when the cookie doesn't yet exist. Insert a
  hidden input into each form with the generated value. Validate that
  the value equals the cookie when submitting a form. The input and
  validation can be abstracted into a Form subclass (or even add it to
  Wicket's Form class...).
 
  That really easy to implement, is much more efficient (generate only
  one value per user/browser session, store it on the client, not the
  server) and is now the most common strategy to protect against CSRF
  attacks. I've read a lot about CSRF, and this strategy seems the only
  one both easy enough to implement and without holes.
 
  What do you think? Should Wicket support that out-of-the-box?
 
  Jörn
 
 



Re: CSRF Protection: double submitted cookie

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

Ahh, a no go for their filter then. The idea are very nice though.

Jörn Zaefferer wrote:

I've looked at CSRFGuard, the approach has several of the drawbacks
described in the paper. Its much less effective then the
double-submitted-cookie, eg. it involves buffering and rewriting the
response to modify forms. It generates values for each rendered form
and stores it in the user session
(http://www.owasp.org/index.php/How_CSRFGuard_Works). The
double-submitted-cookie doesn't require any serverstate at all.

I'm not sure what happens when you open multiple tabs/windows, but
considering that the value is stored in the session, it probably
breaks. Again something the cookie pattern isn't affected by.

Jörn

On Mon, Oct 20, 2008 at 12:42 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
  

I found this interesting:

Don't forget OWASP CSRFTester and CSRFGuard
http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks#comment-100619
Comment by Jeff Williams http://www.owasp.org on September 29th, 2008 at
9:53 am.

OWASP has made two tools available to help with CSRF problems. The first is
CSRFTester which will allow you to test your website for CSRF problems. The
tool allows you to create multi-step test cases and has been used to
transfer funds, create accounts, issue checks, etc...

The second tool is called CSRFGuard, and it's a Java EE filter that can be
placed in front of an entire application to provide CSRF protection.
CSRFGuard uses javascript to insert tokens into forms and links, and then
validates the token in every request.

You can find both free tools at http://www.owasp.org.;


Especially the part about the filter. If it's compatible with wicket and a
okay approach, I'd say forget about these things...




Johan Compagner wrote:


what i dont get
if an attacker wants to submit the form. and it can get to the form it can
do the post
but you say it cant access the cookie. But if the cookie value is just
compared to the form post value
we have to make sure that the name of the cookie cant be guessed right? So
what should the name be?

Because if the name would be wicket-form-uuid then couldnt the attacker
also just generate that cookie?

I guess there is a cookie per form (there can be many forms on the same
page
or different active pages)
and that cookie must be regenerated/set on every form render?

johan


On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer 
[EMAIL PROTECTED] wrote:


  

Hi,

my application currently uses CryptedUrlWebRequestCodingStrategy to
protect against CRSF attacks. Afaik 1.3.5 will include an update that
generates the key based on user sessions:
http://issues.apache.org/jira/browse/WICKET-1782
According to Johan Compagner, there are still issues with that
approach, though I don't know if that has been fixed:
http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593

Anyway, the point of this mail is to bring up a different strategy for
CSRF protection, the double-submitted-cookie. Discussion of that are
here http://www.codinghorror.com/blog/archives/001175.html which links
to this article, including a whitepaper:


http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

The basic idea is:

When a user visits a site, the site should generate a
(cryptographically strong) pseudorandom value and set it as a cookie
on the user's machine. The site should require every form submission
to include this pseudorandom value as a form value and also as a
cookie value. When a POST request is sent to the site, the request
should only be considered valid if the form value and the cookie value
are the same. When an attacker submits a form on behalf of a user, he
can only modify the values of the form. An attacker cannot read any
data sent from the server or modify cookie values, per the same-origin
policy. This means that while an attacker can send any value he wants
with the form, he will be unable to modify or read the value stored in
the cookie. Since the cookie value and the form value must be the
same, the attacker will be unable to successfully submit a form unless
he is able to guess the pseudorandom value.

For Wicket, this would mean: Generate a pseudorandom value and set is
as a session cookie, when the cookie doesn't yet exist. Insert a
hidden input into each form with the generated value. Validate that
the value equals the cookie when submitting a form. The input and
validation can be abstracted into a Form subclass (or even add it to
Wicket's Form class...).

That really easy to implement, is much more efficient (generate only
one value per user/browser session, store it on the client, not the
server) and is now the most common strategy to protect against CSRF
attacks. I've read a lot about CSRF, and this strategy seems the only
one both easy enough to implement and without holes.

What do you think? Should Wicket support that out-of-the-box?

Jörn


 

Re: Pages or components... how do u decide?

2008-10-20 Thread Jörn Zaefferer
The only markup difference between pages and panels for me is that
panels use wicket:panel and pages use wicket:extend. Making that the
same, I'd prefer wicket:extend, would make it even easier to switch
from a page to a panel and back.

Jörn

On Mon, Oct 20, 2008 at 10:22 AM, Ned Collyer [EMAIL PROTECTED] wrote:

 I use those annotations - they are awesome :)

 If you could annotate a panel to be bookmarkable.. that'd be interesting.
 So the panel COULD be embeded into other components, or used standalone as a
 page.

 Currently I achieve this by creating a new page class which instantiates and
 passes the panel to the super.

 Anyway, i thought it was an interesting thing to discuss.


 Jörn Zaefferer-2 wrote:

 A URL is quite a strong argument for using pages. With the
 wicket-annotations project its dead-easy to make pages bookmarkable,
 just add @MountPath(path=/path/to/page).

 Jörn


 --
 View this message in context: 
 http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20065174.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Multilingual website

2008-10-20 Thread newbieabc

Could someone direct me in how to go about making an exisiting website a
multilingual one in wicket framework?
General info, articles you can recommend would be great.
I'm in the starting phase so I don't have any specific questions yet.

Thanks
-- 
View this message in context: 
http://www.nabble.com/Multilingual-website-tp20067483p20067483.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: CSRF Protection: double submitted cookie

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

I found this interesting:

Don't forget OWASP CSRFTester and CSRFGuard 
http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks#comment-100619 

Comment by Jeff Williams http://www.owasp.org on September 29th, 2008 
at 9:53 am.


OWASP has made two tools available to help with CSRF problems. The first 
is CSRFTester which will allow you to test your website for CSRF 
problems. The tool allows you to create multi-step test cases and has 
been used to transfer funds, create accounts, issue checks, etc...


The second tool is called CSRFGuard, and it's a Java EE filter that can 
be placed in front of an entire application to provide CSRF protection. 
CSRFGuard uses javascript to insert tokens into forms and links, and 
then validates the token in every request.


You can find both free tools at http://www.owasp.org.;


Especially the part about the filter. If it's compatible with wicket and 
a okay approach, I'd say forget about these things...





Johan Compagner wrote:

what i dont get
if an attacker wants to submit the form. and it can get to the form it can
do the post
but you say it cant access the cookie. But if the cookie value is just
compared to the form post value
we have to make sure that the name of the cookie cant be guessed right? So
what should the name be?

Because if the name would be wicket-form-uuid then couldnt the attacker
also just generate that cookie?

I guess there is a cookie per form (there can be many forms on the same page
or different active pages)
and that cookie must be regenerated/set on every form render?

johan


On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer 
[EMAIL PROTECTED] wrote:

  

Hi,

my application currently uses CryptedUrlWebRequestCodingStrategy to
protect against CRSF attacks. Afaik 1.3.5 will include an update that
generates the key based on user sessions:
http://issues.apache.org/jira/browse/WICKET-1782
According to Johan Compagner, there are still issues with that
approach, though I don't know if that has been fixed:
http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593

Anyway, the point of this mail is to bring up a different strategy for
CSRF protection, the double-submitted-cookie. Discussion of that are
here http://www.codinghorror.com/blog/archives/001175.html which links
to this article, including a whitepaper:

http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

The basic idea is:

When a user visits a site, the site should generate a
(cryptographically strong) pseudorandom value and set it as a cookie
on the user's machine. The site should require every form submission
to include this pseudorandom value as a form value and also as a
cookie value. When a POST request is sent to the site, the request
should only be considered valid if the form value and the cookie value
are the same. When an attacker submits a form on behalf of a user, he
can only modify the values of the form. An attacker cannot read any
data sent from the server or modify cookie values, per the same-origin
policy. This means that while an attacker can send any value he wants
with the form, he will be unable to modify or read the value stored in
the cookie. Since the cookie value and the form value must be the
same, the attacker will be unable to successfully submit a form unless
he is able to guess the pseudorandom value.

For Wicket, this would mean: Generate a pseudorandom value and set is
as a session cookie, when the cookie doesn't yet exist. Insert a
hidden input into each form with the generated value. Validate that
the value equals the cookie when submitting a form. The input and
validation can be abstracted into a Form subclass (or even add it to
Wicket's Form class...).

That really easy to implement, is much more efficient (generate only
one value per user/browser session, store it on the client, not the
server) and is now the most common strategy to protect against CSRF
attacks. I've read a lot about CSRF, and this strategy seems the only
one both easy enough to implement and without holes.

What do you think? Should Wicket support that out-of-the-box?

Jörn




  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Multilingual website

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael
Is it just static multilingual, like help texts buttons etc.. Then you 
can use property files, database stuff etc.. There something about this 
on the wiki and in WIA..


If it's deeper like some of your classes descriptions, etc can be 
translated its another story.. A little more messy, unless you use 
JPA-translator. Im a developer on it, but it's been a bit inactive lately..


newbieabc wrote:

Could someone direct me in how to go about making an exisiting website a
multilingual one in wicket framework?
General info, articles you can recommend would be great.
I'm in the starting phase so I don't have any specific questions yet.

Thanks
  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



setObject( ), getObject( )

2008-10-20 Thread Ricky
Hi,

Is there any reason getObject and setObject were not made final in Model
class? the reason why i am asking is that there might be the case when
people misuse this; for example (and i have seen this at my current
workplace);

Model xModel = new Model(new Long(1)) {

@Override
public Object getObject() {
// return super.getObject(); -- not calling this, instead i
return null
return null;
}
};

// some lines afterwards ... i need this model ... i use it
(expecting to get back object i set)
// instead i get null. Original intent was to set object passed in
and get the same thing ...
System.out.println(xModel.getObject());

Here i get null as the result.

Any suggestions?

Regards
Vyas, Anirudh


Javascript callback

2008-10-20 Thread dideep

I've got a highly functional JS widget (a grid) which I'm trying to wrap up
in a wicket component.  The JS widget has an object it uses to talk to the
server - you tell this object a URL.  I've got as far as adding a
DefaultAjaxBehavior to my component and telling the JS widget the callback
URL - is this the right way to go?
-- 
View this message in context: 
http://www.nabble.com/Javascript-callback-tp20067507p20067507.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Javascript callback

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

Yes. if you checkout open layers contrib  mootips theres something there:

https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-openlayers/src/main/java/org/wicketstuff/openlayers/event/ClickEventListenerBehavior.java
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-minis/src/main/java/org/wicketstuff/minis/mootipbehavior/MootipAjaxListener.java


dideep wrote:

I've got a highly functional JS widget (a grid) which I'm trying to wrap up
in a wicket component.  The JS widget has an object it uses to talk to the
server - you tell this object a URL.  I've got as far as adding a
DefaultAjaxBehavior to my component and telling the JS widget the callback
URL - is this the right way to go?
  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Javascript callback

2008-10-20 Thread Martin Funk
2008/10/20, dideep [EMAIL PROTECTED]:

 I've got a highly functional JS widget (a grid) which I'm trying to wrap up
 in a wicket component.  The JS widget has an object it uses to talk to the
 server - you tell this object a URL.  I've got as far as adding a
 DefaultAjaxBehavior to my component and telling the JS widget the callback
 URL - is this the right way to go?
Well how shall we know ? :-)
If you are trying to solve something like a half object pattern, like
having the same sort of state on the client side (your widget) and on
the serverside (your component) plus trying to keep em in sync, than
DefaultAjaxBehavior might be a good starting point to get a
CallbackUrl for the JS widget to call back to.
That's what happens in the wicket-contib-gmap2 project of wicket-stuff.

mf
 --
 View this message in context:
 http://www.nabble.com/Javascript-callback-tp20067507p20067507.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DateTextField, format not valid, message key

2008-10-20 Thread Goran Novak

Hi,

I'm using the org.apache.wicket.datetime.markup.html.form.DateTextField
component for my date fields.

When I enter some random string in the text field in the feedback panel,
'asdfasdf' is not a valid Date. message appears.

I would like to customize that message, but I can't find which key I need to
insert in the properties file.

SomePage.properties --
...
dateTextField.NameOfValidator = The date is not valid custom message.
...
--

Does somebody know what do I need to insert instead of the NameOfValidator
string.

I searched the javadoc for the component and the web but didn't find the
validator name.

The component is defined as follows in the java file:

SomePage.java --
...
DateTextField dateTextField= new DateTextField(dateTextField, new
PropertyModel(model,propertyName), new
PatternDateConverter(dd.MM.,true));

dateTextField.add(new DatePicker());
add(dateTextField);
...
--

Thanks,
Goran

-- 
View this message in context: 
http://www.nabble.com/DateTextField%2C-format-not-valid%2C-message-key-tp20069519p20069519.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Model equals/hashCode

2008-10-20 Thread Alexander Landsnes Keül
Hi,

 

Is there any particular reason why Model doesn't implement a default equals(..) 
and hashCode() function? I have a very simple IDataProvider that simply wraps 
the returned object in a Model, and since I want to reuse the items I had to 
inline override the aforementioned functions.

 

Would it be possible to have those two functions implemented with a default in 
Model to just use the getObject().hashCode() and similar for equals for some 
future version? 

 

Alex



Re: CSRF Protection: double submitted cookie

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

Hmm and what about nested forms?

Johan Compagner wrote:

hmm i will read the paper then
I stil dont get it how it is possible with 1 cookie, that then can never
change when it is first generated
and all the forms also just have that value right?

But it is also for double submit protection right? So the cookie has to
change right?
But how can you then have 1 cookie? for all the forms?
If i submit one and that is rerendered or redirected to another page.
(so it has a new cookie so the double submit cant happen)
But if a new cookie is set then all other forms are also suddenly invalid..
and that looks pretty wrong to me

johan


On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer 
[EMAIL PROTECTED] wrote:

  

No, the cookie is subject to the same-origin-policy, both in reading
and writing. The request is authenticated because the session cookie
is set, but its invalid when the form itself is missing the value.
Combining the attack with XSS would give access to the cookie, but
then he could just as well hijack the session directly.

In other words: With CSRF alone there is no way for the attacker to
read the cookie, therefore its enough to use just one.

Their whitepaper may do a better job of explaining the techniquie:
http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf
Solutions are described on page 8ff.

Jörn

On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED]
wrote:


what i dont get
if an attacker wants to submit the form. and it can get to the form it
  

can


do the post
but you say it cant access the cookie. But if the cookie value is just
compared to the form post value
we have to make sure that the name of the cookie cant be guessed right?
  

So


what should the name be?

Because if the name would be wicket-form-uuid then couldnt the attacker
also just generate that cookie?

I guess there is a cookie per form (there can be many forms on the same
  

page


or different active pages)
and that cookie must be regenerated/set on every form render?

johan


On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer 
[EMAIL PROTECTED] wrote:

  

Hi,

my application currently uses CryptedUrlWebRequestCodingStrategy to
protect against CRSF attacks. Afaik 1.3.5 will include an update that
generates the key based on user sessions:
http://issues.apache.org/jira/browse/WICKET-1782
According to Johan Compagner, there are still issues with that
approach, though I don't know if that has been fixed:
http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593

Anyway, the point of this mail is to bring up a different strategy for
CSRF protection, the double-submitted-cookie. Discussion of that are
here http://www.codinghorror.com/blog/archives/001175.html which links
to this article, including a whitepaper:




http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks


The basic idea is:

When a user visits a site, the site should generate a
(cryptographically strong) pseudorandom value and set it as a cookie
on the user's machine. The site should require every form submission
to include this pseudorandom value as a form value and also as a
cookie value. When a POST request is sent to the site, the request
should only be considered valid if the form value and the cookie value
are the same. When an attacker submits a form on behalf of a user, he
can only modify the values of the form. An attacker cannot read any
data sent from the server or modify cookie values, per the same-origin
policy. This means that while an attacker can send any value he wants
with the form, he will be unable to modify or read the value stored in
the cookie. Since the cookie value and the form value must be the
same, the attacker will be unable to successfully submit a form unless
he is able to guess the pseudorandom value.

For Wicket, this would mean: Generate a pseudorandom value and set is
as a session cookie, when the cookie doesn't yet exist. Insert a
hidden input into each form with the generated value. Validate that
the value equals the cookie when submitting a form. The input and
validation can be abstracted into a Form subclass (or even add it to
Wicket's Form class...).

That really easy to implement, is much more efficient (generate only
one value per user/browser session, store it on the client, not the
server) and is now the most common strategy to protect against CSRF
attacks. I've read a lot about CSRF, and this strategy seems the only
one both easy enough to implement and without holes.

What do you think? Should Wicket support that out-of-the-box?

Jörn




  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: setObject( ), getObject( )

2008-10-20 Thread Igor Vaynberg
whenever there is something nonfinal people will always find a way to misuse it.

model methods are not final because it gives you a simple base class
to subclass instead of starting from scratch with an imodel.

-igor

On Mon, Oct 20, 2008 at 6:37 AM, Ricky [EMAIL PROTECTED] wrote:
 Hi,

 Is there any reason getObject and setObject were not made final in Model
 class? the reason why i am asking is that there might be the case when
 people misuse this; for example (and i have seen this at my current
 workplace);

Model xModel = new Model(new Long(1)) {

@Override
public Object getObject() {
// return super.getObject(); -- not calling this, instead i
 return null
return null;
}
};

// some lines afterwards ... i need this model ... i use it
 (expecting to get back object i set)
// instead i get null. Original intent was to set object passed in
 and get the same thing ...
System.out.println(xModel.getObject());

 Here i get null as the result.

 Any suggestions?

 Regards
 Vyas, Anirudh


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: DateTextField, format not valid, message key

2008-10-20 Thread Serkan Camurcuoglu

grepping the wicket source I found in file
src/jdk-1.4/wicket/src/main/java/org/apache/wicket/Application.properties:

IConverter='${input}' is not a valid ${type}.

but I don't know if you can specify a separate message for type Date..





Goran Novak wrote:
 
 Hi,
 
 I'm using the org.apache.wicket.datetime.markup.html.form.DateTextField
 component for my date fields.
 
 When I enter some random string in the text field in the feedback panel,
 'asdfasdf' is not a valid Date. message appears.
 
 I would like to customize that message, but I can't find which key I need
 to insert in the properties file.
 
 SomePage.properties --
 ...
 dateTextField.NameOfValidator = The date is not valid custom message.
 ...
 --
 
 Does somebody know what do I need to insert instead of the
 NameOfValidator string.
 
 I searched the javadoc for the component and the web but didn't find the
 validator name.
 
 The component is defined as follows in the java file:
 
 SomePage.java --
 ...
 DateTextField dateTextField= new DateTextField(dateTextField, new
 PropertyModel(model,  propertyName), new
 PatternDateConverter(dd.MM.,true));
 
 dateTextField.add(new DatePicker());
 add(dateTextField);
 ...
 --
 
 Thanks,
 Goran
 
 

-- 
View this message in context: 
http://www.nabble.com/DateTextField%2C-format-not-valid%2C-message-key-tp20069519p20071815.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: DateTextField, format not valid, message key

2008-10-20 Thread Serkan Camurcuoglu

Wicket in Action book says that IConverter.Date should work..




Serkan Camurcuoglu wrote:
 
 grepping the wicket source I found in file
 src/jdk-1.4/wicket/src/main/java/org/apache/wicket/Application.properties:
 
 IConverter='${input}' is not a valid ${type}.
 
 but I don't know if you can specify a separate message for type Date..
 
 
 
 
 
 Goran Novak wrote:
 
 Hi,
 
 I'm using the org.apache.wicket.datetime.markup.html.form.DateTextField
 component for my date fields.
 
 When I enter some random string in the text field in the feedback panel,
 'asdfasdf' is not a valid Date. message appears.
 
 I would like to customize that message, but I can't find which key I need
 to insert in the properties file.
 
 SomePage.properties --
 ...
 dateTextField.NameOfValidator = The date is not valid custom message.
 ...
 --
 
 Does somebody know what do I need to insert instead of the
 NameOfValidator string.
 
 I searched the javadoc for the component and the web but didn't find the
 validator name.
 
 The component is defined as follows in the java file:
 
 SomePage.java --
 ...
 DateTextField dateTextField= new DateTextField(dateTextField, new
 PropertyModel(model, propertyName), new
 PatternDateConverter(dd.MM.,true));
 
 dateTextField.add(new DatePicker());
 add(dateTextField);
 ...
 --
 
 Thanks,
 Goran
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/DateTextField%2C-format-not-valid%2C-message-key-tp20069519p20071867.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Wicket versus Spring MVC

2008-10-20 Thread Richard Allen
Joel,

What advantage does Tapestry 5 provide you over Wicket for your front office
pages?

Thanks,
Richard Allen

On Sun, Oct 19, 2008 at 8:17 AM, Joel Halbert [EMAIL PROTECTED] wrote:

 We're actually using two web frameworks in our application, depending on
 the type of page.

 Our application basically consists of two types of page:

 * front of shop / front office pages (these are the ones clients see like
 search results, product listings - characterised by high load  page
 impressions, relatively simple page logic and fewer components per page)

 * back office pages (these are the behind the scenes pages used to manage
 the shop, are more complex, require more state and have more complex logic
 and backing functionality and complex page component interactions).


 We basically use Wicket for the back office pages and Tapestry5 for the
 front office pages.

 I find this a great fit, both frameworks are well written and easy so we
 get to take advantage of the best bits of both!




 [EMAIL PROTECTED] wrote:

 Igor, I agree with Nino.

 What about posting something like that on wicketinaction.com? :-)

 Cheers,
 Bruno

 On Oct 17, 2008 2:41pm, Nino Saturnino Martinez Vazquez Wael 
 [EMAIL PROTECTED] wrote:

 Good mail Igor.



 Did you place it on the wiki, or a blog somewhere? It's very sound

 arguments. Especially the part about statefull/stateless web applications.






 Igor Vaynberg wrote:


 here is really what it comes down to:



 springmvc/struts/etc are geared towards building stateless applications.

 building something statefull is hard in these frameworks because the

 burden


 of having to juggle state is on you and it is hard/impossible to get
 right

 when doing manually.



 wicket is geared towrads building stateful applications. it takes care of

 the state juggling so you dont have to. it is, however, hard to build

 stateless applications in wicket because you have to take care to use
 only

 stateless components - and even then you are back to having to juggle

 state


 yourself.



 an important, but peripheral point, is that wicket takes full advantage
 of

 OOP. frameworks like springmvc/struts are highly procedural, they give

 you a


 hierarchy and you usually just extend it one level deep. in wicket you

 have


 to build custom class hierarchies so you can factor out all the common

 bits


 and pieces of your application. do your developers know how to do this

 properly? if you showed your developers the repeater hierarchy of

 repeatingview through datatable and asked them to choose a base class for

 their usecase would they complain that there are too many classes to

 choose


 from? this is quiet a common complaint on this list by people who come

 from


 struts and friends :)



 so in the end you have to look at the kind of application you are
 building

 and the type of developers you have, and pick the framework based on
 that.



 -igor



 On Thu, Oct 16, 2008 at 12:28 PM, Richard Allen

 [EMAIL PROTECTED]wrote:






 Hello,



 We have stateful, desktop-like Web applications based on Struts 1.x. We

 want

 to migrate them to a modern Java Web framework so we are trying to choose

 what framework to use. The decision will be left up to myself and another

 colleague with buy-in from other key people.



 The other colleague wants to use Spring MVC, which she just received

 training on from SpringSource. I want to use a component-based framework

 like Wicket. I think Wicket looks great, so I have been telling her that
 I

 think we should consider using it instead of Spring MVC. I think it is a

 better fit for the type of applications we produce.



 My colleague emailed the instructor from SpringSource and asked what he

 thought of us migrating to Wicket instead of Spring MVC. His response is

 below with my comments inlined. I would appreciate any convincing
 comments

 from Wicket experts.



 Thanks,

 Richard Allen



 Rich,



 Some background on what I am forwarding along...



 During last week's Spring Rich Client class I took full advantage of the

 fact I had unlimited access to a SpringSource consultant/instructor.



 When he asked people why they were there, I brought up that we were

 transitioning from Struts 1.X to something else, and the likely

 candidates were Spring MVC and Wicket.



 Many of my questions to him over the course of the 4 days were focused

 on that particular topic.



 And when he offered up his email address for contacts after the

 class, I wrote it down and got back in touch with him this week (getting

 our money's worth out of the face time, I like to think!) with some

 well-deserved adulation for the course, some questions about the Spring

 3.0 release schedule and finally, a summary of the Spring MVC vs. Wicket

 decision we face, trying to synthesize what I took away from the class.



 ***



 Specifically, in my email, I asked the question that you, an

 experienced web developer, posed to me about 

Re: RequestCycle.urlFor modifies a page's parameters?

2008-10-20 Thread Igor Vaynberg
i dont think this is normal. please file a jira issue.

-igor

On Fri, Oct 17, 2008 at 3:48 AM, aditsu [EMAIL PROTECTED] wrote:


 Hi, I'm using wicket 1.4-m3
 I was debugging a problem and I found that RequestCycle.urlFor(Component,
 RequestListenerInterface, ValueMap) can sometimes modify the parameters of
 an existing page.
 Here's the relevant code:

 if (listener != IRedirectListener.INTERFACE  component.isStateless() 
page.isBookmarkable()  page.getStatelessHint())
 {
PageParameters pageParameters = page.getPageParameters();
if (pageParameters == null)
{
pageParameters = new PageParameters();
}

if (params != null)
{
IteratorMap.EntryString, Object it =
 params.entrySet().iterator();
while (it.hasNext())
{
final Map.EntryString, Object
 entry = it.next();
final String key = entry.getKey();
final String value =
 entry.getValue().toString();
// Do not encode values here. It is
 the encoder's job
// to do the endoding. This leads to
 double encoding
// - Doug Donohoe
// @see
 https://issues.apache.org/jira/browse/WICKET-1627
pageParameters.add(key, value);
}
}

 Is this normal?

 --
 View this message in context:
 http://www.nabble.com/RequestCycle.urlFor-modifies-a-page%27s-parameters--tp20031013p20031013.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




@MountPath with same path

2008-10-20 Thread Cédric Thiébault
Hi,

I want to use REST url for my application using wicketstuff-annotation
but it seems that I can't use the same path for 2 pages.
For example :
- /products for the list of products
  @MountPath(path = products)
  public class ProductListPage extends Webpage

- /products/5 for the detail of product with id=5.
  @MountPath(path = products)
  @MountMixedParam(parameterNames = { id })
  public class ProductDetailPage extends Webpage

It throws an WicketRuntimeException: its is already mounted for
BookmarkablePageEncoder on start up.
I tried to use the patch described in
https://issues.apache.org/jira/browse/WICKET-1534 but it goes to first
page with this path (ie /products displays the product detail page for
id=null).

I also tried:
- /products for the list of products
  @MountPath(path = products)
  public class ProductListPage extends Webpage

- /products/detail/5 for the detail of product with id=5.
  @MountPath(path = products/detail)
  @MountMixedParam(parameterNames = { id })
  public class ProductDetailPage extends Webpage

but /products/detail/5 displays the list page because the list page
path is a subset of the detail page path.

Dis someone used this kind of urls with Wicket ?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: where is wicket-contrib-gmap3 1.3.4

2008-10-20 Thread overseastars

Thanks for replying




Martin Funk-3 wrote:
 
 2008/10/20 overseastars [EMAIL PROTECTED]
 

 Sorry I got some of my words missing.   I mean the latest
 wicket-contrib-gmap2-1.4 is not compatible with wicket-1.3.4.

 So the only way is to checkout the svn and DIY that jar file???
 
 If you wan't to stay 'on the edge' you can check out trunk, modify the
 dependency to wicket in the build.xml to the version you need and let the
 compiler guide you to the places that need to be patched.
 It's only a couple of places were the use of generics needs to be droped.
 Sorry for the inconveniance.
 
 mf
 




 overseastars wrote:
 
  Hi
 
  I'm using wicket 1.3.4 which is not compatible with
 wicket-contrib-gmap2
 
  Could anyone please tell me where i can find that jar file
 

 --
 View this message in context:
 http://www.nabble.com/where-is-wicket-contrib-gmap3-1.3.4-tp20063260p20063753.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 

-- 
View this message in context: 
http://www.nabble.com/where-is-wicket-contrib-gmap3-1.3.4-tp20063260p20074366.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: RequestCycle.urlFor modifies a page's parameters?

2008-10-20 Thread aditsu


igor.vaynberg wrote:
 
 i dont think this is normal. please file a jira issue.
 

Filed WICKET-1881

Thanks
Adrian
-- 
View this message in context: 
http://www.nabble.com/RequestCycle.urlFor-modifies-a-page%27s-parameters--tp20031013p20077002.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Feedback panel message

2008-10-20 Thread Steve Thompson
I've got a panel for which I am building a number of DropDownChoices.
Each must be selected, and if any one of them is not, a message must
be displayed in the corresponding feedback panel.  The problem however
is that, with my HTML as such:

table
   tr wicket:id=reasons
  tdspan wicket:id=description//td
  tdselect wicket:id=options name=options//td
   /tr
/table

the ${label} is always 'options' of course.  How could I associate
different DropDownChoice components in this scenario with a little bit
more legible name (like 'description')

Let me know and best regards,


Steve

--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Feedback panel message

2008-10-20 Thread Dane Laverty
Like so:

DropDownChoice myDropDownChoice = new DropDownChoice(...); 
myDropDownChoice.setLabel(new Model(Description));
add(myDropDownChoice);

Hope that helps.

-Original Message-
From: Steve Thompson [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 20, 2008 12:49 PM
To: users@wicket.apache.org
Subject: Feedback panel message

I've got a panel for which I am building a number of DropDownChoices.
Each must be selected, and if any one of them is not, a message must
be displayed in the corresponding feedback panel.  The problem however
is that, with my HTML as such:

table
   tr wicket:id=reasons
  tdspan wicket:id=description//td
  tdselect wicket:id=options name=options//td
   /tr
/table

the ${label} is always 'options' of course.  How could I associate
different DropDownChoice components in this scenario with a little bit
more legible name (like 'description')

Let me know and best regards,


Steve

--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: tomcat 6

2008-10-20 Thread Timm Helbig
Hi,

I use Tomcat 6.0.16/17/18 with the Wicket Example Application out of the box. 
No Problems at all. I suspect Tomcat is not the Problem.

Regards,
Timm

Am Monday 20 October 2008 09:30:32 schrieb Leucht, Axel:
 Hi,

 I'm currently trying to get a HelloWorld application running with wicket
 1.3.4.

 I'm doing all my web development from within the Eclipse IDE (3.4
 Ganymede), so I suspect setup of the project should be easy. When the
 server environment is set to tomcat 5.5.27 the HelloWorldApplication runs
 fine but NOT under tomcat 6.0.16!

 There is no clue in the logs stating that wicket is started in development
 mode which it is when started under tc 5.5.27. The application does run
 when I start tomcat 6.0.16 in standalone mode (outside Eclipse).

 Does someone knows what to do to make it run from within Eclipse?

 /Axel

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Feedback panel message

2008-10-20 Thread Steve Thompson
Dane -

Thanks, this worked like a charm!

On 10/20/08, Dane Laverty [EMAIL PROTECTED] wrote:
 Like so:

   DropDownChoice myDropDownChoice = new DropDownChoice(...);
   myDropDownChoice.setLabel(new Model(Description));
   add(myDropDownChoice);

 Hope that helps.

 -Original Message-
 From: Steve Thompson [mailto:[EMAIL PROTECTED]
 Sent: Monday, October 20, 2008 12:49 PM
 To: users@wicket.apache.org
 Subject: Feedback panel message

 I've got a panel for which I am building a number of DropDownChoices.
 Each must be selected, and if any one of them is not, a message must
 be displayed in the corresponding feedback panel.  The problem however
 is that, with my HTML as such:

 table
tr wicket:id=reasons
   tdspan wicket:id=description//td
   tdselect wicket:id=options name=options//td
/tr
 /table

 the ${label} is always 'options' of course.  How could I associate
 different DropDownChoice components in this scenario with a little bit
 more legible name (like 'description')

 Let me know and best regards,


 Steve

 --

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: @MountPath with same path

2008-10-20 Thread Jörn Zaefferer
How about mounting that to just products and displaying different
content based on the presence of the parameter? You abstract the
content of both pages into panels and show one or the other based on
the paramter.

Jörn

On Mon, Oct 20, 2008 at 6:15 PM, Cédric Thiébault
[EMAIL PROTECTED] wrote:
 Hi,

 I want to use REST url for my application using wicketstuff-annotation
 but it seems that I can't use the same path for 2 pages.
 For example :
 - /products for the list of products
  @MountPath(path = products)
  public class ProductListPage extends Webpage

 - /products/5 for the detail of product with id=5.
  @MountPath(path = products)
  @MountMixedParam(parameterNames = { id })
  public class ProductDetailPage extends Webpage

 It throws an WicketRuntimeException: its is already mounted for
 BookmarkablePageEncoder on start up.
 I tried to use the patch described in
 https://issues.apache.org/jira/browse/WICKET-1534 but it goes to first
 page with this path (ie /products displays the product detail page for
 id=null).

 I also tried:
 - /products for the list of products
  @MountPath(path = products)
  public class ProductListPage extends Webpage

 - /products/detail/5 for the detail of product with id=5.
  @MountPath(path = products/detail)
  @MountMixedParam(parameterNames = { id })
  public class ProductDetailPage extends Webpage

 but /products/detail/5 displays the list page because the list page
 path is a subset of the detail page path.

 Dis someone used this kind of urls with Wicket ?

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: wicket war file has problems with tomcat

2008-10-20 Thread overseastars


Hi igor

I dont know how to fix this. I already copyied all jar files under WEB-INF
to tomcat6's lib folder.




igor.vaynberg wrote:
 
looks like you are missing slf4j jars in your war?
 
-igor
 
On Mon, Oct 20, 2008 at 10:18 AM, overseastars [EMAIL PROTECTED]
wrote:


 Hi all

 I dont know why but my war file cannot run on tomcat6. Could anyone show
 me
 a way to fix the problem?
 I just checked the log under tomcat. it gave me the following. I actually
 already copy all jar files under the WEB-INF/lib to the lib folder under
 tomcat home.  Something else needed? I've no idea. Thanks in
 advance..


 21/10/2008 04:01:53 org.apache.catalina.core.StandardContext filterStart
 SEVERE: Exception starting filter WicketFilter
 java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.apache.wicket.jmx.Initializer.clinit(Initializer.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
at
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at
 org.apache.wicket.util.lang.Objects.newInstance(Objects.java:1011)
at
 org.apache.wicket.Application.addInitializer(Application.java:755)
at org.apache.wicket.Application.load(Application.java:829)
at
 org.apache.wicket.Application.initializeComponents(Application.java:608)
at
 org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:567)
at
 org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
at
 org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
at
 org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:108)
at
 org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709)
at
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4363)
at
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at
 org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
at
 org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:719)
at
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at
 org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
at
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at
 org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
 21/10/2008 04:01:54 org.apache.catalina.core.ApplicationContext log
 INFO: ContextListener: contextInitialized()
 21/10/2008 04:01:54 org.apache.catalina.core.ApplicationContext log
 INFO: SessionListener: contextInitialized()
 21/10/2008 04:03:56 org.apache.catalina.core.ApplicationContext log
 INFO: SessionListener: contextDestroyed()
 21/10/2008 04:03:56 org.apache.catalina.core.ApplicationContext log
 INFO: ContextListener: contextDestroyed()
 21/10/2008 04:04:06 org.apache.catalina.core.StandardContext filterStart
 SEVERE: Exception starting filter WicketFilter
 java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.apache.wicket.jmx.Initializer.clinit(Initializer.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
at
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
 

Re: wicket war file has problems with tomcat

2008-10-20 Thread claym

I don't think you want your app jars in the server lib directory.

Those .jars should be in /WEB-INF/lib

-Clay



overseastars wrote:
 
 
 Hi igor
 
 I dont know how to fix this. I already copyied all jar files under WEB-INF
 to tomcat6's lib folder.
 
 
 

 igor.vaynberg wrote:
 
looks like you are missing slf4j jars in your war?
 
-igor
 
On Mon, Oct 20, 2008 at 10:18 AM, overseastars [EMAIL PROTECTED]
wrote:


 Hi all

 I dont know why but my war file cannot run on tomcat6. Could anyone show
 me
 a way to fix the problem?
 I just checked the log under tomcat. it gave me the following. I
 actually
 already copy all jar files under the WEB-INF/lib to the lib folder under
 tomcat home.  Something else needed? I've no idea. Thanks in
 advance..


 21/10/2008 04:01:53 org.apache.catalina.core.StandardContext filterStart
 SEVERE: Exception starting filter WicketFilter
 java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at
 org.apache.wicket.jmx.Initializer.clinit(Initializer.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
at
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at
 java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at
 org.apache.wicket.util.lang.Objects.newInstance(Objects.java:1011)
at
 org.apache.wicket.Application.addInitializer(Application.java:755)
at org.apache.wicket.Application.load(Application.java:829)
at
 org.apache.wicket.Application.initializeComponents(Application.java:608)
at
 org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:567)
at
 org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
at
 org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
at
 org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:108)
at
 org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709)
at
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4363)
at
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at
 org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
at
 org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:719)
at
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at
 org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
at
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at
 org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at
 org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
 org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
 21/10/2008 04:01:54 org.apache.catalina.core.ApplicationContext log
 INFO: ContextListener: contextInitialized()
 21/10/2008 04:01:54 org.apache.catalina.core.ApplicationContext log
 INFO: SessionListener: contextInitialized()
 21/10/2008 04:03:56 org.apache.catalina.core.ApplicationContext log
 INFO: SessionListener: contextDestroyed()
 21/10/2008 04:03:56 org.apache.catalina.core.ApplicationContext log
 INFO: ContextListener: contextDestroyed()
 21/10/2008 04:04:06 org.apache.catalina.core.StandardContext filterStart
 SEVERE: Exception starting filter WicketFilter
 java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at
 org.apache.wicket.jmx.Initializer.clinit(Initializer.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
at
 

Re: Setting title dynamically on Modalwindow

2008-10-20 Thread Kuga

Can anyone please help me with this?
Kind of not getting any clue.
Appreciate any help.
thanks
Kuga

Kuga wrote:
 
 Hi,
 Can anyone help me with the following. Thanks in advance for any help.
 I need to update the Title of the Modalwindow based on some actions on the
 dialog. For example say i have added wizard in my modalwindow, the Title
 needs to displayed as follows:
 Test Title : Step 1 of 2, if i go to the next step, the title needs to
 be chaged to Test Title  Step 2 of 2.
 
 Note: I have the ajax request target for any updates.
 thanks
 Kuga
 

-- 
View this message in context: 
http://www.nabble.com/Setting-title-dynamically-on-Modalwindow-tp20062552p20083274.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



how to redirect wicket pages using javascript

2008-10-20 Thread freak182

Hello,

I have a project which uses mostly javascript because it is a client base
part. My problem is when i cannot redirect wicket pages in javascript. I
already try this in behavior:

.
init.js

function clientReady() {

 location.href = '${url}';

}

in behavior...

final Map params = 

 map.put(url , RequestCycle.get().urlFor(new TestPage());

component.add(TextTemplateHeaderContributor.forJavaScript(InitBehavior.class,
init.js, params));
super.bind(component);

i get an error:
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:149)
... 29 more
Caused by: java.lang.IllegalArgumentException: Upper bound for nextInt must
be positive
at org.apache.commons.lang.math.JVMRandom.nextInt(JVMRandom.java:104)
at org.apache.commons.lang.math.RandomUtils.nextInt(RandomUtils.java:88)
at org.apache.commons.lang.math.RandomUtils.nextInt(RandomUtils.java:74)
at
com.ccti.digibanker.arcot.service.ArcotUserQAServiceImpl.get3QA(ArcotUserQAServiceImpl.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy20.get3QA(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler.invoke(LazyInitProxyFactory.java:416)
at org.apache.wicket.proxy.$Proxy23.get3QA(Unknown Source)
at
com.ccti.digibanker.arcot.process.ArcotNoIdPage.init(ArcotNoIdPage.java:49)
... 34 more

any idea...Thanks a lot...Cheers.
-- 
View this message in context: 
http://www.nabble.com/how-to-redirect-wicket-pages-using-javascript-tp20083835p20083835.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]