You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Chris Colman <ch...@stepaheadsoftware.com> on 2012/04/16 10:53:10 UTC

ContinueToOriginalDestination does not clear destination after continue

We have a scenario where single person can log in under different
accounts on the same website. Different user types will typically go to
different page types.
 
A single person using different accounts is not normally required but we
are demonstrating to corporate clients how the system will be used by
different user types. In the demonstration we need to log in as an
'admin' user to demo the admin aspects and then we need to log in as a
'standard' user to demonstrate the aspects that will apply to a standard
user.
 
The admin page uses RedirectToInterceptException to authentication page
if no one is logged in.
 
The standard page uses the home page to authenticate and throws new
RestartResponseException(new AuthenticatePage(parameters)) if no one is
authenticated (i.e. no intercept)
 
After authentication we either continue or go to the 'default' page for
a standard user.
 
Code looks like this:
 
                        If ( authenicationSucceeded )
                        {
                                    if (
!continueToOriginalDestination() )
                                    {
                                                // Was not redirected to
this authentication page so go to default destination for the home page
                                                // Find default page for
standard users and go to that page
                                    }
                        }
 
What we find is that after an admin log on (with intercept/continue
sequence) a subsequent standard user log on will not execute the above
body because continueToOriginalDestination returns 'true' even though
this page was not an intercept page. 
 
It looks like after an intercept/continue has occurred it does not clear
the 'original destination' attribute and so a subsequent call to
continueToOriginalDestination will return true when it should really
return false.
 
Is the attribute that stores 'original destination' cleared after
continueToOriginalDestination? Should it be?
 
 
Yours sincerely,
 
Chris Colman
 
Pagebloom Team Leader,
Step Ahead Software

 
pagebloom - your business & your website growing together
 
Sydney: (+61 2) 9656 1278     Canberra: (+61 2) 6100 2120     
Email: chrisc@stepahead.com.au <ma...@stepahead.com.au> 
Website:
http://www.pagebloom.com <blocked::http://www.pagebloom.com/> 
http://develop.stepaheadsoftware.com
<blocked::http://develop.stepaheadsoftware.com/> 
 
 

RE: ContinueToOriginalDestination does not clear destination after continue

Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>Then this is a bug.

https://issues.apache.org/jira/browse/WICKET-4500

Complete with quickstart.

Regards,
Chris

