| Author |
where to handle session here?
|
Balaji Khandekar
Greenhorn
Joined: Apr 27, 2010
Posts: 29
|
|
hi all,
i have two jsf pages 1st login and 2nd a tree view page
when user directly invoke url for 2nd page then it shoud navigate to login
i have checked session and write navigate code but it gives error.
i have wriiten code to check whether session is active or not in constructor.
Is it right place
|
 |
Tim Holloway
Saloon Keeper
Joined: Jun 25, 2001
Posts: 12513
|
|
I realize that almost every J2EE book ever written has some example that manages a login screen, but I wish they didn't.
I've worked with a lot of apps since J2EE first came out and every last one of the ones that did their own login code had security holes.
The J2EE standard has a built-in security system that can do exactly what you're saying, requires absolutely no java code to do it and has never as far as I know been successfully "hacked".
This is known as Container-Based Authentication and Authorization. You define a logon JSP and a login fail JSP and define them to web.xml. You also supply URL mappings to the security section of the web.xml file so that the URLs you want only accessible to logged-in users are designated as such to the security system.
Most decent J2EE books that cover servlets and JSPs cover this system as part of the introduction to secure transport.
JSF works quite well with the standard system, although since it protects URLs and not resources, any JSF action that navigates to a protected View should include a "redirect" element so that the proper URL will be set up.
|
One of the most odious afflictions that Business has inflicted on the modern English language is "pro-active". Most of the time it's simply redundantly used in place of the simple old word "active". And a good deal of the rest of the time it means "You're not overworked enough yet, so go out and find more!"
|
|
Phillip Ankerson
Greenhorn
Joined: Aug 10, 2011
Posts: 27
|
|
Doing some research on login pages...(before I post my issue, aren't you proud of me?  )
@Tim: So I will look into CBA/A...but say I wanted a user to be able to create and update records, but to delete, they needed a separate authorization level? I really don't want to do Deletes on a separate page...how does CBA/A handle something like that?
|
|
Tim Holloway
Saloon Keeper
Joined: Jun 25, 2001
Posts: 12513
|
|
The primary function of CBA is to protect URLs. That's important, because if you can't get to something, you cannot abuse it, and CBA ensures that unauthorized users are blocked even before getting to the application itself.
However, sometimes you want finer-grained control. A variation of what you're asking about that I've been known to do is present pages where some users can view (auditors) and some users can update (editors).
There are generally 2 parts to this sort of control. One is presentation, If you simply switch the input controls to readonly mode, you can physically inhibit auditors from being able to submit updates. But to be truly secure, you also need a second part, since a hacker can simply alter the page to re-enable the controls.
For that you need code in the backing bean. The good news is that it's pretty simple to do. The bad news is that JSF doesn't help much. In order to check the user's security roles, you have to obtain the HttpServletRequest, and since JSF is externally independent of such things, that means that you have to get the FacesContext and chase through it to get the request object.
To do that requires some fairly gnarly code and it potentially injects framework dependencies into what should otherwise be a POJO. To get around this, I usually implement a "JSFUtils" class that I use when I need access to the Servlet infrastructure. Also for general JSF utilitity, such as stuffing user-generated error messages into the JSF messages obbject. I can then replace this object with a mock object for testing purposes. So that leaves me with stuff like this:
|
|
Phillip Ankerson
Greenhorn
Joined: Aug 10, 2011
Posts: 27
|
|
|
Very interesting and I appreciate the info. You may already know stuff like that is probably a little advanced for me at this point, but I'll hang on to it. I finally got my "login" page to work; it will be used internally for now so I'm not as concerned about security (concerned, just not as concerned - right now :-)
|
|
 |
|
|
subject: where to handle session here?
|
|
|
0
