com.smartgwt.client.docs

Interface DeclarativeSecurity

public interface DeclarativeSecurity

Declarative Security

The Declarative Security system allows you to attach role based access control to DataSource operations and DataSource fields, as well as create a mix of authenticated and non authenticated operations for applications that support limited publicly accessible functionality.

See the QuickStart Guide for more in depth documentation on how declarative security works and how to use it in your application.

See Standalone DataSource Usage for information on how to use declarative security in a standalone application.

NOTE: Declarative security only works for DataSource operations (including DataSource DMI operations). If you want to limit access to an ordinary RPC-DMI method - so it can only be called by authenticated users, only users with a certain role, etc - you have two choices:

• Have your DMI method accept a parameter of type HttpServletRequest; that will cause Smart GWT to pass the current servlet request into your method, and you can directly call the getRemoteUser() and isUserInRole() methods to implement your own security
• Migrate your RPC-DMIs to DataSource DMI operations and get full declarative security support that way. Note that any plain RPC-DMI function can be reworked as a DataSource DMI operation; even if your RPC-DMI manifestly is not fetching a dataset or updating a record, you can use a custom operation

Requests that fail to pass Declarative Security checks will return a response with status of STATUS_AUTHORIZATION_FAILURE.

Client-side declarative security

Client-only dataSources automatically simulate the server-side Declarative Security system. Although this is obviously not useful in a production setting, the simulator is extremely valuable because it allows you to implement and test the effect of roles on the UI, and then switch over to the real authentication system without changing any of the UI code. This is in keeping with the Smart GWT philosophy on dataSources, which is that you should be able to test with a local, client-only dataSource and local test data, and then switch to a real server-side dataSource with confidence that no client code will be affected.

To use client-side declarative security simulation, just create a clientOnly dataSource that specifies some of the declarative security rules linked to below. All of these rules, at a minimum, require authentication, so you will also have to provide a dummy authenticated user to the simulator by use of the client side Authentication class

     Record currentUser = new Record();
     currentUser.setAttribute("userId", "john_doe");
     Authentication.setCurrentUser(currentUser);
  

Many declarative security rules also require a role, such as "payroll" or "manager", so you may also need to provide roles to the client-side simulator

     Authentication.setRoles(new String[] {"order_handling","supervisor"});
  

The example linked below shows how to use the client-side declarative security simulator to implement and test role-based security rules on both operations and individual fields.

See Also:

StandaloneDataSourceUsage, DataSource.requiresAuthentication, DataSource.requiresRole, DataSource.requires, DataSource.creatorOverrides, DataSourceField.viewRequiresAuthentication, DataSourceField.editRequiresAuthentication, DataSourceField.initRequiresAuthentication, DataSourceField.updateRequiresAuthentication, DataSourceField.viewRequiresRole, DataSourceField.editRequiresRole, DataSourceField.initRequiresRole, DataSourceField.updateRequiresRole, DataSourceField.viewRequires, DataSourceField.editRequires, DataSourceField.initRequires, DataSourceField.updateRequires, DataSourceField.creatorOverrides, OperationBinding.requiresAuthentication, OperationBinding.requiresRole, OperationBinding.requires, OperationBinding.creatorOverrides, DataSource.getEnforceSecurityOnClient()