File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes Storing User Session attributes through JSF selected item Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Storing User Session attributes through JSF selected item" Watch "Storing User Session attributes through JSF selected item" New topic
Author

Storing User Session attributes through JSF selected item

marcel vieira
Greenhorn

Joined: Apr 27, 2011
Posts: 11
I have to use the company's login resource, which returns a login page for authentication after a browser/user page request; after successfully authenticated, the session attributes are set in a (remote) valued object (VO) invoked via servlet; then, such values are set in my (local) POJO.

I want to display the current user session attribute (see xChave below) and save it in database. How can I persist http User session attributes through the structure below?

Abstract Controller (just the main code):


IroController (just the main code):


JSF:


I'm thinking to inject the iroController in the POJO and set the desired attribute in the init():


Thanks in advance.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Just a bit of nit-picking. You do not write Controllers in JSF. The primary Controller in JSF is the FacesServlet and the sub-controllers are pre-supplied in the JSF tag implementations. You only code View Templates and Models. Action methods and such within Models are not Controller code (they don't do the Controller's function of transferring values between Model and View), but are instead additional code outside of the MVC domain.

Also, it's bad practice to use underscores in Java names, even though it's legal. The general convention - for better or worse - is camelCase, and some tools may malfunction if they have to deal with unconventional names.

JSF entities are exactly the same thing as J2EE entities, except that JSF automatically constructs them if they don't exist when needed. So you can inject a servlet-created Session object into a Managed Bean, no problem, and no need to rummage around in JSF internal data structures to locate it.

Other than that, my technical term for user-designed login systems is "hacked", based on experience with many, many systems over the years. Most user-designed security is, in fact, so flimsy that an unskilled person can often bypass them in under 15 minutes. J2EE comes with a professionally-designed security subsystem and associated APIs that can repel a lot of attacks before they can even get near the webapp itself. It has been around for probably over 15 years and thus is well-proven. I recommend using it.


Customer surveys are for companies who didn't pay proper attention to begin with.
marcel vieira
Greenhorn

Joined: Apr 27, 2011
Posts: 11
Tim Holloway wrote:Just a bit of nit-picking. You do not write Controllers in JSF. The primary Controller in JSF is the FacesServlet and the sub-controllers are pre-supplied in the JSF tag implementations. You only code View Templates and Models. Action methods and such within Models are not Controller code (they don't do the Controller's function of transferring values between Model and View), but are instead additional code outside of the MVC domain.

Also, it's bad practice to use underscores in Java names, even though it's legal. The general convention - for better or worse - is camelCase, and some tools may malfunction if they have to deal with unconventional names.

JSF entities are exactly the same thing as J2EE entities, except that JSF automatically constructs them if they don't exist when needed. So you can inject a servlet-created Session object into a Managed Bean, no problem, and no need to rummage around in JSF internal data structures to locate it.

Other than that, my technical term for user-designed login systems is "hacked", based on experience with many, many systems over the years. Most user-designed security is, in fact, so flimsy that an unskilled person can often bypass them in under 15 minutes. J2EE comes with a professionally-designed security subsystem and associated APIs that can repel a lot of attacks before they can even get near the webapp itself. It has been around for probably over 15 years and thus is well-proven. I recommend using it.


Hi Tim.
I really appreciate all your help and nit-picking (although there were some issues I already was aware of; the problem is that this webApp isn't mine and I'm not allowed to modify it right now).

Well, I've been studying this problem since you answered me, so I could try to have a better understanding on how it works, when and where using it etc.

In the Company where I work, I've already asked for a LDAP user bind, so I could use JEE-Security + Glassfish (JAAS, roles/groups etc -> I've followed Josh Juneau book, the JavaEE 7 Recipes, which would fit like a glove for my needs); but they denied me it! I was looking for some way to have a workaround on it, in the way as I could still use those JEE7 benefits (http://stackoverflow.com/questions/17052744/how-to-delegate-access-control-using-glassfish-roles-groups-indirectly). And now, I have to use this "amazing" Login Resource.

So, as I understood, there's a way to inject the servlet-created Session object into a Managed Bean and use its sesison attributes, right? I really tried to do it (see below), but no success.

Please, can you help me ?

(I've "cleared all the codes" to minimize its size and just focus on the problem. If you prefer, the full (Netbeans) project is available for download at: https://github.com/f6750699/navApp.git)

What I've did: created a Managed Bean where, I've injected the servlet that holds the session attributes:

The HttpServlet that holds the session attributes:

In JSF:

The AbstractController<T>:

The IroController:

The AbstractFacade (interacts with JPA):

The IroFacade:

Storing all data informed by the user in the form is fine, except the session attribute - which is null:
javax.el.PropertyNotFoundException: /WEB-INF/include/viagens/viagens/Create.xhtml @51,230 value="#{userBean.userID}": Target Unreachable, identifier 'userBean' resolved to null
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Too much information. I'm going to have to fall back to general observations - the old throw stuff out at random and hope trick. Sorry you're stuck with a something this ugly, though.

You have declared userBean via annotations using the newer generic bean management mechanism (whose name and JSR-# I forget). So one thing worth checking is to see if your webapp or webapp server is modern enough to scan for and process those annotations. Older webapp servers may not support the annotations directly, but in some cases, dropping an extra JAR into the WAR will give the same net effect, just like Tomcat doesn't implement the JEE JSF subsystem, but you can include a jsf-impl.jar in a Tomcat webapp's WAR to use JSF.

If you cannot get support for generic bean management, fall back to the old @ManagedBean annotation.

Of course, I'm presuming that this is a JSF2 webapp. JSF1 didn't support annotations at all, so you'd need to declare the bean in faces-config.xml. Which can still be used as the ultimate override for declaring managed beans.

A ManagedBean is instantiated on-demand and not before, so if it's never referenced in a displayed View's xhtml, it won't get instantiated. If non-JSF code needs the bean, it must manually construct and initialize it, then place it in the HttpSession object. JSF code will then see it in the HttpSession and will not attempt to re-instantiate it and the JSF and non-JSF code can happily share it subject to the usual thread-safety considerations.

And, of course, the FacesContext will not exist in non-JSF servlet code, nor should you attempt to manually construct one there. The FacesServlet gets re-constructed every time a JSF request comes to the FacesServlet and destroyed when the FacesServlet has finished with the response to that request.

Just to make one other thing clear, though. JAAS user-defined logins are just as hackable as non-JAAS user-defined logins. It isn't JAAS that makes the webapp more secure, it's using the container security framework. Which can work securely with JAAS, LDAP/Active Directory, JDBC, and many other security "databases".
 
Don't get me started about those stupid light bulbs.
 
subject: Storing User Session attributes through JSF selected item
 
Similar Threads
my a4j:commandButton is failing suddenly, bean is no longer initialized, returning null value.
How to destroy the Object of a SessionScoped bean
session bean
JSF 2.0 - Using Listboxes and Menus
relation between backing beans