LoginAction - Understanding Second Part?

[connerjohn]

I'm trying to understand the booking LoginAction

//$Id: LoggedInInterceptor.java,v 1.12 2006/07/26 23:19:55 gavin Exp $
package org.jboss.seam.example.booking;

import java.lang.reflect.Method;

import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;
import javax.faces.event.PhaseId;

import org.jboss.seam.annotations.Interceptor;
import org.jboss.seam.contexts.Contexts;
import org.jboss.seam.contexts.Lifecycle;
import org.jboss.seam.interceptors.BijectionInterceptor;
import org.jboss.seam.interceptors.BusinessProcessInterceptor;
import org.jboss.seam.interceptors.ConversationInterceptor;
import org.jboss.seam.interceptors.RemoveInterceptor;
import org.jboss.seam.interceptors.ValidationInterceptor;

@Interceptor(around={BijectionInterceptor.class, ValidationInterceptor.class,
 ConversationInterceptor.class, BusinessProcessInterceptor.class},
 within=RemoveInterceptor.class)
public class LoggedInInterceptor
{

 @AroundInvoke
 public Object checkLoggedIn(InvocationContext invocation) throws Exception
 {
 boolean isLoggedIn = Contexts.getSessionContext().get("loggedIn")!=null;
 if ( Lifecycle.getPhaseId()==PhaseId.INVOKE_APPLICATION )
 {
 if (isLoggedIn)
 {
 return invocation.proceed();
 }
 else
 {
 return "login";
 }
 }
 else
 {
 if ( isLoggedIn )
 {
 return invocation.proceed();
 }
 else
 {
 Method method = invocation.getMethod();
 if ( method.getReturnType().equals(void.class) )
 {
 return null;
 }
 else
 {
 return method.invoke( invocation.getTarget(), invocation.getParameters() );
 }
 }
 }
 }

}

Wondering two things from this code:
1. what do we get for checking the Lifecycle.PhaseId
2. what is the purpose of calling method.invoke(....) instead of returing a string outcome (aka, "login") like is done if we are in the INVOKE_APPLICATION phase.

Thanks,
--jc

[pmuir]

I don't use this so I'm not 100% but looking at it, it seems to me that if the user is logged in the invocation proceeds as normal, if we are in phase other than INVOKE_APPLICATION (e.g. updata data model) and not logged in then the method called is invoke but the invocation chain is not followed (i.e. subsequent interceptors are not called) - but why this design decision I'm not sure...

[connerjohn]

"petemuir" wrote:
....but why this design decision I'm not sure...

Thanks! I guess I'm asking about the design reasoning? What is the purpose of calling the method but not the rest of the chain?

Thanks again,
--jc

[gavin.king]

No strong reason, just trying to avoid side-effects. Note that @LoggedIn is not meant for production use. Its better to use a real security fwk.

[connerjohn]

No strong reason, just trying to avoid side-effects.

Thanks for the explanation! I was just trying to understand what I was seeing.

Note that @LoggedIn is not meant for production use. Its better to use a real security fwk.

I agree that the form of @LoggedIn isn't something I want to use. Altough, are you saying there is a problem with storing the the user credentials in the Session context?

One of these days I'm going to dig into the different security models (app server or AECGI - I know I probably butchered that acronym) and I saw there is some new security stuff in Seam.

Always more to do :)

--jc

[johnurban]

Note that @LoggedIn is not meant for production use. Its better to use a real security fwk.

Hmm... I am authenticating users via MySQL DB. I am use to using tag libraries to guard/authorize views in JSP's. Thought using the @LoggedIn was a slick way of guarding views. You say use a "real security fwk". Do I keep following my tag library method that I've always used, or is there a better way?