Forum:

Problem with navigation in JSF with Filter

Greenhorn

Posts: 10

posted 14 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

I have a little problem. I tried to do my own filter to determine, which role can acces which part of site. Everithing works fine, until i sent navigation from backing bean.
EG:
In page:

with BackingBean:

package sessionBeans;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.ManagedProperty;
import javax.faces.bean.RequestScoped;
import prcek.login.sessionBeans.UserTokenSessionBean;

@ManagedBean(name="indexReqBean")
@RequestScoped
public class indexReqBean {
    private String username;
    private String password;

@ManagedProperty("#{userTokenSessionBean}")
    private UserTokenSessionBean bean;

/** Creates a new instance of indexReqBean */
    public indexReqBean() {
    }
    public UserTokenSessionBean getBean() {
        return bean;
    }

public void setBean(UserTokenSessionBean bean) {
        this.bean = bean;
    }
    public String getPassword() {
        return password;
    }
    public void setPassword(String password) {
        this.password = password;
    }
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
    public String perform(){
        return "private/index";
    }
}

When I in filter use this methods:

I am able to say, which page I acces,but only, when I use <h:link>. If i acces to the page from <h:link>, or from browser, everithing is fine. But when I click to the button and execute the perform method, i can´t say, where i was redirected, because only information, i get is index.xhtml, but i need to see private/index.xhtml. Is there any way to fix this?

Sever: GlassFish v3
JSF 2.1
Mostly using NetBeans

Tim Holloway

Saloon Keeper

Posts: 28319

210

I like...

posted 14 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Welcome to the JavaRanch Lukas!

Once you've been around here a while, you'll get mightily sick of hearing me denounce "Do It Yourself" J2EE security systems. I've a list about 12 items long as to why they're a bad idea, and one of them is because this kind of stuff is already, debugged, working and documented in the standard J2EE-defined security framework. Meaning you can spend your time on more profitable endeavours since the J2EE implementers have already done all the dirty work for you. Including figuring out how people would get around it.

I can't be 100% certain, here. It's not worth the trouble for me to analyze in detail. After, all, like I said, there's already something that works, so it's not likely I'll need to "borrow" this code. However, it certainly looks similar to a problem you'll have when using the built-in security system. And if that's the case, you can cure it by putting a <redirect/> element in your navigation rule. The redirect element has no attributes or children, so it's coded exactly as you see it.

Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.

Lukas Hnatuk

Greenhorn

Posts: 10

posted 14 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Tim Holloway wrote:Once you've been around here a while, you'll get mightily sick of hearing me denounce "Do It Yourself" J2EE security systems. I've a list about 12 items long as to why they're a bad idea, and one of them is because this kind of stuff is already, debugged, working and documented in the standard J2EE-defined security framework. Meaning you can spend your time on more profitable endeavours since the J2EE implementers have already done all the dirty work for you. Including figuring out how people would get around it.

If you can tell me some tip, i would be more than glad for it.
I start with JSecurity(now it is Shiro), which was fine, but most of its items did not work. Then I heard about Spring Security, but after two days of trying to understand, how it works i gave up. The same was with JAAS... After more than two weeks of trying,i realized, that most effective would be to do it myself.

Sever: GlassFish v3
JSF 2.1
Mostly using NetBeans

Tim Holloway

Saloon Keeper

Posts: 28319

210

I like...

posted 14 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

For most purposes, the basic JEE security system is sufficient. It can be augmented for apps that need fine-grained security, but I always like to use it to "bar the main gates", so to speak. Keep ordinary users out of the admin functions, keep unauthorized users out of whereever, and so forth.

JEE container security is easy to set up and use and it doesn't have to be invoked because it wraps itself around the webapp and prevents access to application code and resources by unathorized users. The application-specific side is documented in most books on servlets, and the face that it is well-documented is one of its selling points. Basically the app defined guards on URLs via entries in the web.xml file and can add guards on specific sensitive logic functions using the isUserInRole request access method, or for EJBs, the isCallerInRole() method. You can get the user ID from the HttpRequest object as well - it's null if the user hasn't logged in, and it makes a natural "key" for looking up any fine-grained access rules you may want to apply.

The other side of J2EE security is the container side, commonly known as a Realm, which is configured as part of the application deployment. Since J2EE container security is a "black box", you can swap Realms with no effect on the structure of the webapp or its logic. This is handy for testing where you can use a MemoryRealm (XML file) for userids and roles while testing and something more elaborate like a JNDI or database Realm for production.

Another plus is that since a good deal of the security is externally applied, you can code, test, and debug your application without security code getting in the way, adding the security features later. Most of the DIY systems tend to plop security functions right down amongst the business logic, where they not only interfere with initial development, but become a maintenance nightmare. Partly because people coming along later may not know if/when/how to use the security functions, and partly because changes to the security system often end up causing mods all over the application.

Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.

mallareddy gamannagari

Greenhorn

Posts: 3

posted 12 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

hi all,
here, i want to use JEE container based security for my application. Here i have configured realm in tomcat and in my application and validating user and role succeeded but the problem is i'm not getting how to redirect to my home page after completion of j_security_check

in my page i'm getting fallowing error
in url:::::::::http://localhost:9999/HMS/j_security_check
in webpage:::::::
HTTP Status 408 - The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser

please helm me anyone
thanks to advance all...... :rolleyes

Tim Holloway

Saloon Keeper

Posts: 28319

210

I like...

posted 12 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

mallareddy gamannagari wrote:hi all,
here, i want to use JEE container based security for my application. Here i have configured realm in tomcat and in my application and validating user and role succeeded but the problem is i'm not getting how to redirect to my home page after completion of j_security_check

in my page i'm getting fallowing error
in url:::::::::http://localhost:9999/HMS/j_security_check
in webpage:::::::
HTTP Status 408 - The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser

please helm me anyone
thanks to advance all...... :rolleyes

Please do not post the same question in multiple places.

I answered this question in the Tomcat forum.

Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.

The moustache of a titan! The ad of a flea:

Gift giving made easy with the permaculture playing cards

https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing