L I C E N S I N G
as their name , age , address , shoe size etc .: Anything you want to have recorded , with only the EU GDPR regulations limiting your flexibility . The API offers an option to change or delete these entries to be fully GDPR-compliant .
The final and most interesting field is “ ticket ”. The License Portal can define whether a ticket from CodeMeter License Central should act as a Captcha to prevent automatic bots from creating countless spam accounts . Tickets have to be fresh by the time of registration , i . e . not yet been assigned to any other user or group . To make things easier , the ticket is automatically assigned to the user in question after the finished registration process . The captcha field can also be replaced with your own anti-spam mechanism or left out entirely .
The Session The “ register ” command should ideally get the user up and running immediately . It would return a “ sessionid ”, the “ mail ”, and a “ sesssiontoken ”, which are then used for later API calls .
The system also informs you whether the user has to confirm with a Double-Opt-In option . This can be configured for the License Portal and would require the user to confirm a code that they are sent by email . A separate API call is used for this purpose , and the process would not continue until the user has confirmed the code .
The same “ sessionid ”, “ mail ”, and “ sessiontoken ” values would naturally also be returned if you connect the user by a later “ login ” API process . “ logout ” is used to end the session .
Dummy Users One quite popular option is for user accounts to be created automatically without the actual user having to bother with the process . This is a valid choice , but should still be handled with care to make sure that the automatically created profile is compliant with the EU GDPR data protection standards .
To create such dummy accounts , a mail address is created from the internal user ID , such as a virtual mail address on your own server ; alternatively , the ticket ID could be used if users do not have an ID given to them .
A much more interesting question is the automatic creation of a password . Ideally , the system starting the registration process should be able to store a random value for each user , which could take the form of an entry in the user database , or some value on a local machine . This random value is defined , appended to the user ID , and hashed to get an automatic password .
Assigned Credential Files A separate API call is used to get the credential file , which needs the “ sessionid ”, “ sessiontoken ”, and “ mail ” from the user logging in .
The password also has to be included for this purpose . Asking users again for their passwords in this manner is a good means , albeit better used sparingly to avoid irritation , to protect important functions from unauthorized use . For the License Portal , it is technically required , since the credential file is encrypted with the password .
The name of the CmCloudContainer in question can be included in this first call . This would be the name that is visible to the user in Code- Meter ’ s Control Center . However often it is called , this refers to the same file , even if a new name is given . To refer to the CmCloud- Container the CmActID should use the standard fixed value “ 3000 ”, which is reserved for all future purposes .
When the Portal ’ s user admin features are used , the client should require the password again before this API call or calculate the value accordingly in the case of dummy accounts .
Changing Passwords A call to change the passwords needs the old and new passwords on top of the session parameters . Again , a simple precaution against accidental typos is asking the user to enter the new password twice .
This call invalidates the old credential file . When licenses in the CmCloudContainer are accessed next , they are flagged as “ red ” and cannot be used anymore . The user should then receive and import a new credential file with the new password .
Resetting Passwords The API is , naturally , also ready for the inevitable case that a user forgets their passwords . The process uses two specific calls : The first returns a reset token , which only needs the user ’ s email address and does not initiate any internal actions in the system . The reset token needs to be used in a time that you can set to your liking .
Usually , the token is sent to the email address stored in the system . It could alternatively be delivered via the API , but this calls for special attention to make sure that the API function in question can only be used by authorized applications .
The token then allows a new password to be created in a second call . This would invalidate the old credential file , which would have to be recreated and delivered with the new password .
Activating Licenses Licenses are activated in the same manner as they are on CmDongles or in CmActLicenses : A context file is created for the CmCloudContainer by the local copy of CodeMeter and used for activation via the standard Gateway function . The update file produced in return is then uploaded again via the local Code- Meter copy , and if CodeMeter is not installed locally because the system is arranged as a SaaS solution , the License Portal API can step in as the middle man to retrieve the context file and return the update file ( limited to CmCloudCIontainers ).
8