Subscription-based licensing and offline activationAnswered

I'm implementing annual subscription licensing for my product using this documentation:

https://wyday.com/limelm/help/saas-and-time-limited-licensing/

Based on that doc it sounds like my app should call my own service to ask whether the license key is active or expired. In turn, my service should call the LimeLM API to query the custom expiration date field for that license key and verify its relationship with the current date. I have things working exactly that way now.

So here's my question: How should this work for customers with restrictive networks who require offline activation? These customers' machines can't currently talk to https://wyday.com, hence the need for offline activation, and they won't be able to talk to my service endpoint to check active subscription compliance either. How, then, should I enforce subscription compliance?

I can perform a standard offline activation to get the license activated, but that doesn't provide the client anything about the expiration since that's in a custom field. Am I supposed to create an overarching offline activation process/document that also includes capturing expiration information for use on the client? If so it seems like it's then subject to issues like date spoofing and such that are avoided when the server performs the check.

Hopefully I'm just missing or misunderstanding something here. Apologies if so...

Thanks in advance for any guidance on this!

Answer

That's one way to do it. Another way is described here: https://wyday.com/limelm/help/license-features/#saas

>> "So here's my question: How should this work for customers with restrictive networks who require offline activation?"

Yes, custom license fields can be read from your app using the TA_GetFeatureValue() function without needing an online connection.

And use the TA_IsDateValid() function to verify if the subscription has expired.

The rest of the custom license fields article covers how to handle renewals, etc. Long story short: customers who offline activate will be fine.

Let me know if that all makes sense.

Thanks, Wyatt! Let me take a look at all of that and hopefully it will just fall properly into place. What you've described sounds like exactly what I'd hope to find, though. Much appreciated!

Works wonderfully, Wyatt! Thanks so much and nice work!

One more question on the behavior of this, Wyatt. When the current subscription is just about expired, the payment processor will automatically attempt to renew it unless the customer has explicitly canceled the subscription. That will trigger a callout which will be used to change the expiration date custom field value as appropriate for the renewed subscription. Will TA_IsDateValid(TA_GetFeatureValue(), ...) for that expiration date custom field automatically read through to the servers to check validity again, or is there something I need to do to force a read-through. I would hate for the customer to have just paid for a renewal and then have the app tell the user that it thinks the subscription has expired.

Please let me know if my question doesn't make sense.

Thanks again!

Hey Scott,

TA_GetFeatureValue() is always read-only. It never contacts the activation servers.

The step describes how to get the latest value: https://wyday.com/limelm/help/license-features/#change-field-read-new

And this step describes how to gracefully handle expired subscriptions (short answer: don't just kill your app -- instead use it as an opportunity to up-sell on the spot): https://wyday.com/limelm/help/license-features/#change-datetime-handle-expired

Does that make sense?

Yeah, that makes sense, Wyatt. So basically my takeaway is that when I detect that the subscription is expired based on the information cached in the client activation, I might first try to re-check with the server to see if there's a new value for that field. If so and that results in a good subscription state, the user is none the wiser. If not, I can give the user some guidance on how to renew/extend the subscription (or in the case of my digital storefront, most likely fix whatever issue has resulted in a lack of auto-renewal).

Please let me know if I've misunderstood or misinterpreted.

Thanks yet again!

>> " I might first try to re-check with the server to see if there's a new value for that field. If so and that results in a good subscription state, the user is none the wiser. If not, I can give the user some guidance on how to renew/extend the subscription (or in the case of my digital storefront, most likely fix whatever issue has resulted in a lack of auto-renewal)."

Yep, that's the best way to handle things.

Reply
Discard post