>
>On Mon, Apr 16, 2012 at 1:18 PM, Chris Colman
><ch...@stepaheadsoftware.com> wrote:
>> BTW that clear never gets called in the simple process of the Admin user
>> going to admin page redirected and then 'continued' after
>> authentication. I have not attempted to do anything with the standard
>> user at this point so the clear not getting called seems to be a problem
>> in a single user scenario.
>>
>>>-----Original Message-----
>>>From: Martin Grigorov [mailto:mgrigorov@apache.org]
>>>Sent: Monday, 16 April 2012 7:02 PM
>>>To: users@wicket.apache.org
>>>Subject: Re: ContinueToOriginalDestination does not clear destination
>> after
>>>continue
>>>
>>>Hi Chris,
>>>
>>>Check the code
>>>at
>>>org.apache.wicket.RestartResponseAtInterceptPageException#continueToOri
>> gina
>>>lDestination()
>>>This method indeed returns 'true' without cleaning the stored data but
>>>later when the redirect is processed the data is cleaned - see
>>>MAPPER#mapRequest(Request) method few lines below.
>>>
>>>Additionally this data is stored as meta data in the Session object, so
>>>changing users implies invalidation of the old (Admin) session and
>> creation
>>>of a new (normal user) session. Do you degrade the Admin user to a user
>>>with less permissions without a real logout ?
>>>
>>>On Mon, Apr 16, 2012 at 11:53 AM, Chris Colman
>>><chrisc@stepaheadsoftware.com
>>>> wrote:
>>>
>>>> ** **
>>>>
>>>> We have a scenario where single person can log in under different
>>>accounts
>>>> on the same website. Different user types will typically go to
>> different
>>>> page types.****
>>>>
>>>> ** **
>>>>
>>>> A single person using different accounts is not normally required but
>> we
>>>> are demonstrating to corporate clients how the system will be used by
>>>> different user types. In the demonstration we need to log in as an
>>>'admin'
>>>> user to demo the admin aspects and then we need to log in as a
>> 'standard'
>>>> user to demonstrate the aspects that will apply to a standard
>> user.****
>>>>
>>>> ** **
>>>>
>>>> The admin page uses RedirectToInterceptException to authentication
>> page
>>>> if no one is logged in.****
>>>>
>>>> ** **
>>>>
>>>> The standard page uses the home page to authenticate and throws new
>>>> RestartResponseException(new AuthenticatePage(parameters)) if no one
>> is
>>>> authenticated (i.e. no intercept)****
>>>>
>>>> ** **
>>>>
>>>> After authentication we either continue or go to the 'default' page
>> for a
>>>> standard user.****
>>>>
>>>> ** **
>>>>
>>>> Code looks like this:****
>>>>
>>>> ** **
>>>>
>>>>                         If ( authenicationSucceeded )****
>>>>
>>>>                         {****
>>>>
>>>>                                     if (
>> !continueToOriginalDestination()
>>>> )****
>>>>
>>>>                                     {****
>>>>
>>>>                                                 // Was not redirected
>> to
>>>> this authentication page so go to default destination for the home
>>>page***
>>>> *
>>>>
>>>>                                                 // Find default page
>> for
>>>> standard users and go to that page****
>>>>
>>>>                                     }****
>>>>
>>>>                         }****
>>>>
>>>> ** **
>>>>
>>>> What we find is that after an admin log on (with intercept/continue
>>>> sequence) a subsequent standard user log on will not execute the
>> above
>>>body
>>>> because continueToOriginalDestination returns 'true' even though this
>>>> page was not an intercept page. ****
>>>>
>>>> ** **
>>>>
>>>> It looks like after an intercept/continue has occurred it does not
>> clear
>>>> the 'original destination' attribute and so a subsequent call to
>>>> continueToOriginalDestination will return true when it should really
>>>> return false.****
>>>>
>>>> ** **
>>>>
>>>> Is the attribute that stores 'original destination' cleared after
>>>> continueToOriginalDestination? Should it be?****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> Yours sincerely,****
>>>>
>>>> ** **
>>>>
>>>> Chris Colman****
>>>>
>>>>  ****
>>>>
>>>> Pagebloom Team Leader,****
>>>>
>>>> Step Ahead Software
>>>>
>>>> ****
>>>>
>>>> pagebloom - your business & your website growing together****
>>>>
>>>> ** **
>>>>
>>>> **Sydney**: (+61 2) 9656 1278     ****Canberra****: (+61 2) 6100 2120
>>>> ****
>>>>
>>>> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>>>>
>>>> Website:****
>>>>
>>>> http://www.pagebloom.com****
>>>>
>>>> http://develop.stepaheadsoftware.com****
>>>>
>>>>  ****
>>>>
>>>> ** **
>>>>
>>>
>>>
>>>
>>>--
>>>Martin Grigorov
>>>jWeekend
>>>Training, Consulting, Development
>>>http://jWeekend.com <http://jweekend.com/>
>>
>> ---------------------------------------------------------------------
>> 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


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


Re: ContinueToOriginalDestination does not clear destination after continue

Posted by Martin Grigorov <mg...@apache.org>.
Then this is a bug.

