Thank You! This clears up a lot of confusion, and is exactly what was
happening. Shortly after my last message I tried checking for a null
session object and everything worked, though I expected a run time error
due to the missing panel.

        User user = ((VSecureSession)getSession()).getUser();
        if(user != null){
                add(new EventListPanel("eventList", user.getId()));
                //add other session dependent panels
        }

So what is happening is:
1. Page is constructed, skipping session dependent panels
2. checkAccess() is called redirecting to signIn page
3. User signs in and the session is created
4. Original page is re-constructed, this time with a session
5. Original page is rendered

Not the most elegant solution, but for now so long as it works I'm
happy. I'd be interested in any other approaches in the future though.

Thanks,
Troy 


On Thu, 2005-10-06 at 11:20 -0400, Todor Todorov wrote:
> Troy,
> 
> I think  you are confusing constructing a page with rendering a page.
> 
> First a page is being constructed (that's where you are getting the
> exception I believe)
> then checkAccess is being invoked, and later the page is being rendered..
> 
> I'm having similar problems with protected pages - sometimes the
> construction depends on session information but you don't have a valid
> user session until checkAccess returns true.
> 
> So, what you could do is, skip the construction if the user is not
> authenticated ( the page is not going to be rendered anyway).
> Or, create your page in a such a way that session based decisions are
> delayed until render time.
> Or, don't use wicket's authentication features...
> 
> I consider this more a design issue because the workarounds are  not
> satisfying for me.
> I'm currently experimenting with a different auth approaches...
> 
> Better ideas  anyone?
> 
> Todor
> 
> 
> On 10/6/05, Troy MacNeil <[EMAIL PROTECTED]> wrote:
> > Thanks for the reply, I'm using RC2, and my app is originally based on
> > one of the CD apps in contrib-examples (the one with annotations) from
> > the b4 timeframe.
> >
> > In my base page, I redirect to a sign-in page which adds the user object
> > to my session. I then try to use this object in a page which extends the
> > base page.
> >
> > If I link directly to a page (via setHomePage() or bookmark) that
> > accesses the session, my session user object is still null and the page
> > fails to render (due to the null pointer exception in my panel code).
> >
> > If I first link to a page that doesn't use the session variable, and
> > _then_ link to a page that does everything works as expected. So it
> > seemed as though checkAccess() wasn't being called until after the page
> > rendered.
> >
> > I'll take a look with more alert eyes in case there are any lingering
> > issues with the demo code (or at least any I can understand:). I'm also
> > going to try catching the null exception, I expect they won't see data
> > on the first page they visit but at least it won't crash.
> >
> > Here is a more complete version of the relevant code in case it helps...
> >
> >
> > >From base page:
> >     protected boolean checkAccess()
> >     {
> >
> >         //((VSecureSession)getSession()).authenticate("admin",
> > "admin"); //DEBUG
> >         boolean signedIn = ((VSecureSession)getSession()).isSignedIn();
> >
> >         if(!signedIn){
> >                 redirectTo(newPage(SignIn.class));
> >         }
> >         return signedIn;
> >
> >     }
> >
> > >From my session:
> >
> > public final boolean authenticate(final String username, final String
> > password)
> >         {
> >                 if (user == null)
> >                 {
> >                         inUser = ((VSecureRequestCycle)
> > getRequestCycle()).getDao().getUser(username);
> >
> >                                 
> > if((in.getPassword()).equalsIgnoreCase(password)){
> >                                         this.user = in;
> >                                         return true;
> >                 }
> >                 return user != null;
> >         }
> >
> > And the line in the sub page (which causes the null pointer):
> >                 Long userId = 
> > (((VSecureSession)getSession()).getUser()).getId();
> >                 add(new EventListPanel("eventList", userId));
> >
> >
> > Thanks,
> > Troy
> >
> > On Thu, 2005-06-10 at 11:00 +0200, Johan Compagner wrote:
> > > checkAccess() is the first thing that happens before a page is
> > > rendered
> > > see Page.doRender():
> > >
> > > public final void doRender()
> > >     {
> > >         if (checkAccess())
> > >         {
> > >              /// Page get rendered
> > >
> > > So what do you exactly see? What version of wicket do you use?
> > >
> > > On 10/6/05, Troy MacNeil <[EMAIL PROTECTED]> wrote:
> > >         Is there a way to call a method before any page rendering
> > >         takes place?
> > >
> > >         When my user logs in, checkAccess() redirects them to a sign
> > >         in page
> > >         which adds their information to the session for later access.
> > >         This works
> > >         well until I try to go directly (before login) to a
> > >         (Bookmarkable) page
> > >         that uses this session information.
> > >
> > >         After investigating it seems that the entire page is rendered
> > >         before
> > >         calling checkAccess()? Which in my case leads to numerous null
> > >         pointer
> > >         exceptions since the session data is uninitialized.
> > >
> > >         I've tried overriding various methods to call checkAccess()
> > >         earlier in
> > >         the process but without any luck. I'm sure there is a very
> > >         simple
> > >         answer, but it's getting very late and I've been at this for a
> > >         while so
> > >         any help would be _greatly_ appreciated.
> > >
> > >         Thanks,
> > >         Troy
> > >
> > >
> > >         -------------------------------------------------------
> > >         This SF.Net email is sponsored by:
> > >         Power Architecture Resource Center: Free content, downloads,
> > >         discussions,
> > >         and more. http://solutions.newsforge.com/ibmarch.tmpl
> > >         _______________________________________________
> > >         Wicket-user mailing list
> > >         [email protected]
> > >         https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads, discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Wicket-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to