This section applies to scenarios in which your client application is distributed and installed at your customer's premises. This can be a desktop or web app.
If your application can work in offline mode (usually desktop apps), even temporarily, then it is imperative to locally save license data, which is the content of the last successful heartbeat, in a .json file. The digital signature of this content/file should also be saved in order to prevent malicious manipulation of this data.
Saving this content, gives you flexibility in offline scenarios.
*Our NuGet package provides this functionality out of the box.
FREERIDE - FAILED HEARTBEATS
In the event of a failing heartbeat, you normally do not want to restrict software access immediately.
Instead, you should notify the user and ensure that the problem can be remedied (e.g., by going online), within a reasonable amount of time.
Freeride (an edition property) comes into play for such scenarios. Regardless of the failure reason, the freeride period allows the user to continue using the software and until it is finally locked. If a heartbeat succeeds during the freeride period, everything returns to its normal state.
Example: Let’s assume that you have set your license’s heartbeat period to 1 day, and the freeride period to 7 days. This means that the client is going to generate a heartbeat every 24 hours. If the heartbeat fails, the software continues to work normally for the following 7 days, during which a heartbeat must succeed for the cycle to be reset.
*Our NuGet package provides this freeride functionality out of the box.
It is paramount that secrets such as the ProvisioningKey or the EncryptionKey are securely saved within your application. Best practices concerning secret management vary depending on the operating system and/or programming language. However, some basic principles apply.
Embedding secrets directly in the application's source code should be avoided at all costs.
USING ENVIRONMENT VARIABLES
The most common approach to keep secrets out of the source code is to use environment variables. This is a very simple approach that should work for most server-based applications, which means if you have only one physical installation of your application, managed by you. If your application is installed on your end-customer's premises (e.g., classical desktop apps), this approach is not recommended, since they are stored unencrypted, and thus their values can still be accessed if your system is seriously compromised.