There are situations where we want to modify the behavior of the CAS and for this purpose the code of the CAS has to be adapted or be overwritten. While much of the CAS behavior can be controlled via properties, not all of it can. In this article will describe with practical examples, how the behavior of the CAS can be modified by adapting the source code. source code can be modified.
CAS itself is open source. The source code of CAS can be found on Github: https://github.com/apereo/cas/ . The modifications are only made in our CAS repository - no changes are made to the original CAS code. In addition, "overwriting" means here, the extension of Java classes, in which individual methods are then methods are overwritten, as well as the adaptation of texts by using certain properties.
The places to be adapted and to be overwritten must be found independently in the CAS code. For the search can e.g. error messages, display texts or log outputs can be helpful for the search.
The 1st example is about customizing an error message for the password reset function. This functionality works in such a way that a user has to enter his username and then gets an e-mail with a link to change his password.
The behavior of the CAS is that an error message is displayed if the username entered does not exist in the system. This is helpful for the user - e.g. if he has mistyped his password - but at the same time it bears the risk that existing and non-existing usernames can be determined in the system.
The behavior has been adjusted so that no error message appears if the username does not exist in the system. The notification text that an e-mail has been sent has also been extended to include a note. In This note states that the e-mail has only been sent if the user actually exists in the system.
The changes have been made as part of Issue #161: https://github.com/cloudogu/cas/issues/161 .
In order to be able to override the CAS code, it is necessary for the compilation to include all the required
dependencies are included. Dependencies are included in the
build.gradle data. For this example the CAS
cas-server-support-pm-webflow had to be included.
These dependencies had to be included because classes from these dependencies are used in the overridden source code.
At the core of this feature are the classes
CesSendPasswordInstructions extends the original class from CAS and overwrites the corresponding
method - in this case the method
doExecute. Practically the original CAS code can be copied here first and then adapt
it accordingly. In order to avoid duplicated code, if possible, not the entire method should be copied, but the super
method should be used and called.
In the class
PmConfiguration the bean is created. Also here the code is copied for the most part. Only here
instead of an instance of
SendPasswordInstructions an instance of our own class
So that the creation of the bean in the class
PmConfiguration is also attracted, this class must be created in the
For classes that extend a CAS class, it is a good naming convention to put
Ces at the beginning of the class name.
at the beginning of the class name. This way the extended and customized classes can be identified quickly.
To test the customized code, the beans can be mocked.
It becomes a bit more difficult if the method to be tested, calls a more complex super method. For this case there is a workaround. The class, in which the method to be tested is, is extended for the overwritten test and the called super method is overwritten. The overridden method simply returns a certain value.
An example of this can be found in the class
The texts at the interface of the CAS are stored for the respective language as properties in a
To be able to customize and extend the message text of a sent e-mail, the corresponding text properties must be adapted to German and English.
The corresponding property key for the hint test is
screen.pm.reset.sentInstructions. To override the text for this
you have to edit the properties files
custom_messages_en.properties in the
src/main/resources and store the corresponding text as value.
For the German texts, make sure that umlauts are specified in encoded form, e.g.
\u00FC for an
After adjusting the text - the text has now become longer - check whether it is still displayed sensibly in the interface. This is the case in this example. If this is not the case, changes would still have to be made to the corresponding Thymeleaf template or the HTML fragment.
When creating integration tests, it is useful to store a unique Data-TestID in the HTML elements. Using this ID, the integration test can then uniquely access an element and no adjustments need to be made to the integration test. This way, no adjustments have to be made to the integration tests if something else changes in the HTML element.