I am not sure if this ActivateTrial() call is supposed to be, I thought calling the ActivateTrial() on the same machine, as long as the hardware has not been changed, should not start a new trial what’s so ever.
Here is a screenshot from the dashboard that shows my same machine starting a new trial.
My initial intent is to try to extend the first trial from the dashboard, and at the user end it calls ActivateTrial() to get an updated expiration date. If the ActivateTrial() isn’t what I should call it, then what is the right way to get the new updated expiration date on the user’s machine?
I guess what is not clear to me is how ActivateTrial() determines if it is on an existing machine or a new machine. Calling ActivateTrial() within a couple of hours in the morning seems doesn’t create a new trial, but when I tried to call it again in the afternoon, it adds a new trial with a different trial ID. I think this might be a bug.
There is a limitation in trials related to fingerprint matching. On the client, it honours the fingerprinting strategy (fuzzy, exact etc.) but on the server side, the match is always exact in case of trials. So a small change in hardware config can result in a new trial activation. We will try to improve this behaviour in future.
I am writing to inquire if there is any update on the timeline for the resolution of the reported issue. This functionality would be incredibly beneficial for my work.
We want to add a feature to our product that allows us to extend the trial period. To ensure the client-side application receives information about the extension, we need to obtain the latest trial data. According to a suggestion on the forum: Cryptlex forum - Reset Verified Trial remotely, the only solution is to create a mechanism that periodically calls the ActivateTrial() function to fetch the current data.
Thanks @AneesKhan for your help, and since this issue has been there for about 2 years and I do understand there might be some difficulties of fixing the root problem. Is it possible to provide us a guidance of a get-around workflow on how to get the trial extension on the user side?
Currently, if the trial period is extended from the admin portal, the only way for the client application to fetch the updated trial details is to call ActivateTrial(). However, as trials use exact fingerprint matching on the server side, any small change in hardware could cause the server to treat it as a different machine and create a new trial activation instead of updating the existing one.
We completely understand this is not ideal for your workflow, but the good news is that in v5, we are introducing a separate function that will allow the client to just update the trial activation details (such as the extended expiry).
Until then, the workaround is:
If the fingerprint remains identical, calling ActivateTrial() will reflect the updated expiration date.
If the fingerprint differs, unfortunately, it will trigger a new trial activation for now.
We’ll keep you posted as soon as the new function is available!
Thank you again for your continued patience and understanding!
This is good news, is there a rough timeline when the v5 will be ready? It would be great to know so that we could align our new version release timeline with your v5, otherwise it would be extremely hard to get our clients’ IT department constantly updates our versions.
Yes, I noticed that in my dev tests, ActivateTrial() would sometime reactivate a new trial in the next day on the same machine, and I am not sure how the fingerprint is determined. It seems a bit of unreliable, and I don’t think we could ActivateTrial() for updating the updated expiration date, which could potentially provide a way for a user to use the trial unlimited.
Please do keep us posted with the new v5, and thanks again for your help.
Yes, I noticed that in my dev tests, ActivateTrial() would sometime reactivate a new trial in the next day on the same machine, and I am not sure how the fingerprint is determined.
As informed above, trials use exact fingerprint matching on the server side, any small change in hardware details could cause the server to treat it as a different machine. So, calling ActivateTrial() will create a new trial activation instead of updating an existing one if there is any change in the hardware.
is there a rough timeline when the v5 will be ready?
While we don’t have any timeline at the moment, but it’s on our roadmap and planned for future implementation. We’ll be sure to keep you updated here. Thank you for your understanding.