On Mon, Apr 16, 2012 at 1:18 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
> BTW that clear never gets called in the simple process of the Admin user
> going to admin page redirected and then 'continued' after
> authentication. I have not attempted to do anything with the standard
> user at this point so the clear not getting called seems to be a problem
> in a single user scenario.
>
>>-----Original Message-----
>>From: Martin Grigorov [mailto:mgrigorov@apache.org]
>>Sent: Monday, 16 April 2012 7:02 PM
>>To: users@wicket.apache.org
>>Subject: Re: ContinueToOriginalDestination does not clear destination
> after
>>continue
>>
>>Hi Chris,
>>
>>Check the code
>>at
>>org.apache.wicket.RestartResponseAtInterceptPageException#continueToOri
> gina
>>lDestination()
>>This method indeed returns 'true' without cleaning the stored data but
>>later when the redirect is processed the data is cleaned - see
>>MAPPER#mapRequest(Request) method few lines below.
>>
>>Additionally this data is stored as meta data in the Session object, so
>>changing users implies invalidation of the old (Admin) session and
> creation
>>of a new (normal user) session. Do you degrade the Admin user to a user
>>with less permissions without a real logout ?
>>
>>On Mon, Apr 16, 2012 at 11:53 AM, Chris Colman
>><chrisc@stepaheadsoftware.com
>>> wrote:
>>
>>> ** **
>>>
>>> We have a scenario where single person can log in under different
>>accounts
>>> on the same website. Different user types will typically go to
> different
>>> page types.****
>>>
>>> ** **
>>>
>>> A single person using different accounts is not normally required but
> we
>>> are demonstrating to corporate clients how the system will be used by
>>> different user types. In the demonstration we need to log in as an
>>'admin'
>>> user to demo the admin aspects and then we need to log in as a
> 'standard'
>>> user to demonstrate the aspects that will apply to a standard
> user.****
>>>
>>> ** **
>>>
>>> The admin page uses RedirectToInterceptException to authentication
> page
>>> if no one is logged in.****
>>>
>>> ** **
>>>
>>> The standard page uses the home page to authenticate and throws new
>>> RestartResponseException(new AuthenticatePage(parameters)) if no one
> is
>>> authenticated (i.e. no intercept)****
>>>
>>> ** **
>>>
>>> After authentication we either continue or go to the 'default' page
> for a
>>> standard user.****
>>>
>>> ** **
>>>
>>> Code looks like this:****
>>>
>>> ** **
>>>
>>>                         If ( authenicationSucceeded )****
>>>
>>>                         {****
>>>
>>>                                     if (
> !continueToOriginalDestination()
>>> )****
>>>
>>>                                     {****
>>>
>>>                                                 // Was not redirected
> to
>>> this authentication page so go to default destination for the home
>>page***
>>> *
>>>
>>>                                                 // Find default page
> for
>>> standard users and go to that page****
>>>
>>>                                     }****
>>>
>>>                         }****
>>>
>>> ** **
>>>
>>> What we find is that after an admin log on (with intercept/continue
>>> sequence) a subsequent standard user log on will not execute the
> above
>>body
>>> because continueToOriginalDestination returns 'true' even though this
>>> page was not an intercept page. ****
>>>
>>> ** **
>>>
>>> It looks like after an intercept/continue has occurred it does not
> clear
>>> the 'original destination' attribute and so a subsequent call to
>>> continueToOriginalDestination will return true when it should really
>>> return false.****
>>>
>>> ** **
>>>
>>> Is the attribute that stores 'original destination' cleared after
>>> continueToOriginalDestination? Should it be?****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Yours sincerely,****
>>>
>>> ** **
>>>
>>> Chris Colman****
>>>
>>>  ****
>>>
>>> Pagebloom Team Leader,****
>>>
>>> Step Ahead Software
>>>
>>> ****
>>>
>>> pagebloom - your business & your website growing together****
>>>
>>> ** **
>>>
>>> **Sydney**: (+61 2) 9656 1278     ****Canberra****: (+61 2) 6100 2120
>>> ****
>>>
>>> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>>>
>>> Website:****
>>>
>>> http://www.pagebloom.com****
>>>
>>> http://develop.stepaheadsoftware.com****
>>>
>>>  ****
>>>
>>> ** **
>>>
>>
>>
>>
>>--
>>Martin Grigorov
>>jWeekend
>>Training, Consulting, Development
>>http://jWeekend.com <http://jweekend.com/>
>
> ---------------------------------------------------------------------
> 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: ContinueToOriginalDestination does not clear destination after continue

Posted by Chris Colman <ch...@stepaheadsoftware.com>.
BTW that clear never gets called in the simple process of the Admin user
going to admin page redirected and then 'continued' after
authentication. I have not attempted to do anything with the standard
user at this point so the clear not getting called seems to be a problem
in a single user scenario.

