On Wed, Feb 27, 2008 at 10:10 PM, Roberto Fasciolo
<[EMAIL PROTECTED]> wrote:
>
> Based on this page in wiki:
> http://cwiki.apache.org/WICKET/stateless-pages.html a page is stateless if
> all the components in it are stateless.
> My sign in page contains a SignInPanel (from wicket-auth-roles) and 2 links.
> I can change the links to StatelessLink, but how can I make SignInPanel
> (that contains a Form, not a StatelessForm) stateless? Is writing my own
> version of it the only solution?
yep. not sure signinpanel was meant for you to be used directly, its
more of an example... in fact the entire wicket-auth-roles is more of
an example rather then something to be used as a library.
-igor
>
> -Roberto
>
>
>
>
> igor.vaynberg wrote:
> >
> > is your sign in page stateless? if its not it will need to be stored in
> > session.
> >
> > re ddos attacks, its really the job of the application server to
> > prevent an exorbitant amount of sessions opened from what looks like
> > the same ip or however it decides to do that. ie there are plenty of
> > jsp/struts applications that create a session on the first hit.
> >
> > what wicket does is provide a page eviction strategy so once created
> > an attacker cannot grow the session infinitely
> >
> > -igor
> >
> >
> > On Wed, Feb 27, 2008 at 11:10 AM, Roberto Fasciolo
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> Our application is totally hidden behind authentication, so in our case
> >> the
> >> session (I'm talking about an object extending AuthenticatedWebSession)
> >> is
> >> created without any page navigation, just by opening the sign in page.
> >>
> >> Anyway, how can you deal with DoS attacks? I mean, it'll be really easy
> >> to
> >> write a small script continuously opening pages on a wicket site (or
> >> creating new sessions) until the site would die by OutOfMemoryError.
> >>
> >> But back in track, I don't see anything bad in, instead creating a new
> >> session just for calling getRoles() and getting null, returning directly
> >> null (= user not in any role) if the user never signed in before.
> >>
> >>
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > wicket uses session to store pages, so creating a session is
> >> > orthogonal to authorizing/authenticating a user
> >> >
> >> > -igor
> >> >
> >> > On Wed, Feb 27, 2008 at 9:04 AM, Roberto Fasciolo
> >> > <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I noticed some strange behavior on my webapplication that has
> >> >> authorization
> >> >> in place (by using Roles).
> >> >>
> >> >> It seems that Wicket creates a session for checking the role of the
> >> user
> >> >> even the user has not logged in. I'd guess the preferred behavior
> >> would
> >> >> be
> >> >> that wicket would in this occasion first check if there is a session
> >> and
> >> >> if
> >> >> not, then just let the authorization fail instead of creating
> >> session
> >> >> and
> >> >> then checking if role is there.
> >> >>
> >> >> I did simple trace to find what is calling MySession constructor:
> >> >>
> >> >> public MySession(final AuthenticatedWebApplication application,
> >> >> final Request request) {
> >> >> super(application, request);
> >> >> this.logger.error("Created session", new Throwable());
> >> >> }
> >> >>
> >> >> 18:56:16,634 (btpool0-5) ERROR [MySession] - Created session
> >> >> java.lang.Throwable
> >> >> at MySession.<init>(MySession.java:39)
> >> >> 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.authentication.AuthenticatedWebApplication.newSession(AuthenticatedWebApplication.java:114)
> >> >>
> >> >> at org.apache.wicket.Session.findOrCreate(Session.java:225)
> >> >> at org.apache.wicket.Session.findOrCreate(Session.java:208)
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Wicket-creating-a-session-for-authorization-even-if-no-user-signed-in-tp15717761p15717761.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/Wicket-creating-a-session-for-authorization-even-if-no-user-signed-in-tp15717761p15720619.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/Wicket-creating-a-session-for-authorization-even-if-no-user-signed-in-tp15717761p15730372.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]
