>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
><chr...@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: chr...@stepahead.com.au <//chr...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to