Upgrading the UI SDK from 1.0 as delivered with Airlock IAM 7.3 to UI SDK 2.0 as delivered IAM 7.4 requires some manual changes that are described below.
Those changes may be breaking for scripts or build pipelines that rely on the previous names and conventions. The change for instance.properties is breaking for every IAM instance < 7.4 using this key.
With Airlock IAM 7.4, the UI SDK ZIP artifact name, path, binary name and key in instance.properties have changed:
SDK 1.0 | SDK 2.0 | |
|---|---|---|
Artifact name and path | Name: Path: | Name: Path: |
Binary name |
|
|
Key in |
|
|
When unpacking the artifact for Airlock IAM 7.4, the content is unpacked into this directory: airlock-iam-loginapp-rest-ui-sdk
In Airlock IAM 7.3, the format of the i18n files (located here: src/assets/custom/i18n) was JSON whereas the new format in IAM 7.4 is properties.
en.json to en.properties .We use the content of en.json as an example.
en.json:
{
"authentication": {
"password": {
"title": {
"caption": "Welcome - Please Login"
}
}
}
}authentication.password.title.caption = Welcome - Please Login
Instead of migrating everything by hand, you can find JSON-to-properties converters on the internet that will help you with this transformation.
With Airlock IAM 7.4 dropping the support of Internet Explorer 11 (IE11) for the Loginapp REST UI, it is now possible to use JavaScript ES6 classes.
class and extends keywords instead of var and the extend() method when declaring a class.super() instead of init and this._super().super.methodName() instead of this._super().:function when declaring a class method. Also, the comma following the function declaration can be omitted.iam.api.types.CustomPage into two classes – one for customizing existing product pages iam.api.types.CustomProductPage and one for adding new pages entirely written in JavaScript iam.api.types.CustomJavaScriptPage.CustomPage.renderContentHtml to CustomPage.contentHtml .getPageId which is replaced by isApplicable. This provides more flexibility to customize the same page for different use-cases. If access to the current pageId of your customized page is required, the relevant page data received in the isApplicable({pageId, flowId, stepId}) method has to be stored as class fields.The following example shows a side-by-side comparison that illustrates the points mentioned above:
Example IAM 7.3 | Example IAM 7.4 |
|---|---|
var MyCustomLayout = iam.api.types.CustomLayout.extend({
headerHtml: function () {
return '...';
},
contentHtml: function () {
return '...';
},
footerHtml: function () {
return '...';
}
});
var MyCustomPage = iam.api.types.CustomPage.extend({
init: function () {
this._super();
...
},
getPageId: function () {
return 'mypage';
},
onPageEnter: function () {
console.log('entering: ' + this.getPageId());
this._super();
},
onPageExit: function () {
console.log('exiting: ' + this.getPageId());
},
renderContentHtml: function () {
return '...';
}
}); | class MyCustomLayout extends iam.api.types.CustomLayout {
headerHtml() {
return '...';
}
contentHtml() {
return '...';
}
footerHtml() {
return '...';
}
}
class MyCustomPage extends iam.api.types.CustomJavaScriptPage { // or iam.api.types.CustomProductPage depending on the use-case
constructor() {
super();
...
}
isApplicable({pageId, flowId, stepId}) {
return pageId === 'mypage';
}
onPageEnter() {
console.log('entering: mypage');
super.onPageEnter();
}
onPageExit() {
console.log('exiting: mypage');
}
contentHtml() { // Method renamed
return '...';
}
} |
In Airlock IAM 7.4, class iam.api.types.CustomLayout changed in its semantic. With IAM 7.3 inheriting from CustomLayout implied that, by default, IAM's product layout was used for header/footer/content except for explicitly overwritten methods. With IAM 7.4, inheriting from CustomLayout does not provide any layout at all.
Custom code that relied on this functionality must be updated to implement the missing methods.
In Airlock IAM 7.3, the content HTML was required to be a symmetric structure that was wrapped around the actual Loginapp REST UI content.
With IAM 7.4, it is no longer required for the content to be symmetric. However, the content must define the location where the actual content should be rendered to using HTML ID iamContentTargetContainer.
Example for IAM 7.3 | Example for IAM 7.4 |
|---|---|
var MyCustomLayout = iam.api.types.CustomLayout.extend({
contentHtml: function () {
return '<div></div>';
}
}); | class MyCustomLayout extends iam.api.types.CustomLayout {
contentHtml() {
return '<div id="iamContentTargetContainer"></div>';
}
} |
Custom CSS rules that relied on the old HTML structure have to be adjusted accordingly.
The sass files from src/sass/custom are no longer available. These are substituted by _custom-styles.scss and _custom-variables.scss, that can be used to customize the appearance of your application.
IAM 7.3 | IAM 7.4 | |
|---|---|---|
| _common-styles.scss _common-variables.scss _instance-styles.scss _instance-variables.scss | _custom-styles.scss _custom-variables.scss |
To preserve your customizations, copy the content of _common and _instance into the corresponding _custom file.
The following variables have been removed, since they did not have any effect: