Passing the session to JSF

[Maki Tolentino]

Hi,

I am linking to a JSF application from a page done in Spring MVC.

I've set a POJO in the session inside Spring-MVC,

request.getSession().setAttribute("userDetails", userDetails);

and I am planning to retrieve the userDetails bean inside JSF.

        FacesContext context = event.getFacesContext();
        ExternalContext ext = context.getExternalContext();
        HttpSession session = (HttpSession) ext.getSession(false);
        
        UserDetails userDetails= null;
       	userDetails= (UserDetails)session.getAttribute("userDetails");

I've tried putting the above code inside a managed bean, phaselistener and even a filter, but i always get null.
It seems that the session in JSF's FacesContext doesn't have the bean that I've set inside Spring MVC.

Doesn't the JSF page inherit the session from my first page?

Thanks in advance.
Maki

[Tim Holloway]

There is no such this as a "JSF session". The session for a JSF is the same old HttpSession that you know and love from plain old J2EE and it follows the same old rules. The FacesContext, incidentally is not a session object, and it's completely built and destroyed for each JSF request/response cycle. And doesn't exist at all during non-JSF requests.

There are 2 things that indicate trouble in your approach.

1. You're explicitly using JSF code. Excepting data models, anytime you invoke anything from the javax.faces packages, it's a good idea to reflect on whether you should really be doing that. JSF is designed in such a way that in many cases the answer is "no".

2. You're locating services. JSF - and Spring - are based on the concept of injection. In other words, you don't go out and get things, they get delivered yo you.

In the particular case of Spring, there's a bridge that can make all Spring beans injectable into JSF managed beans. Probably someday the two will merge, since 2 separate bean managers is a little silly, but in the mean time, this will suffice. I use this mechanism to inject my Spring DAO objects into my backing beans. You set it up in faces-config like this:

    <application>
        <variable-resolver>
            org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
        <locale-config>
            <default-locale>en</default-locale>
        </locale-config>
        <message-bundle>appResource</message-bundle>
    </application>

The item of interest is the DelegatingVariableResolved. With this component wired into the JSF framework, any Spring bean can be used just like any JSF managed bean and injected into JSF session objects.

[Maki Tolentino]

Hi Tim!

Thanks for your very informative reply.

The problem with this system is that it is composed of 2 separate applications.
I have the Spring MVC application, that does the user authentication, then stores the user's credential in the http session.
And I have the second (JSF) application which fetches the user credentials from the session.
These two are only linked by a link (no pun intended ).

Try to picture that the two web apps are contained in different web containers.

Is it possible that the http session from Spring MVC, be also read from the JSF application?

My current workaround is to pass the variables through the URL.
but since the details are user credentials, i don't think it is a viable solution.


Thanks in advance!

[Tim Holloway]

It really doesn't matter whether the two services are in 2 different containers. It's sufficient that they are 2 separate webapps. Therefore they don't share a common session and you cannot expect information put in one session to be visible in another session.

I will freely confess that I have an antipathy to Do-It-Yourself webapp security systems. I've been accumulating a list of reasons why they should be the last way you attempt to secure webapps, instead of (as is more commonly) the first. It's up to about a dozen items right now, and it begins with the the fact that I've yet to encounter one that I'd trust to successfully hide information on which desk drawer I keep my junk food collection in. Amateur security experts are downright dangerous.

My solution to a problem of this nature would be to place the authentication and authorization code into a security realm module and let the standard J2EE security system manage it - or as much of it as possible. In the real world, it's often necessary to extend it, but that's still better than rolling something from scratch. Since J2EE security is injected into the secured webapps, you don't have to play games with session objects. And, yes, it's perfectly possible to create, say, a custom Tomcat security realm that authenticates against a web application or web service - I've done it.

[Maki Tolentino]

Thanks Tim.
Seems that i'd have to have another workaround to fit my application to the current setup.

I share your sentiments with Do-It-Yourself webapp security systems, but I really do not have any option right now because the authentication facility is already existing, and I am now only modifying it to fit my JSF application.
I will heed your advice on authentication on my next projects.

[Tim Holloway]

Maki Tolentino wrote:Thanks Tim.
Seems that i'd have to have another workaround to fit my application to the current setup.

I'd say that comes under item #8 on my whinge list for DIY security (development costs).

I share your sentiments with Do-It-Yourself webapp security systems, but I really do not have any option right now because the authentication facility is already existing, and I am now only modifying it to fit my JSF application.
I will heed your advice on authentication on my next projects.

If you can, you'll be fortunate. More often it seems that whatever local genius invented the "ultimate clever webapp security system" also has the clout to get it rammed into the shop standards, so there's rarely a choice. But if you'd like to quote me as an authority, feel free, for whatever it's worth.

[Maki Tolentino]

Tim, just one question.

How does yahoo and large portals create their websites?

Is their site 1 big web application or is it composed of smaller webapps? (yahoo mail, groups, etc.. )

I noticed that when you logged in their main site, the modules remember your session (user credentials and such).

thanks in advance.

[Tim Holloway]

Maki Tolentino wrote:Tim, just one question.

How does yahoo and large portals create their websites?

Is their site 1 big web application or is it composed of smaller webapps? (yahoo mail, groups, etc.. )

I noticed that when you logged in their main site, the modules remember your session (user credentials and such).

thanks in advance.

I don't really know, but I expect that there are whole suites of applications, just because their scope over the years has expanded to the point where a single do-everything app isn't supportable. And, in fact, most such endeavors are done on a variety of platforms and in multiple programming languages.

Single-Signon isn't that hard, but I should point out that there's a significant difference between a "session" in the HttpSession sense and authentication credentials.

The ability to work in a single-signon environment is also one of the items on my "Why DIY webapp security is Bad" list. When you have a single container-based security manager, it acts as the authentication central control point, and if the security realm module supports it, you can have either server-local SSO or site-wide SSO. SSO makes mega-sites a lot more convenient, but it's also important if you're running a portal site. If you want to really abuse people, make them sign on separately to 16 different portlets on the same web page.

If my memory isn't deceiving me, Yahoo supports OpenID, which is like the old Microsoft Passport system, where if you sign on to any node in the security net, you can carry over the signon to other participants. However, unlike Passport, OpenID is designed to work without trusting your life to a specific vendor's (i. e., Microsoft's) servers.

Returning to the topic of sessions - the HttpSession object is normally bound to a single user of a single J2EE webapp and is not shared. The security session, however, is not. Ig There's no inherent data store in the security session, the way there is in an HttpSession, but you do always have a key - the user ID available from request.getUserPrincipal, and if you're using SSO, this is going to be the same ID for all SSO participants. The UserPrincipal can then be used as a reference point (key) to access shared data from whatever resources you choose - databases, shared memory hashes, messaging systems or whatever.