Parent Project
Documentation
How-to
- Introduction
- Use-Cases
- Activity Graphs
- Controllers
- Custom Code
- Session Objects
- Security
- Calling the Back-End
- Tables
- Other Content
- I18n
- Tips & Tricks
Samples
Project Documentation
Adding security to your web application can be done very easily, although in a coarse-grain fashion: you cannot tell the cartridge to allow a specific person access to some page, you would rather express which groups of people have permission to access a specific use-case.
Again UML elegantly allows us to model this: just associate actors to your use-cases. When an actor is associated to a use-case it means that all users represented by that actor are allowed to call that use-case's actions: hyperlinks will be enabled and the server will allow access to the resources in the use-case's package.
When a user is not permitted access to a specific use-case he will find that the hyperlinks to that use-case are rendered in plain text, form buttons are grayed-out, and that the server will not authorize any access to the resources of that use-case.
To facilitate the modeling of the user groups using actors, these actors are allowed to generalize other actors, thereby explicitly inheriting the privileges of the parent actor.
Use-cases without any actors associated to them will always be accessible, the application will authorize anyone who requests access to them.
By default the cartridge generates client-side and server-side validation code. On the client side this is implemented using Javascript, rendered dynamically into the JSP pages by the <html:javascript ... /> struts tag.
The server-side code is perfectly equivalent to the validation on the client-side. Client-side validation is interesting because it can warn the user of errors without having to go to the server (which can take time and resources), server-side validation is a safety net that will guarantee input fields are present or properly formatted.
Client-side and/or server-side validation can be enabled or disabled using the clientValidation and serverValidation namespace properties respectively.
Different types of validation exist and depending on how you model your application different validation routines will be activated. For example, numeric input fields will be checked, email addresses will be checked for valid format, URLs must be well-formed, input needs to be in a certain range, creditcard numbers must pass the Luhn check, .. even regular expressions can be matched.
Check the table at the bottom of the Profile page to learn what's possible. Please note that more than one validator tagged value can be added to an event parameter.
Adding your own validator is simple, you can specify the validator's name so it will be checked if you just make sure your validator has been added to the validator-rules.xml file. To do this make use of the <!-- validator-rules merge-point --> merge point.
If you have enabled security the web.xml descriptor will contain sections describing the security on the level of each individual use-case, the use-case and actor relationships shown in the diagram above would yield output like this:
And the section describing the roles:
Please note that you would usually not model the Login use-case, except in those cases you need very specific functionality that cannot be handled easily using the default JAAS framework.
A login page will always be generated automatically, but this time it will be presented to you when you are trying to access one of the application's resources, this might be an action, an image, a JSP or anything else which it will try to locate within the application's path.
 |
(Larger View)
This screenshot is taken from the online-store sample, although security has not been enabled by default you can always access the login page by simply appending /login/login-form.jsp to the context-path, like this: http://www.andromda.org:8080/OnlineStore/login/login-form.jsp. |
Next section: Calling back-end services.