>-----Original Message-----
>From: Martin Grigorov [mailto:mgrigorov@apache.org]
>Sent: Monday, 16 April 2012 7:02 PM
>To: users@wicket.apache.org
>Subject: Re: ContinueToOriginalDestination does not clear destination
after
>continue
>
>Hi Chris,
>
>Check the code
>at
>org.apache.wicket.RestartResponseAtInterceptPageException#continueToOri
gina
>lDestination()
>This method indeed returns 'true' without cleaning the stored data but
>later when the redirect is processed the data is cleaned - see
>MAPPER#mapRequest(Request) method few lines below.
>
>Additionally this data is stored as meta data in the Session object, so
>changing users implies invalidation of the old (Admin) session and
creation
>of a new (normal user) session. Do you degrade the Admin user to a user
>with less permissions without a real logout ?
>
>On Mon, Apr 16, 2012 at 11:53 AM, Chris Colman
><chrisc@stepaheadsoftware.com
>> wrote:
>
>> ** **
>>
>> We have a scenario where single person can log in under different
>accounts
>> on the same website. Different user types will typically go to
different
>> page types.****
>>
>> ** **
>>
>> A single person using different accounts is not normally required but
we
>> are demonstrating to corporate clients how the system will be used by
>> different user types. In the demonstration we need to log in as an
>'admin'
>> user to demo the admin aspects and then we need to log in as a
'standard'
>> user to demonstrate the aspects that will apply to a standard
user.****
>>
>> ** **
>>
>> The admin page uses RedirectToInterceptException to authentication
page
>> if no one is logged in.****
>>
>> ** **
>>
>> The standard page uses the home page to authenticate and throws new
>> RestartResponseException(new AuthenticatePage(parameters)) if no one
is
>> authenticated (i.e. no intercept)****
>>
>> ** **
>>
>> After authentication we either continue or go to the 'default' page
for a
>> standard user.****
>>
>> ** **
>>
>> Code looks like this:****
>>
>> ** **
>>
>>                         If ( authenicationSucceeded )****
>>
>>                         {****
>>
>>                                     if (
!continueToOriginalDestination()
>> )****
>>
>>                                     {****
>>
>>                                                 // Was not redirected
to
>> this authentication page so go to default destination for the home
>page***
>> *
>>
>>                                                 // Find default page
for
>> standard users and go to that page****
>>
>>                                     }****
>>
>>                         }****
>>
>> ** **
>>
>> What we find is that after an admin log on (with intercept/continue
>> sequence) a subsequent standard user log on will not execute the
above
>body
>> because continueToOriginalDestination returns 'true' even though this
>> page was not an intercept page. ****
>>
>> ** **
>>
>> It looks like after an intercept/continue has occurred it does not
clear
>> the 'original destination' attribute and so a subsequent call to
>> continueToOriginalDestination will return true when it should really
>> return false.****
>>
>> ** **
>>
>> Is the attribute that stores 'original destination' cleared after
>> continueToOriginalDestination? Should it be?****
>>
>> ** **
>>
>> ** **
>>
>> Yours sincerely,****
>>
>> ** **
>>
>> Chris Colman****
>>
>>  ****
>>
>> Pagebloom Team Leader,****
>>
>> Step Ahead Software
>>
>> ****
>>
>> pagebloom - your business & your website growing together****
>>
>> ** **
>>
>> **Sydney**: (+61 2) 9656 1278     ****Canberra****: (+61 2) 6100 2120
>> ****
>>
>> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>>
>> Website:****
>>
>> http://www.pagebloom.com****
>>
>> http://develop.stepaheadsoftware.com****
>>
>>  ****
>>
>> ** **
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com <http://jweekend.com/>

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


RE: ContinueToOriginalDestination does not clear destination after continue

Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>Additionally this data is stored as meta data in the Session object, so
>changing users implies invalidation of the old (Admin) session and
creation
>of a new (normal user) session. Do you degrade the Admin user to a user
>with less permissions without a real logout ?

By a 'real logout' do you mean invalidating the session? Can we do that
if we change users? Don't we still need a valid session for the new
user?
 
