logout

[Tom Eugelink <tb...@tbee.org>]

I've started a new project and decided to use Wicket for the web component again. Still intrigued enough to be curious how it will work out.

Anyhow, I've added Wicket Auth/Roles (http://wicket.apache.org/learn/projects/authroles.html) as the security framework and it is working fine except one thing; logging out. I am invalidating the session but the next time I want to log in, the credentials of the previous login are picked up automatically. Maybe sometime during testing I had the "remember me" checkbox selected, I don't know but I don't believe so, but this now causing me problems.

1. How can I stop this cross-session autologin?
2. How can I do a full log out?

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: logout

[Martin Grigorov <mg...@apache.org>]

wicket-auth-roles is actually an example of IAuthenticationStrategy
and IAuthorizationStrategy interfaces.
Most of the people that use it actually just see how it works and
copy/paste the related parts of it and later extend them with their
specific business logic.

afaik it uses "rememberMe" cookie but it is removed when you log out.
Put a breakpoint in CookieUtils#remove(String) and you will see
whether this really happens. Another interesting point in
AuthenticatedWebSession#invalidate().
You can also use Firebug/Dev utils to see what cookies are left after
logout and whether they are send with the next request and used to log
you in.

On Mon, Jun 25, 2012 at 2:38 PM, Tom Eugelink <tb...@tbee.org> wrote:
> Ok. The actual problem I have is that wicket auth keeps logging in
> automatically. This is a side effect of a.o. BASIC authentication (not sure
> if that is used in this case, but the behavior is similar) which sends the
> login credentials with every request, even if you have logged out in the
> mean time. To enforce a new login via the login page, one usually places
> some marker in the session telling the authenticator class that it should
> not accept the current credentials until a valid login page submit was done.
> But since Wicket keeps doing things to the session, I'm not able to get this
> marker to work.
>
> Are there any people using auth and that are able to fully log out?
>
> Tom
>
>
>
> On 2012-06-25 13:29, Martin Grigorov wrote:
>>
>> Hi Tom,
>>
>> I agree with your vision.
>> But since Wicket is a framework around the Servlet API we call
>> HttpSession.invalidate(). This triggers some web container internal
>> workings and at some point Wicket is called back (see
>> javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
>> Wicket clears everything that it added to this session.
>> What happens with this session later is not our business. It may be
>> teared down or recycled, we really don't care. Next time we need to
>> store something in the http session we just call:
>> httpRequest.getSession(true) and use it.
>>
>> I know you use recent version of Wicket (6.x ?) and there are no
>> pagemaps since Wicket 1.5.0 but if you find that anything leaks then
>> it is a bug and it should be fixed.
>>
>> On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink <tb...@tbee.org> wrote:
>>>
>>> Which means that upon logout, these values should be removed / cleared. A
>>> session does not represent a user, it is a construct to bind request, no
>>> more no less. All other usages are bolted on and should be bolted off.
>>> You
>>> don't tear down the house, just because you are moving.
>>>
>>> Tom
>>>
>>>
>>> On 2012-06-23 10:18, Bert wrote:
>>>>
>>>> But Wicket also stores the page map in the session to support back
>>>> button functionality. If you only change the status, than the user
>>>> could possibly (depending on how you construct your page) go back
>>>> after the logout and see the last pages.
>>>>
>>>> This could be a problem on public computers.
>>>>
>>>> You could also see a session as representing a user, not a browser.
>>>> Than, invalidating the session on logout makes perfect sense to me.
>>>>
>>>> regards
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: logout

[Tom Eugelink <tb...@tbee.org>]

Ok. I also have a logout page, call signout in the before-render, and then use the exception thing to immediately forward to another page. Maybe actually showing the logout page is the trick (better a page and autologin all the time).

What do you do on the logout page to force the logout?

Tom


On 2012-06-25 13:58, Stefan Moises wrote:
> Hi Tom,
>
> we are using wicket auth and we can only logout if we use a dedicated Signout page (with template) - if we only logout (and e.g. try to forward right to the homepage with setResponsePage()) it doesn't work and the user always stays logged in as you describe it.
> We'd love to get rid of the additional Signout page though (because it only says "Good bye" and is rather annoying for regular users I think ...) :)
>
> Stefan
>
> Am 25.06.2012 13:38, schrieb Tom Eugelink:
>> Ok. The actual problem I have is that wicket auth keeps logging in automatically. This is a side effect of a.o. BASIC authentication (not sure if that is used in this case, but the behavior is similar) which sends the login credentials with every request, even if you have logged out in the mean time. To enforce a new login via the login page, one usually places some marker in the session telling the authenticator class that it should not accept the current credentials until a valid login page submit was done. But since Wicket keeps doing things to the session, I'm not able to get this marker to work.
>>
>> Are there any people using auth and that are able to fully log out?
>>
>> Tom
>>
>>
>> On 2012-06-25 13:29, Martin Grigorov wrote:
>>> Hi Tom,
>>>
>>> I agree with your vision.
>>> But since Wicket is a framework around the Servlet API we call
>>> HttpSession.invalidate(). This triggers some web container internal
>>> workings and at some point Wicket is called back (see
>>> javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
>>> Wicket clears everything that it added to this session.
>>> What happens with this session later is not our business. It may be
>>> teared down or recycled, we really don't care. Next time we need to
>>> store something in the http session we just call:
>>> httpRequest.getSession(true) and use it.
>>>
>>> I know you use recent version of Wicket (6.x ?) and there are no
>>> pagemaps since Wicket 1.5.0 but if you find that anything leaks then
>>> it is a bug and it should be fixed.
>>>
>>> On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink <tb...@tbee.org> wrote:
>>>> Which means that upon logout, these values should be removed / cleared. A
>>>> session does not represent a user, it is a construct to bind request, no
>>>> more no less. All other usages are bolted on and should be bolted off. You
>>>> don't tear down the house, just because you are moving.
>>>>
>>>> Tom
>>>>
>>>>
>>>> On 2012-06-23 10:18, Bert wrote:
>>>>> But Wicket also stores the page map in the session to support back
>>>>> button functionality. If you only change the status, than the user
>>>>> could possibly (depending on how you construct your page) go back
>>>>> after the logout and see the last pages.
>>>>>
>>>>> This could be a problem on public computers.
>>>>>
>>>>> You could also see a session as representing a user, not a browser.
>>>>> Than, invalidating the session on logout makes perfect sense to me.
>>>>>
>>>>> regards
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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: logout

[Stefan Moises <be...@gmx.de>]

Hi Tom,

we are using wicket auth and we can only logout if we use a dedicated 
Signout page (with template) - if we only logout (and e.g. try to 
forward right to the homepage with setResponsePage()) it doesn't work 
and the user always stays logged in as you describe it.
We'd love to get rid of the additional Signout page though (because it 
only says "Good bye" and is rather annoying for regular users I think 
...) :)

