Login Pattern
The "Login" is the design pattern by which a user is granted access to the protected resources of an application; this is normally done by means of the validation of his identity through the submission of credentials, such as a username and a password. The "Login" design pattern can be modeled in different ways depending on the requirements. The basic version, which we show in this lesson, models the "Login" action definition with a single operation, the "Login" operation.
User Model
The "Login" operation works using a particular portion of the Domain Model, called the "User Model". This means that by default the Web application uses the database as a source of information for validating the user's identity. The "User model" is composed of three entities - "User", "Group", and "Module" - and is used to manage access rights. These three entities are added by default into the Domain Model as you create a new Web Project. The "User" entity models the basic information about users used to identify and authenticate them. The "Group" entity models the set of roles relevant for the Web application. The "Module" entity models the list of the Web application elements that are subjected to access restrictions. "User", "Group" and "Module" are connected with relationships. Each user can have a default group, and each group can have a default module.
Protected Modules
The instances of the "User" and "Group" entity must be created prior to using the login pattern, for example with a dedicated Web application area modeled in WebRatio Platform. Conversely the instances of the "Module" entity can be created automatically by WebRatio Platform. Also the relationships data between "User", "Group" and "Module" entities must be managed with a dedicated Web application area or filled into the database by hand. You can establish in the Web Project which elements have access restriction. The attempt at accessing a restricted model element, for example an Area, Page or Site View, by an unauthorized user causes the application to automatically show a form for the user to authenticate. To restrict the access to a model element you have to check the "Protected" property for it. To enable the automatic creation of the instances of the "Module" table from the model elements that have the protected property, you have to enable the "Admin Area" from the "Project" Properties View.
How to Enable Automatic Creation the Instances of "Module" Table
The "Admin Area" is a specific section of the Web application, automatically generated by WebRatio Platform, which supports the editing of the content of the "Module" entity. To activate its generation, select the "Project" tab of your Web Project and then check the property "Enable Admin Area". Optionally, you can set the path used to reach the "Admin Area" and the credentials for the user who will act as the administrator, entitled to access the "Admin Area". To use "Admin Area", generate the project using the "Generate and Run" button from the main menu and access the URL: "http://Host:Port/AppName/AdminAreaPath.do". If the properties "Admin Path", "Username" and "Password" are left undefined, the following default values are used:
- Admin Path: "WRAdmin/Home.do"
- Username: "manager"
- Password: "m4n4g3r"
Login Operation
The "User Model" is required by the default implementation of the "Login" operation, provided off-the-shelf by WebRatio Platform. The "Login" operation can be used inside an "Action Definition" and exposes three input parameters: "Username", "Password", and "Remember Credentials". The "Login" operation checks whether the user exists, if the password is correct, and then decides which sections of the Web application to show to the user after authentication.
Login Mechanism
The "Login" operation reads information from the "User Model", starting from the "User" entity. It checks whether a user with the specific "Username" and "Password" exists. Then, it exploits the "User_DefaultGroup" many to one (N-1) relationship between the "User" and "Group" entities to retrieve the unique default group of the user. If a default group for the user is found, a join is done with the "Group_DefaultModule" many to one (1-N) relationship, pointing to the "Module" entity to retrieve the group’s default module. If a group's default module is found, the operation redirects automatically the user to the found module. If no default group is found, for each group connected to the user by the "User_Group" many to many (N-N) Relationship, a default module is searched. If no such default module is found, then the login operation cannot decide the page to show to the user and follows the "KO Flow", which signals an unsuccessful termination of the authentication procedure.
How to Model the "Login" Action Definition
Let's see now how to define the "Action Definition" for the "Login". To model an "Action Definition" you need a specific container, which is the "Module Definitions View". To create a new "Module Definitions View", open the "Project" tab in the main work area, right click on the "Module Definitions" icon, and choose the "Add Module Definitions" command. Type a name for the "Module Definitions View" in the opening dialog and press the "Finish" button to confirm. After this operation, WebRatio Platform brings you directly inside the "Module Definitions View". Let’s now create an "Action Definition" for the login. Select the command "Action Definition" icon from the toolbar on the left and place the "Action Definition" inside the workarea. Then type the desired name for that "Action Definition", for example "Login". Double-click on the "Login" action definition to open it and start modeling its behavior. Now you have to add a "Login" operation to the "Action Definition". Select the "Login" Operation from the "Session Components" section in the toolbar and click inside the work area.
To express the activation of the "Login" operation, add an "OK Flow" from the "Input Port" to the "Login" operation, by selecting the "OK Flow" icon from the "Flows" section of the toolbar and clicking on the "Input Port" and then on the "Login" operation. As the "Login" operation needs to receive the user credentials from the invoking environment, the appropriate input parameters must be added to the "Input Port". Right-click on the "Input Port" and choose the "Input Port Wizard" option. The opening dialog asks for the operation that will receive the parameters. Choose the "Login" operation and press the "Next" button. Choose the parameters to add; in this case "Username" and "Password" suffice. Press the "Finish" button to complete the work.
The "Input Port Wizard" automatically binds the parameters on the "OK Flow" to the target operation. Since the "Login" automatically infers which is the module to redirect the user to, it's not necessary to explicitly handle the "OK Flow". Add only one "KO Port" to the "Action Definition". Right-click on the workarea, open the "Add" menu, and select the "KO Port" command. Connect the "Login" operation to the "KO Port" with a "KO Flow" by selecting the "KO Flow" icon from the "Flows" section of the toolbar and clicking on the "Login" operation and then on the "KO Port".
How to Refer the "Login" Action Definition
To exploit the "Action Definition" just constructed for the "Login" basic pattern, go back to the IFML Model presented in the lesson about "Access Control". Let's recall the model shown in the lesson about "Access Control". The page "Please Login" exposes a "Form" that contains two fields, "Username" and "Password", and the submit button to trigger the "Login" action. A "KO Flow" connects the "Action" and the "Page". To make a reference from the "Action" to the "Login" action definition, select the "Action" and press the "Select" button next to the "Action" property in the Properties View. Choose the "Login" action definition from the opening dialog. Press the "OK" button to confirm. In order to make the Action Definition work properly, it’s necessary to provide "Username" and "Password" to it, through the "Parameter Binding". Define the "Parameter Bindings" between the "Login Form" and the "Login" action by double-clicking on the "Flow" outgoing from the "Form" component, uncheck the "Enable Default Binding" property and bind the "Username" field with the "Username" parameter and the "Password" field with the "Password" parameter. Press the "OK" button to confirm.
Logout Pattern
The "Logout" is the operation that explicitly terminates the user's session. After the session is destroyed, the user loose the permissions to access the protected resources of the application. The "Logout" pattern can be modeled in different ways depending on the requirements. The basic pattern, which we show in this lesson, is to model the "Logout" action definition with a single operation, the "Logout" operation.
How to Model the "Logout" Action Definition
Let’s see how to model an "Action Definition" for the "Logout". As for the "Login" Action Definition, use the project shown in the lesson about "Access Control". Use the same "Module Definitions View" used for the "Login" action definition. Select the command "Action Definition" icon from the toolbar on the left and place the "Action Definition" inside the work area. Then type the desired name for that "Action Definition", for example "Logout". Double click on the "Logout" action definition to open it and start modeling its behavior. Now you have to add a "Logout" operation to the "Action Definition". Select the "Logout" operation from the "Session Components" section in the toolbar and click inside the work area.
To express the activation of the "Logout" operation, add an "OK Flow" from the "Input Port" to the "Logout" operation, by selecting the "OK Flow" icon from the "Flows" section of the toolbar and clicking on the "Input Port" and then on the "Logout" operation. As the "Logout" operation does not need to receive any parameter it’s not necessary to add parameters to the "Input Port". You need to set the operation to indicate which public site view you want to redirect the user to, after the logout has been performed. Select the "Logout" operation and move to the Properties View. Press the "Select" button next to the "Site View" property and choose a "Site View" in the opening dialog. Press the "OK" button to confirm.
Since the "Logout" operation uses the "Site View" property to redirect the user, it's not necessary to explicitly handle the "OK Flow". Add only one "KO Port" to the "Action Definition". Right-click on the workarea, open the "Add" menu, and select the "KO Port" command. Connect the "Logout" operation to the "KO Port" with a "KO Flow" by selecting the "KO Flow" icon from the "Flows" section of the toolbar and clicking on the "Logout" operation and then on the "KO Port".
How to Refer the "Logout" Action Definition
To exploit the "Action Definition" just constructed for the "Logout" basic pattern, go back to the IFML model presented in the lesson about "Access Control". As you can see there’s an action outside the "User Profile" page, that's need a reference to an "Action Definition". To make a reference from the Action to the "Logout" action definition, select the "Action" and press the "Select" button next to the "Action" property in the Properties View. Choose the "Logout" action definition from the opening dialog. Press the "OK" button to confirm.