You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Marcelo Morales <ma...@gmail.com> on 2008/08/06 21:23:46 UTC
Questions about wicket features
Hello
I've browsed over the wicket documentation and examples. There are a
couple of things I don't seem able to determine. So I would really
appreciate your input on this questions.
1 Can I write a web application without coding any HTML whatsoever?...
I mean, is there some kind of "html" or "whole page" component which
renders an entire HTML page?
2 Is there a way to work on dialogs (also known as conversations) as
opposed to sessions?... maybe this question is nonsense and I didn't
understand the whole page version management mechanism.
3 Does it come with some kind of integration testing?
4 Is it possible (or feasible) to implement some kind of "page
hardening"? I am seeking something to protect victims of CSRF attacks
from other sites. A input name randomizer comes to mind (which would
make it impossible to selenium test it)
Regads
Marcelo Morales
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Questions about wicket features
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> Hello
>
> I've browsed over the wicket documentation and examples. There are a
> couple of things I don't seem able to determine. So I would really
> appreciate your input on this questions.
>
> 1. Can I write a web application without coding any HTML
whatsoever?...
> I mean, is there some kind of "html" or "whole page" component which
> renders an entire HTML page?
You need to use something like Echo2 or Echo3 to write pure Java web
apps with no HTML whatsoever. All the HTML and all the AJAX is
completely transparent to the developer - it's more like writing a
desktop app than a web app which has benefits if you come from a
Java/C++ background and some disadvantages if you like having the power
to hack around with HTML and Javascript code.
With wicket you're still in control of the markup (HTML) which means you
have to write it but it's pretty straightforward. There is support for a
single section of markup to be overridden (inheritance) from a base page
markup to a derived page markup which means you can perform some level
of markup reusability at the page level. On some occasions I've found
the need to have multiple sections in a base markup to be 'overridable'
in a derived markup pages but this is not yet possible as far as I know.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Marcelo Morales <ma...@gmail.com>.
Thank you all
Marcelo Morales
On Thu, Aug 7, 2008 at 2:44 AM, Erik van Oosten <e....@grons.nl> wrote:
> Hello Marcelo,
>
> 1. No. The flip side of having full control of the HTML is that you need
> to write it yourself.
>
> 2. In Wicket it is trivial to keep state (read the conversation state)
> on the server, local to the dialog/panel you are working with. No
> official conversation support is therefore needed.
>
> 3. Yes. See WicketTester.
>
> 4. Yes. See mailing list for earlier answers. There are more hardening
> options such as encrypting urls.
>
> Regards,
> Erik.
>
>
> Marcelo Morales wrote:
>> Hello
>>
>> I've browsed over the wicket documentation and examples. There are a
>> couple of things I don't seem able to determine. So I would really
>> appreciate your input on this questions.
>>
>> 1 Can I write a web application without coding any HTML whatsoever?...
>> I mean, is there some kind of "html" or "whole page" component which
>> renders an entire HTML page?
>> 2 Is there a way to work on dialogs (also known as conversations) as
>> opposed to sessions?... maybe this question is nonsense and I didn't
>> understand the whole page version management mechanism.
>> 3 Does it come with some kind of integration testing?
>> 4 Is it possible (or feasible) to implement some kind of "page
>> hardening"? I am seeking something to protect victims of CSRF attacks
>> from other sites. A input name randomizer comes to mind (which would
>> make it impossible to selenium test it)
>>
>> Regads
>>
>> Marcelo Morales
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> --
>
> --
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Erik van Oosten <e....@grons.nl>.
I was talking about the case where you are silly enough to code an
action in the constructor of a bookmarkable page. (Really, I have seen
it happen.)
Regards,
Erik.
Martijn Dashorst wrote:
> but all actions on bookmarkable pages have session relative urls,
> which makes guessing the correct URL still problematic.
>
> Martijn
>
>
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Martijn Dashorst <ma...@gmail.com>.
but all actions on bookmarkable pages have session relative urls,
which makes guessing the correct URL still problematic.
Martijn
On Thu, Aug 7, 2008 at 3:16 PM, Erik van Oosten <e....@grons.nl> wrote:
>
> Johan Compagner wrote:
>> ...Which is pretty random. Only if all users would go over the same path
>> always to the same page then the id could be guessed.
>>
> Actually, I do not think that is completely far fetched. In my banking
> applications I mostly follow the same path. In some applications there
> may be a high change that the guessed path is correct.
> Then again, it is easily fixed by starting at a random page version number.
>
> In addition, many Wicket applications use bookmarkable pages. Easily
> avoided if you're worried about CSRF of course.
>
> Regards,
> Erik.
>
> --
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Erik van Oosten <e....@grons.nl>.
Johan Compagner wrote:
> ...Which is pretty random. Only if all users would go over the same path
> always to the same page then the id could be guessed.
>
Actually, I do not think that is completely far fetched. In my banking
applications I mostly follow the same path. In some applications there
may be a high change that the guessed path is correct.
Then again, it is easily fixed by starting at a random page version number.
In addition, many Wicket applications use bookmarkable pages. Easily
avoided if you're worried about CSRF of course.
Regards,
Erik.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Johan Compagner <jc...@gmail.com>.
CSRF uses urls to do something on another side right?
for example
<img src="
http://bank.example/withdraw?account=bob&amount=1000000&for=mallory">
How would that work in a default wicket application?
Is it really so stupid developed that these kind of things uses client side
state?
So this cant be done with just an url. So you have to have real scripting..
So for this to work in wicket you have to know upfront so many things..
First the page id of the bank transfer page.. Which is pretty random. Only
if all users would go over the same path always to the same page
then the id could be guessed.
Then it has to get the right form, fill in the right values and do the
submit
And do modern browsers allow js script like that?
johan
On Thu, Aug 7, 2008 at 10:54 AM, Arthur Ahiceh <ar...@gmail.com>wrote:
>
> >> 4. Yes. See mailing list for earlier answers. There are more hardening
> options such as encrypting urls.
>
> Even encrypting the urls Wicket is vulnerable to CSRF because the key used
> to encrypt is shared by all users of application. Wicket is an extensible
> framework where you to add some new functionallity "easily" but it doesn't
> provide any secure solution by default to protect you against CSRF attacks!
>
>
>
>
> Erik van Oosten wrote:
> >
> > Hello Marcelo,
> >
> > 1. No. The flip side of having full control of the HTML is that you need
> > to write it yourself.
> >
> > 2. In Wicket it is trivial to keep state (read the conversation state)
> > on the server, local to the dialog/panel you are working with. No
> > official conversation support is therefore needed.
> >
> > 3. Yes. See WicketTester.
> >
> > 4. Yes. See mailing list for earlier answers. There are more hardening
> > options such as encrypting urls.
> >
> > Regards,
> > Erik.
> >
> >
> > Marcelo Morales wrote:
> >> Hello
> >>
> >> I've browsed over the wicket documentation and examples. There are a
> >> couple of things I don't seem able to determine. So I would really
> >> appreciate your input on this questions.
> >>
> >> 1 Can I write a web application without coding any HTML whatsoever?...
> >> I mean, is there some kind of "html" or "whole page" component which
> >> renders an entire HTML page?
> >> 2 Is there a way to work on dialogs (also known as conversations) as
> >> opposed to sessions?... maybe this question is nonsense and I didn't
> >> understand the whole page version management mechanism.
> >> 3 Does it come with some kind of integration testing?
> >> 4 Is it possible (or feasible) to implement some kind of "page
> >> hardening"? I am seeking something to protect victims of CSRF attacks
> >> from other sites. A input name randomizer comes to mind (which would
> >> make it impossible to selenium test it)
> >>
> >> Regads
> >>
> >> Marcelo Morales
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > --
> >
> > --
> > Erik van Oosten
> > http://day-to-day-stuff.blogspot.com/
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Questions-about-wicket-features-tp18857860p18866486.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Questions about wicket features
Posted by Arthur Ahiceh <ar...@gmail.com>.
Martijn, this solution is correct but I tell that I said in post [1]...
Wicket is a framework where you can implement an easy solution but I prefer
that these types of solutions were distributed by default!
[1]
http://www.nabble.com/Security-Features-offered-by-Wicket-to15738864.html#a15738864
Arthur
Martijn Dashorst wrote:
>
> This assumes that the hacker correctly guesses the application key
> (which you of course changed from the default setting), or has access
> to your application to harvest URLs.
>
> Making the SunJceCrypt user specific is as simple as:
>
> new SunJceCrypt() {
> @Override public String getKey() {
> return MySession.get().getUserKey();
> }
> }
>
> And all you have to do is implement your own user key generation that
> generates a key based on some random information and is constant
> throughout the session (e.g. md5 sum of a salt + Random.nextInt).
>
> Martijn
>
> On Thu, Aug 7, 2008 at 11:28 AM, Arthur Ahiceh <ar...@gmail.com>
> wrote:
>>
>>
>> ok! you have not used the word "easily" but only saying "There are more
>> hardening options such as encrypting urls" it only seems that encrypting
>> urls the problem is solved and it is not the case! The user has to
>> implement a custom security factory, one different than provided by
>> Wicket
>> (SunJceCrypt), to resolve CSRF.
>>
>>
>> Erik van Oosten wrote:
>>>
>>>
>>> Arthur Ahiceh wrote:
>>>>>> 4. Yes. See mailing list for earlier answers. There are more
>>>>>> hardening
>>>>>> options such as encrypting urls.
>>>>>>
>>>>
>>>> Even encrypting the urls Wicket is vulnerable to CSRF because the key
>>>> used
>>>> to encrypt is shared by all users of application. Wicket is an
>>>> extensible
>>>> framework where you to add some new functionallity "easily" but it
>>>> doesn't
>>>> provide any secure solution by default to protect you against CSRF
>>>> attacks!
>>> Correct indeed. Also note, I did not use the word 'easily' :)
>>>
>>> Regards,
>>> Erik.
>>>
>>> --
>>> Erik van Oosten
>>> http://day-to-day-stuff.blogspot.com/
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Questions-about-wicket-features-tp18857860p18866928.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Questions-about-wicket-features-tp18857860p18870094.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Martijn Dashorst <ma...@gmail.com>.
This assumes that the hacker correctly guesses the application key
(which you of course changed from the default setting), or has access
to your application to harvest URLs.
Making the SunJceCrypt user specific is as simple as:
new SunJceCrypt() {
@Override public String getKey() {
return MySession.get().getUserKey();
}
}
And all you have to do is implement your own user key generation that
generates a key based on some random information and is constant
throughout the session (e.g. md5 sum of a salt + Random.nextInt).
Martijn
On Thu, Aug 7, 2008 at 11:28 AM, Arthur Ahiceh <ar...@gmail.com> wrote:
>
>
> ok! you have not used the word "easily" but only saying "There are more
> hardening options such as encrypting urls" it only seems that encrypting
> urls the problem is solved and it is not the case! The user has to
> implement a custom security factory, one different than provided by Wicket
> (SunJceCrypt), to resolve CSRF.
>
>
> Erik van Oosten wrote:
>>
>>
>> Arthur Ahiceh wrote:
>>>>> 4. Yes. See mailing list for earlier answers. There are more hardening
>>>>> options such as encrypting urls.
>>>>>
>>>
>>> Even encrypting the urls Wicket is vulnerable to CSRF because the key
>>> used
>>> to encrypt is shared by all users of application. Wicket is an extensible
>>> framework where you to add some new functionallity "easily" but it
>>> doesn't
>>> provide any secure solution by default to protect you against CSRF
>>> attacks!
>> Correct indeed. Also note, I did not use the word 'easily' :)
>>
>> Regards,
>> Erik.
>>
>> --
>> Erik van Oosten
>> http://day-to-day-stuff.blogspot.com/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Questions-about-wicket-features-tp18857860p18866928.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Erik van Oosten <e....@grons.nl>.
Arthur Ahiceh write:
> Erik, if you did not mean that I feel it, I understood that. ;-)
>
> Arthur
>
Okay, thanks. (I didn't.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Arthur Ahiceh <ar...@gmail.com>.
Erik, if you did not mean that I feel it, I understood that. ;-)
Arthur
Erik van Oosten wrote:
>
> Arthur Ahiceh wrote:
>> ok! you have not used the word "easily" but only saying "There are more
>> hardening options such as encrypting urls" it only seems that encrypting
>> urls the problem is solved and it is not the case! The user has to
>> implement a custom security factory, one different than provided by
>> Wicket
>> (SunJceCrypt), to resolve CSRF.
>>
> Come on, I did not (intend to) suggest that URL encryption solves CSRF
> attacks. It is *another* hardening strategy.
>
> Erik.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Questions-about-wicket-features-tp18857860p18870076.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Erik van Oosten <e....@grons.nl>.
Arthur Ahiceh wrote:
> ok! you have not used the word "easily" but only saying "There are more
> hardening options such as encrypting urls" it only seems that encrypting
> urls the problem is solved and it is not the case! The user has to
> implement a custom security factory, one different than provided by Wicket
> (SunJceCrypt), to resolve CSRF.
>
Come on, I did not (intend to) suggest that URL encryption solves CSRF
attacks. It is *another* hardening strategy.
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Arthur Ahiceh <ar...@gmail.com>.
ok! you have not used the word "easily" but only saying "There are more
hardening options such as encrypting urls" it only seems that encrypting
urls the problem is solved and it is not the case! The user has to
implement a custom security factory, one different than provided by Wicket
(SunJceCrypt), to resolve CSRF.
Erik van Oosten wrote:
>
>
> Arthur Ahiceh wrote:
>>>> 4. Yes. See mailing list for earlier answers. There are more hardening
>>>> options such as encrypting urls.
>>>>
>>
>> Even encrypting the urls Wicket is vulnerable to CSRF because the key
>> used
>> to encrypt is shared by all users of application. Wicket is an extensible
>> framework where you to add some new functionallity "easily" but it
>> doesn't
>> provide any secure solution by default to protect you against CSRF
>> attacks!
> Correct indeed. Also note, I did not use the word 'easily' :)
>
> Regards,
> Erik.
>
> --
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Questions-about-wicket-features-tp18857860p18866928.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Erik van Oosten <e....@grons.nl>.
Arthur Ahiceh wrote:
>>> 4. Yes. See mailing list for earlier answers. There are more hardening
>>> options such as encrypting urls.
>>>
>
> Even encrypting the urls Wicket is vulnerable to CSRF because the key used
> to encrypt is shared by all users of application. Wicket is an extensible
> framework where you to add some new functionallity "easily" but it doesn't
> provide any secure solution by default to protect you against CSRF attacks!
Correct indeed. Also note, I did not use the word 'easily' :)
Regards,
Erik.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Arthur Ahiceh <ar...@gmail.com>.
>> 4. Yes. See mailing list for earlier answers. There are more hardening
options such as encrypting urls.
Even encrypting the urls Wicket is vulnerable to CSRF because the key used
to encrypt is shared by all users of application. Wicket is an extensible
framework where you to add some new functionallity "easily" but it doesn't
provide any secure solution by default to protect you against CSRF attacks!
Erik van Oosten wrote:
>
> Hello Marcelo,
>
> 1. No. The flip side of having full control of the HTML is that you need
> to write it yourself.
>
> 2. In Wicket it is trivial to keep state (read the conversation state)
> on the server, local to the dialog/panel you are working with. No
> official conversation support is therefore needed.
>
> 3. Yes. See WicketTester.
>
> 4. Yes. See mailing list for earlier answers. There are more hardening
> options such as encrypting urls.
>
> Regards,
> Erik.
>
>
> Marcelo Morales wrote:
>> Hello
>>
>> I've browsed over the wicket documentation and examples. There are a
>> couple of things I don't seem able to determine. So I would really
>> appreciate your input on this questions.
>>
>> 1 Can I write a web application without coding any HTML whatsoever?...
>> I mean, is there some kind of "html" or "whole page" component which
>> renders an entire HTML page?
>> 2 Is there a way to work on dialogs (also known as conversations) as
>> opposed to sessions?... maybe this question is nonsense and I didn't
>> understand the whole page version management mechanism.
>> 3 Does it come with some kind of integration testing?
>> 4 Is it possible (or feasible) to implement some kind of "page
>> hardening"? I am seeking something to protect victims of CSRF attacks
>> from other sites. A input name randomizer comes to mind (which would
>> make it impossible to selenium test it)
>>
>> Regads
>>
>> Marcelo Morales
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> --
>
> --
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Questions-about-wicket-features-tp18857860p18866486.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Questions about wicket features
Posted by Erik van Oosten <e....@grons.nl>.
Hello Marcelo,
1. No. The flip side of having full control of the HTML is that you need
to write it yourself.
2. In Wicket it is trivial to keep state (read the conversation state)
on the server, local to the dialog/panel you are working with. No
official conversation support is therefore needed.
3. Yes. See WicketTester.
4. Yes. See mailing list for earlier answers. There are more hardening
options such as encrypting urls.
Regards,
Erik.
Marcelo Morales wrote:
> Hello
>
> I've browsed over the wicket documentation and examples. There are a
> couple of things I don't seem able to determine. So I would really
> appreciate your input on this questions.
>
> 1 Can I write a web application without coding any HTML whatsoever?...
> I mean, is there some kind of "html" or "whole page" component which
> renders an entire HTML page?
> 2 Is there a way to work on dialogs (also known as conversations) as
> opposed to sessions?... maybe this question is nonsense and I didn't
> understand the whole page version management mechanism.
> 3 Does it come with some kind of integration testing?
> 4 Is it possible (or feasible) to implement some kind of "page
> hardening"? I am seeking something to protect victims of CSRF attacks
> from other sites. A input name randomizer comes to mind (which would
> make it impossible to selenium test it)
>
> Regads
>
> Marcelo Morales
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org