>
>On Mon, Apr 16, 2012 at 11:53 AM, Chris Colman
><chrisc@stepaheadsoftware.com
>> wrote:
>
>> ** **
>>
>> We have a scenario where single person can log in under different
>accounts
>> on the same website. Different user types will typically go to
different
>> page types.****
>>
>> ** **
>>
>> A single person using different accounts is not normally required but
we
>> are demonstrating to corporate clients how the system will be used by
>> different user types. In the demonstration we need to log in as an
>'admin'
>> user to demo the admin aspects and then we need to log in as a
'standard'
>> user to demonstrate the aspects that will apply to a standard
user.****
>>
>> ** **
>>
>> The admin page uses RedirectToInterceptException to authentication
page
>> if no one is logged in.****
>>
>> ** **
>>
>> The standard page uses the home page to authenticate and throws new
>> RestartResponseException(new AuthenticatePage(parameters)) if no one
is
>> authenticated (i.e. no intercept)****
>>
>> ** **
>>
>> After authentication we either continue or go to the 'default' page
for a
>> standard user.****
>>
>> ** **
>>
>> Code looks like this:****
>>
>> ** **
>>
>>                         If ( authenicationSucceeded )****
>>
>>                         {****
>>
>>                                     if (
!continueToOriginalDestination()
>> )****
>>
>>                                     {****
>>
>>                                                 // Was not redirected
to
>> this authentication page so go to default destination for the home
>page***
>> *
>>
>>                                                 // Find default page
for
>> standard users and go to that page****
>>
>>                                     }****
>>
>>                         }****
>>
>> ** **
>>
>> What we find is that after an admin log on (with intercept/continue
>> sequence) a subsequent standard user log on will not execute the
above
>body
>> because continueToOriginalDestination returns 'true' even though this
>> page was not an intercept page. ****
>>
>> ** **
>>
>> It looks like after an intercept/continue has occurred it does not
clear
>> the 'original destination' attribute and so a subsequent call to
>> continueToOriginalDestination will return true when it should really
>> return false.****
>>
>> ** **
>>
>> Is the attribute that stores 'original destination' cleared after
>> continueToOriginalDestination? Should it be?****
>>
>> ** **
>>
>> ** **
>>
>> Yours sincerely,****
>>
>> ** **
>>
>> Chris Colman****
>>
>>  ****
>>
>> Pagebloom Team Leader,****
>>
>> Step Ahead Software
>>
>> ****
>>
>> pagebloom - your business & your website growing together****
>>
>> ** **
>>
>> **Sydney**: (+61 2) 9656 1278     ****Canberra****: (+61 2) 6100 2120
>> ****
>>
>> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>>
>> Website:****
>>
>> http://www.pagebloom.com****
>>
>> http://develop.stepaheadsoftware.com****
>>
>>  ****
>>
>> ** **
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com <http://jweekend.com/>

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


RE: ContinueToOriginalDestination does not clear destination after continue

Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>Hi Chris,
>
>Check the code
>at
>org.apache.wicket.RestartResponseAtInterceptPageException#continueToOri
gina
>lDestination()
>This method indeed returns 'true' without cleaning the stored data but
>later when the redirect is processed the data is cleaned - see
>MAPPER#mapRequest(Request) method few lines below.

I just ran the code in the debugger and after successful authentication
I never see MAPPER#mapRequest getting called. I set a breakpoint on both

continueToOriginalDestination

and 

Mapper#mapRequest

Execution hits continueToOriginalDestination but I never see it hit
Mapper#mapRequest - which means InterceptData.clear() never gets called
- that would explain what I'm seeing.


>
>Additionally this data is stored as meta data in the Session object, so
>changing users implies invalidation of the old (Admin) session and
creation
>of a new (normal user) session. Do you degrade the Admin user to a user
>with less permissions without a real logout ?
>
>On Mon, Apr 16, 2012 at 11:53 AM, Chris Colman
><chrisc@stepaheadsoftware.com
>> wrote:
>
>> ** **
>>
>> We have a scenario where single person can log in under different
>accounts
>> on the same website. Different user types will typically go to
different
>> page types.****
>>
>> ** **
>>
>> A single person using different accounts is not normally required but
we
>> are demonstrating to corporate clients how the system will be used by
>> different user types. In the demonstration we need to log in as an
>'admin'
>> user to demo the admin aspects and then we need to log in as a
'standard'
>> user to demonstrate the aspects that will apply to a standard
user.****
>>
>> ** **
>>
>> The admin page uses RedirectToInterceptException to authentication
page
>> if no one is logged in.****
>>
>> ** **
>>
>> The standard page uses the home page to authenticate and throws new
>> RestartResponseException(new AuthenticatePage(parameters)) if no one
is
>> authenticated (i.e. no intercept)****
>>
>> ** **
>>
>> After authentication we either continue or go to the 'default' page
for a
>> standard user.****
>>
>> ** **
>>
>> Code looks like this:****
>>
>> ** **
>>
>>                         If ( authenicationSucceeded )****
>>
>>                         {****
>>
>>                                     if (
!continueToOriginalDestination()
>> )****
>>
>>                                     {****
>>
>>                                                 // Was not redirected
to
>> this authentication page so go to default destination for the home
>page***
>> *
>>
>>                                                 // Find default page
for
>> standard users and go to that page****
>>
>>                                     }****
>>
>>                         }****
>>
>> ** **
>>
>> What we find is that after an admin log on (with intercept/continue
>> sequence) a subsequent standard user log on will not execute the
above
>body
>> because continueToOriginalDestination returns 'true' even though this
>> page was not an intercept page. ****
>>
>> ** **
>>
>> It looks like after an intercept/continue has occurred it does not
clear
>> the 'original destination' attribute and so a subsequent call to
>> continueToOriginalDestination will return true when it should really
>> return false.****
>>
>> ** **
>>
>> Is the attribute that stores 'original destination' cleared after
>> continueToOriginalDestination? Should it be?****
>>
>> ** **
>>
>> ** **
>>
>> Yours sincerely,****
>>
>> ** **
>>
>> Chris Colman****
>>
>>  ****
>>
>> Pagebloom Team Leader,****
>>
>> Step Ahead Software
>>
>> ****
>>
>> pagebloom - your business & your website growing together****
>>
>> ** **
>>
>> **Sydney**: (+61 2) 9656 1278     ****Canberra****: (+61 2) 6100 2120
>> ****
>>
>> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>>
>> Website:****
>>
>> http://www.pagebloom.com****
>>
>> http://develop.stepaheadsoftware.com****
>>
>>  ****
>>
>> ** **
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com <http://jweekend.com/>

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


