proxy to licensing server?

>> "re-direct them to you and act as a MITM"

No.

If they're having internet problems follow this FAQ: https://wyday.com/limelm/help/faq/#internet-error

And always use the latest version of TurboActivate.

If the customer wants to use a proxy, we auto-detect the proxies on the machine. But you an also accept custom proxies: https://wyday.com/limelm/help/proxies-in-turboactivate/

Lastly, make sure your app is code-signed using EV certificates so that crummy anti-virus apps don't block your app (and, by extension, the TurboActivate library) from contacting outside end-points.

https://wyday.com/limelm/help/faq/#internet-error is really not written for end-users. It's incredibly confusing for them to follow this sort of thing.

The problem we have is that we don't know what your server receives from the client. Could you add an end point on your server that just returns whatever it receives? Then our app can log that for debug purposes so if the client is sending gibberish, we can see the gibberish that is being sent!

The FAQ boils down to this: Type https://wyday.com in Internet Explorer. Don't see the site? You're blocking things on your machine or your network.

Do see a site? Then something is blocking the app from contacting the servers. (because the *machine* can access the site using the default browser, therefore it follows that because the app can't talk to the site then something is blocking the app).

>> "It's incredibly confusing for them to follow this sort of thing."

It's meant as guidance for software companies to use and convey in short steps for their customers. It's not meant to be linked to from your app as a help document for end-users.

>> "Could you add an end point on your server that just returns whatever it receives?"

No. That would add a maintenance burden that would only help a very limited network mis-configuration case. Namely, if a customer is not *receiving* anything from wyday.com (or it's captured, manipulated, etc.) then chances are they cannot *send* anything to wyday.com.

(Actually what you're asking for has an even more limited use-case -- because to *receive* anything from wyday.com you have to make a request to -- i.e. *send data to* -- wyday.com)

So, our FAQ and standard debugging methods are sufficient.

Hi Wyatt,

The biggest issue is that we don't really want to tell customers about wyday.com at all - we want them to whitelist on their network the domain they understand they are doing business with - not yours.

This is a growing problem for us - over 50% of our support requests are todo with licensing issues not our actual product - being able to debug within product the sort of issue and give better error handling would save a lot of support.

We are about to hit your max plan pricing - so limelm is a reasonably expensive option for us - it's going to be hard to justify if we can't get some improvement here - the simplest for us would be proxying requests via our server before sending to wyday.com

I've just seen

"You can also run LimeLM on your own servers. LimeLM works with all major server software. Contact us if you want more information, pricing details, or you would like to order."

Perhaps this is the solution for us? Does this also let us run turbofloat server on our own server as well? This could be the solution for us perhaps?

Hey Chris,

You've asked several questions:

>> "The biggest issue is that we don't really want to tell customers about wyday.com at all - we want them to whitelist on their network the domain they understand they are doing business with - not yours."

Right, and I understand that. We go out of our way to make things "just work" and not require end-users know anything about us. This trend continues with the release last week (TA 4.1). It improves TurboActivate's ability to "just work" in more labyrinthine-proxy configurations used in corporate networks.

So, before doing anything else, use the latest version.

Next, for customers without the latest version of your app (with the latest version of TA included) have them upgrade before continuing to support them. Chasing down things that have already been solved isn't useful to anyone.

If customers are still having problems dig into the root cause of the problem. If they're blocking all outgoing connections except a limited whitelist, well, you have a couple of options:

1. Have them offline activate: https://wyday.com/limelm/help/offline-activation/

2. Have them whitelist "wyday.com" over port 443 (i.e. HTTPS connections to our activation servers)

3. Host LimeLM on your own servers and have them whitelist your domain name. (This is an expensive option -- more expensive than the Max plan -- but doable if you really want to "hide" wyDay's involvement).

1 and 2 are the best and cheapest options.

If the customer is having other problems (*and* they're using the latest version of TurboActivate), and you believe this problems to be genuine bugs, then report them with enough information so we can actually fix them: https://wyday.com/limelm/help/faq/#useful-reports

In short: tell us the exact function "failing", what "failure" means to you, the exact error code, the exact parameters passed.

Long story short: we provide a number of error codes, and that number increases with every release, so additional "blind" log dumping isn't useful to anyone (we would need to decode it anyway -- and thus provide error codes -- bringing us full circle)

>> "This is a growing problem for us - over 50% of our support requests are todo with licensing issues not our actual product - being able to debug within product the sort of issue and give better error handling would save a lot of support. "

You need to separate the legitimate issues from the cooked-up issues. For example a common cooked-up issue is saying "I replaced the hard drive on my computer but now the app isn't activated" -- what's typically happening in this case is they've installed your app on a second computer and want a free license.

Why? Because we handle all common "maintenance scenarios" with devices (replace RAM, hard-drives, GPU, etc., etc.)

So, I don't doubt a percentage of the "issues" customers are having is not wanting to buy another license for your app.

To sum up:

1. Use the latest TurboActivate (currently 4.1.3).

2. Provide full error reports if you believe TurboActivate is behaving incorrectly (see the FAQ for the information you need to provide).

Thanks for all the additional information.

Thanks Wydatt for all the detail here. We are sorting EV cert and will upgrade to latest version and I hope that helps.

>>>>>> 2. Have them whitelist "wyday.com" over port 443 (i.e. HTTPS connections to our activation servers)

Just wondering, is there a technical reason (or other?) why we can't just re-direct connections from our domain? i.e. we specific domain.com as a variable in the library and then we need some tiny bit of code to redirect requests back/forward to solve this. It would solve lots of problems.

>>> 1. Have them offline activate: https://wyday.com/limelm/help/offline-activation/

I am wondering if the alternative is to use offline in a messy way i.e. we automate this in product. So we tell them to whitelist domain.com - we then generate offline activation automatically - send it to our server, use your API to get the code, send it back to them - and they are activated "offline" and we only need to tell them to whitelist our domain. Thoughts?

Most of the issues are errors are connection fails (i.e. whitelist wyday) or things like https://wyday.com/limelm/help/faq/#disabled-adapters

>>> The FAQ boils down to this: Type https://wyday.com in Internet Explorer. Don't see the site? You're blocking things on your machine or your network.

Do see a site? Then something is blocking the app from contacting the servers. (because the *machine* can access the site using the default browser, therefore it follows that because the app can't talk to the site then something is blocking the app).

The problem is getting to the point where we have to tell the user to open up a browser they probably don't use, to open a website they have never heard of - is a *really* bad experience! So we want to be able to automate in-product discovery of any network issue that will cause licensing to fail. We can then tell them what to do. e.g. we can't reach wyday.com at all (do this) or we can reach wyday.com but the data we get back is being modified (do this) etc.

>> "The problem is getting to the point where we have to tell the user to open up a browser they probably don't use, to open a website they have never heard of - is a *really* bad experience!"

Right, well you don't have to do that. That's only if you want to show why the activation isn't working (i.e. the customer has a brain-dead configuration or they block all sites except a small whitelist).

Otherwise, just use the internet errors that TurboActivate returns: TA_E_INET, TA_E_INET_TIMEOUT, TA_E_INET_TLS

Beyond those errors, there's no magic way to find the root cause of a customer's configuration errors. There are literally hundreds of thousands of causes for a customer not being able to reach the activation servers. There's no magic bullet.

So, as stated above...

1. if you're using the latest TurboActivate2. ... and the customer is connected to the internet3. ... and the customer is getting a TA_E_INET* type error4. ... and you want to "hide" wyDay's involvement in your product5. ... and you want an immediate solution.6. Use offline activation: https://wyday.com/limelm/help/offline-activation/

If you want to actually solve what in the world the customer is doing to block their own access to the activation servers, then you need to actually dig into the cause. There's no magic bullet.