aspose file tools*
The moose likes JSF and the fly likes Capturing JSF Session variables. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Capturing JSF Session variables." Watch "Capturing JSF Session variables." New topic
Author

Capturing JSF Session variables.

Ronald Alarcon
Greenhorn

Joined: May 29, 2011
Posts: 22

Introduction:
I am new on JSF Framework relatively. My Class mates and I are developing a system for an "saving and credit union", we are using PrimeFaces TagLibs, JSF, JPA and Oracle Database. We have made a nice looking GUI using JSF + PrimeFaces and im working on Database relatively easy for me because i work actually like a PL/SQL developer. We are using SVN and Google Code for versioning repository, we have allmost all planned for the project.

So i will be asking some questions here in the forum when something isn't understood on my development team, and we can't get more info on books or internet i will be grateful for your time and your responses.

The real problem:
Now we have the GUI we want to save the session for an user, in PL/SQL we can use a Global Variable but in Java Web i'm just thinking about using session beans. The access to each webpage is controlled by a dynamic menu using roles defined on database for each user so i want to capture:

  • user
  • role


  • When each user get into a page the page will validate the user session (active or not) and the corresponding role, actually we're thinking in four roles:
  • Operative
  • Client
  • IT Administrator
  • Operative Manager


  • So Thanks in advance for your responses.


    <<Write once run everywhere...>>
    Tim Holloway
    Saloon Keeper

    Joined: Jun 25, 2001
    Posts: 16065
        
      21

    Not to disparage your PL/SQL skills, but I have discovered (the hard way) that database stored procedures are a programming nightmare and should be used sparingly. The problem is that it fractures the app into 2 different sets of source code, and so the first thing a maintenance programmer always has to do when working on the app is figure out which source code (java or PL/SQL) a given function is in. Also, stored procedures don't easily fit into source code version control. Which means that shipping source code to someone else can be a and that getting old copies of a function require the assistance of a DBA.

    Stored procedures can be more efficient, but if we really needed that much more efficiency, we'd still be coding in assembly language and not using expensive frameworks like JDBC and JSF. Plus, you're dumping extra work on the database server machine and usually there are more appservers than DB servers.

    Users and Roles are not something that I recommend handling yourself. J2EE has a built-in container-managed security system that uses role-based access control as well as authentication (login). It is far, far more secure than user-written security systems, since it was designed by security specialists and has had more than a decade of real-world use to prove itself. In that same period of time I've encountered more user-written security systems than I can count, including some in critical finance apps and even military use. And not one blessed one of them had any real security at all. Most could be defeated in 15 minutes or less.

    You don't need session objects for userids and roles using the J2EE standard security system. The userid is available from the HttpServletRequest, and roles can be checked via the isUserInRole() method. More importantly, the J2EE security standard can keep people from accessing secured pages altogether via declarations in web.xml without any code at all.

    There is one caveat for JSF, however. JSF doesn't normally track URLs as closely as most frameworks, and the J2EE page protection is based on the URL, not the page view definition file resource. This is easily allowed for by using the "redirect" JSF navigation option.


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

    Joined: May 29, 2011
    Posts: 22

    Tim Holloway wrote:Not to disparage your PL/SQL skills, but I have discovered (the hard way) that database stored procedures are a programming nightmare and should be used sparingly. The problem is that it fractures the app into 2 different sets of source code, and so the first thing a maintenance programmer always has to do when working on the app is figure out which source code (java or PL/SQL) a given function is in. Also, stored procedures don't easily fit into source code version control. Which means that shipping source code to someone else can be a and that getting old copies of a function require the assistance of a DBA.

    Stored procedures can be more efficient, but if we really needed that much more efficiency, we'd still be coding in assembly language and not using expensive frameworks like JDBC and JSF. Plus, you're dumping extra work on the database server machine and usually there are more appservers than DB servers.

    Some comments:
    There is SVN for PL/SQL Development too, SQL Developer like Netbeans has a Subversion Client inlaid. You´re right the SP are used in some cases but arent necessary, thanks for recommendation but isnt my case, i was just mentioning that i work on pl/sql development.

    Tim Holloway wrote:
    Users and Roles are not something that I recommend handling yourself. J2EE has a built-in container-managed security system that uses role-based access control as well as authentication (login). It is far, far more secure than user-written security systems, since it was designed by security specialists and has had more than a decade of real-world use to prove itself. In that same period of time I've encountered more user-written security systems than I can count, including some in critical finance apps and even military use. And not one blessed one of them had any real security at all. Most could be defeated in 15 minutes or less.


    You don't need session objects for userids and roles using the J2EE standard security system. The userid is available from the HttpServletRequest, and roles can be checked via the isUserInRole() method. More importantly, the J2EE security standard can keep people from accessing secured pages altogether via declarations in web.xml without any code at all.

    Are you Talking about JAAS?

    Tim Holloway wrote:
    There is one caveat for JSF, however. JSF doesn't normally track URLs as closely as most frameworks, and the J2EE page protection is based on the URL, not the page view definition file resource. This is easily allowed for by using the "redirect" JSF navigation option.

    Are you talking about JSF navigation rules?
    Tim Holloway
    Saloon Keeper

    Joined: Jun 25, 2001
    Posts: 16065
        
      21

    1. I'd like a link on that, if you could provide one. Might be useful at some point. Unfortunately, where I have my real scorch marks, the database was SQL Server. I got sent a ZIP file with the source code. Then I got sent another zip file with a database in it. I then had to import the database and chase down some scripts to dump all the stored procedures out of the database and into text files.

    2. No. J2EE security is Container Managed Security (not to be confused with Content Management Systems). CM security usually is backed by plug-in security Realm modules that are configured into the server itself. Tomcat, for example, comes with a Realm that uses a simple XML file to define users and roles, 2 different database Realms, a JAAS Realm, and an LDAP/Active Directory Realm. And that's just the beginning. I've also done custom Realms on occasion, like when I needed to interface with a corporate web service based security system.

    3. That's correct. redirect an option on JSF view navigation.
    Ronald Alarcon
    Greenhorn

    Joined: May 29, 2011
    Posts: 22

    Tim Holloway wrote:1. I'd like a link on that, if you could provide one. Might be useful at some point. Unfortunately, where I have my real scorch marks, the database was SQL Server. I got sent a ZIP file with the source code. Then I got sent another zip file with a database in it. I then had to import the database and chase down some scripts to dump all the stored procedures out of the database and into text files.

    A link: http://gerardnico.com/wiki/ide/sqldeveloper/svn
    An Example: http://st-curriculum.oracle.com/obe/db/11g/r2/prod/appdev/sqldev/srccodexmlext/srccode_otn.htm
    Im not sure if SVN just works using Oracle Database, but SQL Developer its another great Java product, so you can add jdbc driver for another databases including MS SQL Server (I have tested it), try it and maybe its possible.

    Tim Holloway wrote:
    2. No. J2EE security is Container Managed Security (not to be confused with Content Management Systems). CM security usually is backed by plug-in security Realm modules that are configured into the server itself. Tomcat, for example, comes with a Realm that uses a simple XML file to define users and roles, 2 different database Realms, a JAAS Realm, and an LDAP/Active Directory Realm. And that's just the beginning. I've also done custom Realms on occasion, like when I needed to interface with a corporate web service based security system.

    Interesting, i will investigate about CMS. Do you know if GlassFish implements this?
    I was thinking about using LDAP on the beginning, i was looking for OpenDS, but this project must be finished in two months so we need to use the basics and dont have enough time for learning some tools (This is the big problem).

    Tim Holloway wrote:
    3. That's correct. redirect an option on JSF view navigation.

    Thanks.
    Tim Holloway
    Saloon Keeper

    Joined: Jun 25, 2001
    Posts: 16065
        
      21

    Thanks for the svn link. Looks like it would be a little awkward for those of us who live our lives in Eclipse or NetBeans, though.


    Interesting, i will investigate about CMS. Do you know if GlassFish implements this?


    CM Security is part of the core J2EE and JEE standards. That means that any J2EE/JEE appserver that even pretends to be standards-compliant must support this feature. Glassfish, Tomcat, WebSphere, WebLogic, JOnAS, OC4J, whatever. That's one of the other main reasons I recommend it. You can read about it in any decent book on Enterprise Java, which is more than I can say about the one-off Do-It-Yourself security frameworks.

    The majority of the webapps on the mousetech.com servers use LDAP as their user/role definition repository. Configuring LDAP can be a nuisance, however, so for academic purposes, I'd recommend using a more tractable repository such as a database or (in the case of Tomcat) xml file. Since the security is managed in the appserver and not the webapp, you can then change to an alternative repository system later without having to modify or rebuild the webapp.
    Ronald Alarcon
    Greenhorn

    Joined: May 29, 2011
    Posts: 22

    So its mean i have to investigate a little more about your recommendations. Than you Tim.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Capturing JSF Session variables.