Version 20.11
The new November 2020 Release of ApiOmat features the beta version of our Microservice Generation Feature, authentication with JWT, besides additional changes. See below for further information on these topics.
Note that this is the second version with the changed versioning scheme. As of this version, we will provide larger releases every four months, which will contain a set of the different software parts in different versions.
The ApiOmat version 20.11 consists of the following versions of sub-components and services:
-
ApiOmat Yambas 3.6.0
-
ApiOmat Dashboard 3.6.0
-
ApiOmat Bouncer 1.0.0
-
ApiOmat Brewer 2.0.0
-
ApiOmat Dispatcher 1.6.0
-
ApiOmat Executor 1.1.0
-
ApiOmat Explorer 1.2.0
-
ApiOmat Gearhead 1.1.0
-
ApiOmat Innkeeper 2.0.0
-
ApiOmat Analytics 1.6.1
New Features
Microservices Generation
Generate Spring Boot Microservices in a simple way to bring your business logic into ApiOmat.
Generated microservices are following defined boundaries so that also developers with less experience can achieve results fast. Security audits can take place only one time.
With this release you are able to generate Spring boot microservices, deploy and execute them in your ApiOmat environment.
With services based on Spring boot you can fastly integrate your businesslogic and benefit from the large spring ecosystem.
Powerful, secure and efficient authentication with JWT
ApiOmat is shipped now with our new service called Bouncer for easier integration of third party authentication providers (Active Directory, LDAP, SSO, Mulitfactor Authentication) inside your application. Besides that we provied a stronger separation between Authentication and Authorization and using JWT now for secure authentication.
Clean Separation Between Authorization And Authentication
A major change in the ApiOmat 20.11 release is the clean separation between authentication and authorization.
In short, an authentication check is about checking whether the requesting user is the one, who he says that he is. While authorization checks whether the user has access to the requested resource.
In the past, we did not provide a clear separation between these two topics and changed it in the current release. We will explain in this section, what has changed, which implications this has and what advantages you get from this.
Previous versions checked the authentication altogether with the authorization at a central point. This lead to the situation that within one request the authentication has been checked multiple times, including multiple calls to the auth-method within a native module. Although there were some caching mechanisms that prevented multiple authentication checks, there were still some cases where, under special circumstances, these checks would still occur.
Since ApiOmat 20.11, the authentication is done directly and solely when the request comes in, before any other logic is executed. Therefore your auth method gets executed only once. If your module's auth-method contains authorization logic, you should move this logic parts to the isUserInRoles method and only keep the authentication logic in your auth-method.
The APIKey checks were also moved to the beginning execution of the request. Therefore this check gets only executed once and not within the execution of a native module.
For custom REST-Endpoints you'll still need to do the checks by yourself.
As a side effect a wrong APIKey as well as a model-request for a non-existing app will now consistently lead to a "API Key was not correct" exception ( status code 841 or 401 ) instead of a "Application was not found!" exception ( status code 801 or 404 ).
C# Embedded Documents Support
New C# SDK supports now ApiOmat Embedded Objects in all CRUD methods
Breaking changes
Breaking changes may require changes in configuration, apps, or native module code after an ApiOmat upgrade to ensure system stability.
|
Affects |
Change |
Implications |
|
Delete Parent Module Endpoint |
Instead of the need to send a payload to the delete parent module endpoint you now need to give the parentModuleName and parentModuleVersion to the path:
|
If you called the delete parent endpoints before you need to switch to the new one. |
|
Swift SDK, |
The Swift SDK has been adapted to work with Objective-C code:
|
Classes in base modules such as Basics, Push, Facebook etc. are prefixed with AOM, e.g. AOMUser, because Objective-C does not have name-spacing. If you used a String attribute named "description", it will be generated as a method because "description" is used as a property name in NSObject. |
|
Objective-C SDK, |
The following SDKs ran out of deprecation and were removed from ApiOmat:
|
Those specific SDKs cannot be generated anymore with YAMBAS version 3.6.0 and higher. Please use the following replacements instead:
|
|
Google Analytics, Restore Module, |
These static modules were removed from ApiOmat |
|
|
YAMBAS and Dashboard |
The Tomcat used for YAMBAS installation was updated to 8.5.60 . |
If you want to use the AJP Connector in your ApiOmat environment, you now need to set it up manually after installation. |
Remarkable changes
Remarkable changes do not affect system stability after ApiOmat upgrade, but may require changes in configuration, apps, or modules in the next development cycle.
|
Affects |
Change |
Implications |
|
OAuth2 tokens |
We have changed the hash function used to generate OAuth2 tokens, so any existing tokens will no longer work. Therefore, all existing tokens (including manually set tokens) will be deleted when upgrading from a previous version. |
After upgrading, generate new tokens for any Customers/Users that need them. |
|
Consul registration |
We have added a scheduled job to check if YAMBAS is (still) registered to Consul, and re-register it if not. This job is deactivated by default. You can activate it by setting a specific application property. Please note that this job does not work if you are using a Consul cluster, as YAMBAS may be registered in a different node. |
To activate the job, set the application property common.consul.health.registrationCheckInterval to a positive integer, which will be the job interval (e.g. a value of 5 means the job will be executed once every five minutes). |
|
Installations using usernames for Customers, Organizations and/or Users that only differ in case |
It is no longer possible to create Customers, Organizations or Users with usernames that are identical except for case, e.g. "Freddy" and "freddy" This is because Bouncer, our authentication microservice, cannot handle different casings. |
The minimum required MongoDB version has been raised from 3.2 to 3.4. Please upgrade if necessary. Customers and Organizations with usernames identical except for case may not be useable anymore. With Users, the change only automatically affects new applications. It does not affect existing applications unless all the data for the User class is deleted (via "Drop all data" or "Drop class data") in the Dashboard. |
Changelog