Re: ContinueToOriginalDestination does not clear destination after continue

Posted by Martin Grigorov <mg...@apache.org>.
Hi Chris,

Check the code
at org.apache.wicket.RestartResponseAtInterceptPageException#continueToOriginalDestination()
This method indeed returns 'true' without cleaning the stored data but
later when the redirect is processed the data is cleaned - see
MAPPER#mapRequest(Request) method few lines below.

Additionally this data is stored as meta data in the Session object, so
changing users implies invalidation of the old (Admin) session and creation
of a new (normal user) session. Do you degrade the Admin user to a user
with less permissions without a real logout ?

On Mon, Apr 16, 2012 at 11:53 AM, Chris Colman <chrisc@stepaheadsoftware.com
> wrote:

> ** **
>
> We have a scenario where single person can log in under different accounts
> on the same website. Different user types will typically go to different
> page types.****
>
> ** **
>
> A single person using different accounts is not normally required but we
> are demonstrating to corporate clients how the system will be used by
> different user types. In the demonstration we need to log in as an ‘admin’
> user to demo the admin aspects and then we need to log in as a ‘standard’
> user to demonstrate the aspects that will apply to a standard user.****
>
> ** **
>
> The admin page uses RedirectToInterceptException to authentication page
> if no one is logged in.****
>
> ** **
>
> The standard page uses the home page to authenticate and throws new
> RestartResponseException(new AuthenticatePage(parameters)) if no one is
> authenticated (i.e. no intercept)****
>
> ** **
>
> After authentication we either continue or go to the ‘default’ page for a
> standard user.****
>
> ** **
>
> Code looks like this:****
>
> ** **
>
>                         If ( authenicationSucceeded )****
>
>                         {****
>
>                                     if ( !continueToOriginalDestination()
> )****
>
>                                     {****
>
>                                                 // Was not redirected to
> this authentication page so go to default destination for the home page***
> *
>
>                                                 // Find default page for
> standard users and go to that page****
>
>                                     }****
>
>                         }****
>
> ** **
>
> What we find is that after an admin log on (with intercept/continue
> sequence) a subsequent standard user log on will not execute the above body
> because continueToOriginalDestination returns ‘true’ even though this
> page was not an intercept page. ****
>
> ** **
>
> It looks like after an intercept/continue has occurred it does not clear
> the ‘original destination’ attribute and so a subsequent call to
> continueToOriginalDestination will return true when it should really
> return false.****
>
> ** **
>
> Is the attribute that stores ‘original destination’ cleared after
> continueToOriginalDestination? Should it be?****
>
> ** **
>
> ** **
>
> Yours sincerely,****
>
> ** **
>
> Chris Colman****
>
>  ****
>
> Pagebloom Team Leader,****
>
> Step Ahead Software
>
> ****
>
> pagebloom - your business & your website growing together****
>
> ** **
>
> **Sydney**: (+61 2) 9656 1278     ****Canberra****: (+61 2) 6100 2120
> ****
>
> Email: chrisc@stepahead.com.au <//...@stepahead.com.au>****
>
> Website:****
>
> http://www.pagebloom.com****
>
> http://develop.stepaheadsoftware.com****
>
>  ****
>
> ** **
>



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