As you grow your product offering, a challenge that can arise is how to differentiate between different products, and, at the same time, offer a seamless experience to your customers. We will present two approaches that can be used in Cryptolens and outline best practises when implementing license key verification in a product with multiple modules.
Using one license for multiple products
With this approach, the information about your products/modules is stored within one license key. In other words, you would just need to create one product in the Cryptolens dashboard. To differentiate between your products, you could either use the pre-defined features (F1 to F8) or define a more detailed feature hierarchy using feature templates.
This approach tends to work in most cases. However, in some cases it is still more desirable to be able to issue separate license keys for each product or module. We will describe this approach in the next section.
Separate license key per product bundled in a master license
If the previous approach is not an option, another way is to create one Cryptolens product per product/module. Typically the reason why this approach is more desirable is that it allows you to have separate trials or subscriptions attached to each license. For example, let’s suppose you have a product that offers additional features that are not part of the main product. By using a separate license key for the additional features or sub-products, you could allow your clients to test them out independently.
However, this approach would mean that your customers will need to keep track of multiple licenses at once. To solve this, we recently released an update to the API and the customer object. From now on, assuming that licenses are linked to the same customer, they can be retrieved using one API call using the customer secret.
Best practises when a product consists of independent modules
When a product is split up into independent modules, calling Key.Activate (a method used to verify a license with the server) each time a module starts is not optimal in most cases. Instead, a better approach is to verify the license with the server once at startup and then save the License Key object to file. Before another module is launched, it can check for existence of such file (and ensure that it is not too old) and then use it instead of calling the server. When it comes to obfuscation, it is more important to focus on obfuscating the method that loads the License Key object then the code that obtains the License Key object from the server.
If you have any questions, please feel free to reach out to us at [email protected].