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
