How control access and rights in JSF?

后端 未结 1 1853
我在风中等你
我在风中等你 2020-11-28 05:20

I would like to control the access after the user log in my system.

For example:

administrator : can add, delete and give rights to employee
employee         


        
相关标签:
1条回答
  • 2020-11-28 05:45

    Well, this is a pretty broad subject. As you're starting off with homebrewed authentication, I'll target the answer on homebrewed authorization.


    Role checking in Java/JSF is at its own relatively simple if the model is sensibly designed. Assuming that a single user can have multiple roles (as is often the case in real world applications), you'd ultimately like to end up having something like:

    public class User {
    
        private List<Role> roles;
    
        // ...
    
        public boolean hasRole(Role role) {
            return roles.contains(role);
        }
    
    }
    
    public enum Role {
    
        EMPLOYEE, MANAGER, ADMIN;
    
    }
    

    so that you can check it as follows in your JSF views:

    <h:selectManyCheckbox value="#{user.roles}" disabled="#{not user.hasRole('ADMIN')}">
        <f:selectItems value="#{Role}" />
    </h:selectManyCheckbox>
    
    <h:commandButton value="Delete" rendered="#{user.hasRole('ADMIN')}" />
    

    and in your filter:

    String path = req.getRequestURI().substring(req.getContextPath().length());
    
    if (path.startsWith("/integra/user/admin/") && !user.hasRole(Role.ADMIN)) {
        res.sendError(HttpServletResponse.SC_UNAUTHORIZED);
    }
    

    The hardest part is translating this Java model to a sane DB model. There are several different ways depending on the concrete business requirements, each with its own (dis)advantages. Or perhaps you already have a DB model on which you have to base your Java model (thus, you need to design bottom-up)?

    Anyway, assuming that you're using JPA 2.0 (your question history at least confirms this) and that you can design top-down, one of the easiest ways would be to map the roles property as an @ElementCollection against an user_roles table. As we're using a Role enum, a second role table isn't necessary. Again, that depends on the concrete functional and business requirements.

    In generic SQL terms, the user_roles table can look like this:

    CREATE TABLE user_roles (
        user_id BIGINT REFERENCES user(id),
        role VARCHAR(16) NOT NULL,
        PRIMARY KEY(user_id, role)
    )
    

    Which is then to be mapped as follows:

    @ElementCollection(targetClass=Role.class, fetch=FetchType.EAGER)
    @Enumerated(EnumType.STRING)
    @CollectionTable(name="user_roles", joinColumns={@JoinColumn(name="user_id")})
    @Column(name="role")
    private List<Role> roles;
    

    That's basically all you'd need to change in your User entity.


    Next to homebrewed authentication (login/logout) and authorization (role checking), there is also Java EE provided container managed authentication with which you can login by j_security_check or HttpServletRequest#login(), filter HTTP requests by <security-constraint> in web.xml, check the logged-in user by #{request.remoteUser} and its roles by #{request.isUserInRole('ADMIN')}, etc.

    Then there are several 3rd party frameworks such as PicketLink, Spring Security, Apache Shiro, etc. But this is all out of the question :)

    0 讨论(0)
提交回复
热议问题