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]

Reply via email to