voyent
sessionId problem in Acegi, Facelets, Glassfish stack  XML
Forum Index -> General Help
Author Message
rainwebs


Joined: 24/Jul/2007 00:00:00
Messages: 237
Offline


I tried to get Acegi running with the backing bean implementation (1, 2) in ICEfaces 1.6.1 that worked in other JSF implementations without a problem.

When the authenticate() of the AuthenticationController tries to create a WebAuthenticationDetails object the constructor tries to get a session from the request parameter. This delivers null, even if the request.getSession(true) is used (the default Acegi implementation uses getSession(false)). Because of this, the sessionId gets null, too. As Acegi needs the sessionId in different contexts it throws exceptions and the login stops.

I tried to create a MyWebAuthenticationDetails and defined a constructor that can process a given session object, so that a request.getSession() is not necessary:

public MyWebAuthenticationDetails(HttpServletRequest request, HttpSession session) {

this.remoteAddress = request.getRemoteAddr();
this.sessionId = (session != null) ? session.getId() : null;

doPopulateAdditionalInformation(request);
}

Using this in the AuthenticationController:

public String authenticate() {
//...
MyWebAuthenticationDetails details = new MyWebAuthenticationDetails(this.getRequest(),this.getSession());
authReq.setDetails(details);
//...
}

public HttpSession getSession() {

if (session == null) {
FacesContext context = FacesContext.getCurrentInstance();
HttpSession session=(HttpSession)context.getExternalContext().getSession(true);
}
return session;
}

public HttpServletRequest getRequest() {

if (request == null) {
FacesContext context = FacesContext.getCurrentInstance();
request = (HttpServletRequest) context.getExternalContext().getRequest();
}
return request;
}


It seems that it is not possible to get the current session from the request object when Acegi starts its work. Is this a bug, or a configuration problem with ICEfaces? I couldn't find a corresponding Jira bug, although it seems to be a known problem.

ICEfaces book . ICEcube . ICEfusion . ICEfaces Technical Blog Award
michael.thiem


Joined: 04/Jun/2007 00:00:00
Messages: 704
Offline


Hi,

as Philip mentioned in forum-5749 this may be related to some cached jars.

I assume you already tried to clean your project and redeploy it again?

However, I attached an example application which uses Acegi and ICEfaces
1.6.1. I tested this application on Tomcat 5.5.23, but couldn't reproduce this
behaviour.

I hope that helps. Please let me know if this works for you.

Thanks,
Michael
 Filename Test_AcegiExample.zip [Disk] Download
 Description
 Filesize 91 Kbytes
 Downloaded:  269 time(s)

 Filename Test_AcegiExample.war [Disk] Download
 Description
 Filesize 8982 Kbytes
 Downloaded:  171 time(s)

rainwebs


Joined: 24/Jul/2007 00:00:00
Messages: 237
Offline


Your examples does the "standard login" Acegi suggests. I use the backing bean implementation, that places the security context into the session "manually".

What is really annoying to me, is the fact that at that time I can get a session object from the FacesContext, but a request.getSession() doesn't deliver one. Spring/Acegi read from the request. So, for me it looks like ICEfaces doesn't manage the contexts the right way.

BTW: I used the same implementation with Trinidad and Struts and had no problems to get it work.

ICEfaces book . ICEcube . ICEfusion . ICEfaces Technical Blog Award
michael.thiem


Joined: 04/Jun/2007 00:00:00
Messages: 704
Offline


Can you post your example?

Thanks,
Michael
rainwebs


Joined: 24/Jul/2007 00:00:00
Messages: 237
Offline


I can't give you a running example, sorry. So, may I describe what I'm doing:

I have moved all backing beans to a Spring context. I started with a session scope for all beans, e.g.

<bean id="userSkin"
class=”com.mycompany.UserSkin” scope=”session”>
<aop:scoped-proxy/>
</bean>


The first step was to skip all Acegi-specific beans from the session scope:

http://blog.rainer.eschen.name/2007/09/28/acegi-on-ice/

First, I thought that Acegi had problems with the ICEfaces envionment. But, it seems that Spring in general has a problem how ICEfaces manages sessions.

I'm using session-scoped beans (e.g. userSkin) to set skins in Facelets templates:

ice:outputStyle href="/skins/#{userSkin.id}/icefaces.css"


So, every time a page is called the bean is accessed.

Today, I found out that this works after a login, so that I can see our index page with the menu from the protected area, but when I choose a menu item to get to another page I get a session-scope exception. For this I use:

public static void showPage(String page) {

FacesContext context = FacesContext.getCurrentInstance();
context.getApplication().getNavigationHandler().handleNavigation(context, null, page);
}


The method is called from the actionlistener I've defined to manage the dynamic menu entries:

public void clicked(ActionEvent event) {
this.nextPage = (String) ((UIComponent) event.getSource()).getId();
Faces.showPage(this.nextPage);
}

We also have language selectors presented as images near the menu. Clicking on one of them initiates an action that also creates a session-scope exception.

I don't understand all aspects of the JSF/Servlet engine in detail, but for me it looks like:

Every request that is created during runtime is missing the current session reference

As Spring/Acegi tries to get the session via request.getSession() and not via FacesContext it creates the session-scope exceptions, because it gets a null instead of the object.

ICEfaces book . ICEcube . ICEfusion . ICEfaces Technical Blog Award
rainwebs


Joined: 24/Jul/2007 00:00:00
Messages: 237
Offline


Still not tested, but maybe a workaround to solve the problem:

http://weblogs.java.net/blog/felipeal/archive/2008/03/spring_icefaces.html

ICEfaces book . ICEcube . ICEfusion . ICEfaces Technical Blog Award
newalopez

Joined: 15/Oct/2006 00:00:00
Messages: 37
Offline


I recently found that the session ...

request.getSession() on a servlet isn't the same that FacesContext....getSession()

But my worst scenario was that , in a routed network, two different users, accessing my server with same ip (because of the network configuration), well, request.getSession() works great, but the other one, was giving my the session id, from the other users that has the same IP.

so this is dangerous for internet access when a lot of people could have the same IP because the have the same outdoor in the office or something like that...
[Email]
 
Forum Index -> General Help
Go to:   
Powered by JForum 2.1.7ice © JForum Team