Stefan

Am 25.06.2012 13:38, schrieb Tom Eugelink:
> Ok. The actual problem I have is that wicket auth keeps logging in 
> automatically. This is a side effect of a.o. BASIC authentication (not 
> sure if that is used in this case, but the behavior is similar) which 
> sends the login credentials with every request, even if you have 
> logged out in the mean time. To enforce a new login via the login 
> page, one usually places some marker in the session telling the 
> authenticator class that it should not accept the current credentials 
> until a valid login page submit was done. But since Wicket keeps doing 
> things to the session, I'm not able to get this marker to work.
>
> Are there any people using auth and that are able to fully log out?
>
> Tom
>
>
> On 2012-06-25 13:29, Martin Grigorov wrote:
>> Hi Tom,
>>
>> I agree with your vision.
>> But since Wicket is a framework around the Servlet API we call
>> HttpSession.invalidate(). This triggers some web container internal
>> workings and at some point Wicket is called back (see
>> javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
>> Wicket clears everything that it added to this session.
>> What happens with this session later is not our business. It may be
>> teared down or recycled, we really don't care. Next time we need to
>> store something in the http session we just call:
>> httpRequest.getSession(true) and use it.
>>
>> I know you use recent version of Wicket (6.x ?) and there are no
>> pagemaps since Wicket 1.5.0 but if you find that anything leaks then
>> it is a bug and it should be fixed.
>>
>> On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink <tb...@tbee.org> wrote:
>>> Which means that upon logout, these values should be removed / 
>>> cleared. A
>>> session does not represent a user, it is a construct to bind 
>>> request, no
>>> more no less. All other usages are bolted on and should be bolted 
>>> off. You
>>> don't tear down the house, just because you are moving.
>>>
>>> Tom
>>>
>>>
>>> On 2012-06-23 10:18, Bert wrote:
>>>> But Wicket also stores the page map in the session to support back
>>>> button functionality. If you only change the status, than the user
>>>> could possibly (depending on how you construct your page) go back
>>>> after the logout and see the last pages.
>>>>
>>>> This could be a problem on public computers.
>>>>
>>>> You could also see a session as representing a user, not a browser.
>>>> Than, invalidating the session on logout makes perfect sense to me.
>>>>
>>>> regards
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: logout

[Tom Eugelink <tb...@tbee.org>]

Ok. The actual problem I have is that wicket auth keeps logging in automatically. This is a side effect of a.o. BASIC authentication (not sure if that is used in this case, but the behavior is similar) which sends the login credentials with every request, even if you have logged out in the mean time. To enforce a new login via the login page, one usually places some marker in the session telling the authenticator class that it should not accept the current credentials until a valid login page submit was done. But since Wicket keeps doing things to the session, I'm not able to get this marker to work.

Are there any people using auth and that are able to fully log out?

Tom


On 2012-06-25 13:29, Martin Grigorov wrote:
> Hi Tom,
>
> I agree with your vision.
> But since Wicket is a framework around the Servlet API we call
> HttpSession.invalidate(). This triggers some web container internal
> workings and at some point Wicket is called back (see
> javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
> Wicket clears everything that it added to this session.
> What happens with this session later is not our business. It may be
> teared down or recycled, we really don't care. Next time we need to
> store something in the http session we just call:
> httpRequest.getSession(true) and use it.
>
> I know you use recent version of Wicket (6.x ?) and there are no
> pagemaps since Wicket 1.5.0 but if you find that anything leaks then
> it is a bug and it should be fixed.
>
> On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink <tb...@tbee.org> wrote:
>> Which means that upon logout, these values should be removed / cleared. A
>> session does not represent a user, it is a construct to bind request, no
>> more no less. All other usages are bolted on and should be bolted off. You
>> don't tear down the house, just because you are moving.
>>
>> Tom
>>
>>
>> On 2012-06-23 10:18, Bert wrote:
>>> But Wicket also stores the page map in the session to support back
>>> button functionality. If you only change the status, than the user
>>> could possibly (depending on how you construct your page) go back
>>> after the logout and see the last pages.
>>>
>>> This could be a problem on public computers.
>>>
>>> You could also see a session as representing a user, not a browser.
>>> Than, invalidating the session on logout makes perfect sense to me.
>>>
>>> regards
>>>
>>
>> ---------------------------------------------------------------------
>> 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: logout

[Martin Grigorov <mg...@apache.org>]

Hi Tom,

I agree with your vision.
But since Wicket is a framework around the Servlet API we call
HttpSession.invalidate(). This triggers some web container internal
workings and at some point Wicket is called back (see
javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
Wicket clears everything that it added to this session.
What happens with this session later is not our business. It may be
teared down or recycled, we really don't care. Next time we need to
store something in the http session we just call:
httpRequest.getSession(true) and use it.

I know you use recent version of Wicket (6.x ?) and there are no
pagemaps since Wicket 1.5.0 but if you find that anything leaks then
it is a bug and it should be fixed.

On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink <tb...@tbee.org> wrote:
> Which means that upon logout, these values should be removed / cleared. A
> session does not represent a user, it is a construct to bind request, no
> more no less. All other usages are bolted on and should be bolted off. You
> don't tear down the house, just because you are moving.
>
> Tom
>
>
> On 2012-06-23 10:18, Bert wrote:
>>
>> But Wicket also stores the page map in the session to support back
>> button functionality. If you only change the status, than the user
>> could possibly (depending on how you construct your page) go back
>> after the logout and see the last pages.
>>
>> This could be a problem on public computers.
>>
>> You could also see a session as representing a user, not a browser.
>> Than, invalidating the session on logout makes perfect sense to me.
>>
>> regards
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: logout

[Tom Eugelink <tb...@tbee.org>]

Which means that upon logout, these values should be removed / cleared. A session does not represent a user, it is a construct to bind request, no more no less. All other usages are bolted on and should be bolted off. You don't tear down the house, just because you are moving.

Tom

On 2012-06-23 10:18, Bert wrote:
> But Wicket also stores the page map in the session to support back
> button functionality. If you only change the status, than the user
> could possibly (depending on how you construct your page) go back
> after the logout and see the last pages.
>
> This could be a problem on public computers.
>
> You could also see a session as representing a user, not a browser.
> Than, invalidating the session on logout makes perfect sense to me.
>
> regards
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: logout

[Bert <ta...@gmail.com>]

But Wicket also stores the page map in the session to support back
button functionality. If you only change the status, than the user
could possibly (depending on how you construct your page) go back
after the logout and see the last pages.

This could be a problem on public computers.

You could also see a session as representing a user, not a browser.
Than, invalidating the session on logout makes perfect sense to me.

regards

On Sat, Jun 23, 2012 at 9:14 AM, Tom Eugelink <tb...@tbee.org> wrote:
> On 2012-06-22 16:57, Tom Eugelink wrote:
>>
>> Anyhow, I've added Wicket Auth/Roles
>> (http://wicket.apache.org/learn/projects/authroles.html) as the security
>> framework and it is working fine except one thing; logging out.
>
>
> I've found that the login / logout logic is invalidating the session. During
> an attempt to setup security in a webapp years back, I found that Tomcat
> also does this and I never understood why. The session is a technical
> construct that binds requests from the same browser and allows the website
> to become coherent over multiple request. It has nothing to do with an
> authentication state. Naturally it can be used as a means to administer if a
> user is logged in, but there is no reason to trash the session when a user
> is logging out; after all, it's still the same brower sending requests. The
> session has not changed, the user's status has.
>
> The security filter I've implemented years back as a result of this
> discovery simply changes the logged in state in the current session. If any
> attributes need to be cleared when a user logs out, this is easily done by
> removing them from the current session (may even by using a special map
> store as an attribute in the session). This will prevent the automatic login
> I'm experiencing now. I will roll my security filter in to my wicket app.
>
>
> Tom
>
> ---------------------------------------------------------------------
> 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: logout

[Tom Eugelink <tb...@tbee.org>]

On 2012-06-22 16:57, Tom Eugelink wrote:
> Anyhow, I've added Wicket Auth/Roles (http://wicket.apache.org/learn/projects/authroles.html) as the security framework and it is working fine except one thing; logging out.

I've found that the login / logout logic is invalidating the session. During an attempt to setup security in a webapp years back, I found that Tomcat also does this and I never understood why. The session is a technical construct that binds requests from the same browser and allows the website to become coherent over multiple request. It has nothing to do with an authentication state. Naturally it can be used as a means to administer if a user is logged in, but there is no reason to trash the session when a user is logging out; after all, it's still the same brower sending requests. The session has not changed, the user's status has.

The security filter I've implemented years back as a result of this discovery simply changes the logged in state in the current session. If any attributes need to be cleared when a user logs out, this is easily done by removing them from the current session (may even by using a special map store as an attribute in the session). This will prevent the automatic login I'm experiencing now. I will roll my security filter in to my wicket app.

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org