In this section, we introduce the concept of a profile, user roles, and restrictions. Profile (@UiProfile) is understood as a type of the resulting code fragment, such as the creation of a new instance versus update versus search, view, etc. The user roles (@UiUserRoles) depicts visualization of given fragment based on the user security roles, such as fragment for editing differs for admin and for a reviewer. The @UiRestrict the allows you to define expression language (EL) formulas evaluable to a boolean value. Below we introduce these concepts in more details.

@UiProfiles

Sometimes we want to use the same data entity with given fields, but to restrict certain fields based on given context. For example, consider a situation with a class address that gathers information about country and state. Although not all countries might have a state, we can use GeoIP to locate the user and offer him a UI with or without the state field. In the entity, we use an annotation @UiProfiles({..}) and pass there a string key that is used for determining whether or not to use the field.

Usage of Profile in class Address

#!java

// class Address

@UiOrder(45)
public Country getCountry() { return country; }

@UiOrder(50)
@UiProfiles({ "US","CA" })
public String getState() { return state; }

Next, we need to expose the current profile to use to the AspectFaces context. For JSF we do it in a way as is described in 7.1. Aspect Faces Context.

Information passing to the context through the JSFHandler

#!java

public class CustomHandler extends DefaultAFGeneratorHandler {

 @Override
 protected void hookAddToAFContext(Context context) {
    String location = "US"; // acquired via GeoIP detection
    context.setProfiles( new String[]{ location } );
 }
}

@UiUserRoles

To apply field-level role-based access control (RBAC) similar to @RolesAllowed in Java EE (Tutorial: Java EE 6), you can use @UiUserRoles({..}) to mark roles that have access to a given field. Then pass the current user role to the AF Context. There is no direct connection to Java EE principals concept, etc., because there are many security frameworks and different kinds of authentication tools, thus Aspect Faces doesn't want to enforce just one implementation. For that reason, there is no direct connection to any implementation but a developer is still free to connect it himself.

Roles

#!java

@Email
@UiOrder(11)
@UiUserRoles({ "Admin", "Owner" }) // allowed roles
public String getEmail() { return email; }

Passing the actual role is similar to the example above and described in 7.1. Aspect Faces Context.

Information passing to the context through the JSFHandler

#!java

public class CustomHandler extends DefaultAFGeneratorHandler {

 @Override
 protected void hookAddToAFContext(Context context) {

    // get current user roles - integrate your access rights system.
    String role = "Admin";
    context.setRoles( new String[]{ role } );
 }
}

@UiRestrict

To further extend the security concept, option @UiRestrict provides you with the ability to evaluate some EL. The string from the @UiRestrict(String) is evaluated as EL and resolves to true or false. You need to use the javaee-connector module with this, but its default part of javaee-jsf2 meta-package.