Additional table pages might be useful: which roles use a particular permission? which users have a particular role? These are left as an exercise for the reader.

Additional table pages might be useful: which roles use a particular permission? which users have a particular role? These are left as an exercise for the reader.

+

+

{{note|Where to create the outline|If you create a new outline in the folder '''All Outlines''' you will do just that. If you create a new outline for the '''Desktop''', the SDK will not only create an outline for you, it will also '''register it on the Desktop''' and it will '''create a button for it'''.}}

=== Permission Table Page and Outline Service ===

=== Permission Table Page and Outline Service ===

Revision as of 06:01, 31 October 2012

Scout TutorialPermissions are created for you in the background by the SDK as you build your application, but they don't seem to have any effects. That's because by default, you're using the "anonymous" security filter and because you're being granted the "all" permission. This chapter shows you how to change that.This page is an optional addition to the Minicrm Step-by-Step Tutorial and uses it as a starting point.

Administration Outline

Additional table pages might be useful: which roles use a particular permission? which users have a particular role? These are left as an exercise for the reader.

Where to create the outlineIf you create a new outline in the folder All Outlines you will do just that. If you create a new outline for the Desktop, the SDK will not only create an outline for you, it will also register it on the Desktop and it will create a button for it.

Permission Table Page and Outline Service

We'll be using this table in two places, thus we need a variable for the role (RoleNr).

If a role is provided, we need a service on the server side to provide these. Create a new outline service (AdministrationOutlineService) with an operation to get all the roles (getPermissionTableData) with a single argument of type Long (roleNr).

If no role is provided, we list all the permissions. These are all available on the client. We don't need service on the server side to fetch them. Thus, on the client side, things look a bit different. Here's execLoadTableData for the newly created PermissionTablePage.

No data is visible because the permissions haven't been assigned to roles, yet. This will be our next task.

Assigning Permissions to Roles

We will create a menu which calls a tiny form to assign one or more permissions to a role. The form will contain nothing but a smart field with roles.

Let's start with the form.

Create a new form called AssignToRoleForm; do not create am Id (no AssignToRoleNr). On the second page of the wizard, get rid of the ModifyHandler, the ReadAssignToRolePermission and the UpdateAssignToRolePermission.

Add a smart field RoleField using LookupCall RoleLookupCall.

Add a variable of type String called Permission. Now do something which the SDK doesn't do for you: change the type of m_permission from String to String[] and change getPermission and setPermission to match.

Switch to the AssignToRoleProcessService and remove the load and store operations. (You may have to remove them from the interface IAssignToRoleProcessService as well.)

For the moment, there is nothing to do for the prepareCreate operation. For the create operation, use the following statement:

Switch to the PermissionTablePage and add a menu called AssignToRoleMenu.
Have it start the AssignToRoleForm and call the NewHandler.
Mark the menu as both a Single Selection Action and a Multi Selection Action.
Change the execAction as follows:

Missing Pieces

make sure menus that will result in "permission denied" errors are invisible

make table pages invisible that display information you are not allowed to read

Authentication

Before you continue: make sure the administrator has the username "admin" and the administrator role. Make sure the administrator role has been assigned all permissions. Once we're done here you can lock yourself out of the application. If that happens, you will have to fix the permissions on the database.

Identifying Users

To get an idea of what goes on, find the ServerSession and change execLoadSession as follows:

@Override
protectedvoid execLoadSession()throws ProcessingException{
logger.warn("created a new session for "+getUserId());}

When you start a new client, you'll see:

!MESSAGE eclipse.org.minicrm.server.ServerSession.execLoadSession(ServerSession.java:46) created a new session for anonymous

What user id? This is handled by security filters. Go to the config file of your server product (/eclipse.org.minicrm.server/products/development/config.ini). You'll see that the AnonymousSecurityFilter is active. IT provides the user id "anonymous".

Now you can attempt to login with a valid username/password combination and the system will check whether a person actually uses the usernames provided. By default, the three users in the demo database match the usernames in the config file. You need to add more combinations to the config file in order to test it.

Granting Permissions to Users

Find the AccessControlService class and take a look at the execLoadPermissions method: