When I create an offline license and activate it, it counts toward my license activations in the server, which is ok.
When my application calls “DeactivateLicense” from LexActivator, the offline license activation in the server is being relased, but I can still work with mu offline license file.
Is this expected? Shouldn’t my offline activated license be freed only with the license deactivation request? And in case of “DeactivateLicense” is a safe way to always free an activation, shouldn’t it deactivate my Offline License file?
Hi @AugustoMartins,
Thank you for reaching out!
When an offline activation response file is generated, it consumes an activation on the server side. Later, if DeactivateLicense() is called, the activation is released.
However, the offline activation response file itself is not invalidated by DeactivateLicense(). It remains usable until its configured responseValidity period expires. These are intended to work independently in offline environments, and once issued, the server cannot directly revoke the already generated offline response file on the client machine.
We generally recommend configuring the responseValidity to a lowest practical duration for your use-case. This would help to minimize scenarios where a response file could again be used to activate a license offline.
Regarding your question about whether the activation should only be released using DeactivateLicense(), this function is designed to deactivate a license when an active internet connectivity is available. For completely offline environments, you can use the GenerateOfflineDeactivationRequest() to perform the deactivation workflow in an offline mode.
Thank you for the quick response as always!
What would stop a client from generating an offline license, activating it in the machine and then call the DeactivateLicense to free it in the server and then use two activations in a one activation license? The client will have my product_id and my product_data, they can simply create a Python script that call DeactivateLicense and keep using an offline license in the computer and create infinity others.
Our offline licenses must have long periods of validity, because the creation of the offline license is not user friendly, there are too many steps and some of our clients have lots of computers running our application offline, thus your solution to keep the responseValidity low would hurt our clients more than help us.
Shouldn’t “DeactivateLicense” only deactivate online licenses? From what I understand, offline activations should only be deactivated by offline deactivation file request or manually by my company.
Could you please let us know whether allowing a single use of the offline activation response file would address your requirement, regardless of the configured responseValidity duration?
The client can activate and deactivate his offline license as he pleases, ideally for him, the offline license will be valid for as long as he does not deactivate it himself or the license contract expires. And we do not want them to be able to deactivate an offline activation without the offline deactivation request file or through asking directly to us.
I do not know if this answers your question, I also do not think I understood it well. Hopefully the description above helps.
Hey @AugustoMartins,
In my earlier correspondence, I was referring to the offline activation response file, which is generated against the offline activation request file on the Cryptlex server side. The generated response file is then used to activate the license offline in the client application as part of the offline activation workflow. My earlier question was whether you wanted to restrict that response file to a single use only. In other words, if you want to invalidate the response file right away after it’s used for activation, preventing it from being used again.
Regarding your another question, you can simplify the workflow you are looking for by handling online and offline deactivation separately in your application using GetActivationMode().
For example:
- If
GetActivationMode() returns the initial/current activation mode as online , allow DeactivateLicense()
- If
GetActivationMode() returns the initial activation mode as offline , allow GenerateOfflineDeactivationRequest() and not the DeactivateLicense()
Ok, I think I understand your question now.
I do not mind the activation response to be used multiple times in the machine it was generated for.
Regarding your last example, this is what I we are doing now, but our client can download Cryptlex Python LexActivator lib and create a script to just call DeactivateLicense and they will have a valid offline license file and a free activation on the server.
You can reduce the responseValidity period for the offline activation response file to limit the time window during which the file can be reused. This would help to reduce the risk of the same response file being reused multiple times before it expires.
Alternatively, we can consider introducing a feature enhancement that would invalidate the offline activation response file after a single successful use. This would help ensure that once the response file has been consumed for activation on a machine, it cannot be reused again on the same machine, which would address the concern you raised regarding repeated usage of the same offline activation response file.
Why not just block the user from deactivating an offline activation using the DeactivateLicense method?
On your solution, the client can just generate the offline license file and then create a simple Python script that connects to the account and then call DeactivateLicense. They will have 0 activations and a valid offline license file that has never been activated.
How about if the activation response file can only be consumed once? In that case, even if DeactivateLicense() is called later, the same offline activation response file would no longer be usable to reactivate the application again.
Additionally, you can also control the allowedDeactivations value for a license. For example, setting it to 0 would mean that no deactivations are allowed for that license, or you can configure it according to your specific requirements and workflow.
Here is the scenario that I could reproduce:
- Generate offline license request file
- Activate the license with the request file
- Download the license file
- Activate the license with username and password not using the file (the license file is not used)
- Call “DeactivateLicense”
- The activations will all be cleared
- Activate the license WITH the file now.
Results: No activation on the server and the offline license active in the machine.
What you propose does not solve this case.
Our licenses must have the option to activate and deactivate multiple times.
Step 4 and 5 could still be performed using a separate script that deactivates the license offline. Because of this, enforcing only online → online deactivation and offline → offline deactivation would not provide any meaningful prevention for the scenario effectively.
For your use case, the more effective approaches are:
• Configuring allowedDeactivations for the license appropriately.
• Setting a serverSyncGracePeriod so that offline activations must be enforced to sync with the server, if your environment allows it.
We would also be interested to understand the reason behind exposing the productId and product.dat to end users, since these could instead be obfuscated within the application itself.
That said, we will still discuss this with our team and keep you updated.
The scenario I described is a scenario where the client can have a valid offline license active while having no activations on the server, meaning basically unlimited offline licenses. If the client follow the steps I listed, they will have a valid still not activated offline license on their computer which they can activate whenever they want AND still have a free license to be used elsewhere. I was not describing our use case, I described a potential issue with Cryptlex.
We are already aware of this and are working on measures to prevent such scenarios. However, the product.dat file and productId can be obfuscated rather than shared explicitly with users.
Thank you for your feedback. We truly appreciate it. If you need any additional help, please feel free to reach out to support@cryptlex.com.
