The wyDay blog is where you find all the latest news and tips about our existing products and new products to come.
We’re proud to announce that we’ve made it possible to sell your app on a per-process-instance basis. Meaning you can directly limit how many instances of your app your customers can run at any one time.
It’s available now for all LimeLM customers!
This new per-instance lease issuance is the alternative to the per-user-session leases that TurboFloat Server issued by default. The differences between the two is shown in the gif above as well as described in “Fine-grained control: per-instance vs. per-user session leases“:
With the release of TurboFloat 4.1 we added the ability to issue leases either on a per-process-instance basis or a per-user session basis. This gives you more control over how you sell your software and how it’s used by your customers.
For per-user-session leases, one lease is issued per-user session on a machine (real or virtual) that is using at least one instance of your app. For example, “Sally Doe” starting your app on a shared server will be able to start multiple instances of your app and it will use that one lease regardless of how many instances they start in that user-session on that machine.
For per-process-instance leases, one lease is issued for every instance of your app started. Every separate process-instance of your app started will request a license lease whether the separate instances are in the same user-session or are in multiple different user-sessions.
So, how do you use it? Simple: first, make sure you’re using the latest version of the TurboFloat Server and TurboFloat library (get them on your API page). Then create a new TurboFloat Server key (or edit an existing one) and select the “per-process-instance leases” option.
That’s it. We handle the rest. Easy-peasy, lemon (lime?) squeezy.
TurboActivate and TurboFloat 4.1 are now out! This release is a huge leap forward in quality and features and sets the foundation for the new product releases that will be rolled out over the next 2 months.
So, wait no longer: get the latest TurboActivate and TurboFloat on your API page.
If you’re not already a LimeLM customer, sign up now for free!
Here are the big “marquee” features of this release:
Learn more over in our “Using TurboActivate with NodeJS or Electron” article (for hardware-locked licensing) and our “Using TurboFloat with NodeJS or Electron” article (for floating licensing). These articles and the accompanying example apps will show you everything you need to know to add true node-locked and floating licensing to your NodeJS app whether you’re on Windows, Linux, macOS, or FreeBSD.
Which brings us to our next big feature:
In addition to supporting the “big 3” operating systems (Windows, macOS, and Linux) with this 4.1 release we’ve added support for FreeBSD! All of our products now run natively on FreeBSD 10.x and above (no Linux compatibility layer necessary).
You can download the latest versions on your API page in LimeLM.
Prior to this release of TurboFloat Server version 4.1, the TurboFloat Library and TurboFloat Server only “talked” over encrypted raw binary. This was perfectly fine when the TurboFloat Server was behind a corporate firewall and all of the “clients” existed in the same network.
Things got trickier when a corporate end-user decided to host their TurboFloat Server on a public facing computer and their employees ran your app from different networks. If they had a “direct” connection to the server running the TFS instance (whether on the same network or through a VPN), then everything worked fine. But things are rarely so easy in a corporation. Inevitably communications would need to go through a labyrinth of proxies. And, unfortunately, proxies rarely support “raw” transmitted data.
The solution is letting your app (using the TurboFloat Library) talk to the TurboFloat Server over HTTPS. Read more about how to do it here: Configuring TurboFloat Server for HTTPS communication.
Now corporate clients with complicated proxy setups (or anyone else) can have all of the communication happen over HTTPS.
We’re also excited to add improved client-side date/time fraud to the timed-trials functionality in TurboActivate. We improve client-side fraud detection with every release of TurboActivate, but this version took a leap forward.
Additionally, we’ve added a new function “
TA_SetTrialCallback()“ that gives you real-time notifications of trial expirations and fraud. This means there’s no more need to “poll” TurboActivate functions for the life-time of your process. Just, call that function once, and let TurboActivate handle it.
Prior to this 4.1 release we made the following ARM builds of our products:
armv4t, 32-bit little-endian, soft-float
armv7-a, 32-bit little-endian, soft-float
aarch64, 64-bit little-endian, soft-float
But we’ve found this doesn’t match the use-case for most of our customers on these platforms, so we’ve added “hard-float” version for everything other than the armv4t target, and we’ve added an armv8-a, 32-bit build. So, here’s our new targets:
armv4t, 32-bit little-endian, soft-float
armv7-a, 32-bit little-endian, hard-float
armv8-a, 32-bit little-endian, hard-float
aarch64, 64-bit little-endian, hard-float
What this means in practice is that you can sell your app and target distros like Raspian (and all other popular arm-based distros) without having to re-target your app for “soft-float” support.
In addition to the big features listed here, we have a ton of quality improvements and tweaks to provide a better experience for all end-users. Read a condensed list of changes here for TurboActivate and the changes for TurboFloat.
Roughly a year ago we made a change to how the LimeLM web API functioned. We changed the behavior from allowing API calls to originate from any device anywhere in the world, to only allow 1 device to use an API key. We did this for security reasons, which I’ll explain in-depth in a moment. But the side-effect was that this made our web API harder to use.
And we didn’t make this change blindly. We knew that this change would both increase our customer’s data security but it would do it at the expense of their ability to easily use our API.
Naturally, this caused outrage among some of our customers. Both because we made this change and because we made the change rapidly (over the course of about 2 weeks with short notice).
LimeLM is our software licensing product. Companies integrate our components and libraries into their software so they can sell their software accurately to their end-customers. After a company integrates our components into their software, the typical workflow looks something like this:
An end-customer buys the software from the company.
The company sends them a product key.
The end-customer activates the software to that device using that product key. (Locking it to the device).
None of those steps requires using the LimeLM web API, but you could use the web API in step 2 to automate the product key generation.
Needless to say, many customers outright ignored this advice. Some were just careless with their API key and included them in public repositories and scripts accessible from outside their companies. Some just deliberately ignored our advice and embedded their web API key directly inside their apps that they gave to their customers. Thereby giving everyone with access to their app-binary access to their LimeLM account.
The proverbial straw that broke the camel’s back for this whole situation was when we saw unusually high web API usage from a particular web API key. It turns out this customer (a large software company) had embedded their web API key directly in their app. We investigated the abnormal API key-usage and saw that the key was being used from all over the world. It didn’t look like this customer’s data was being leaked, but there was so much noise in the data that we could not tell.
We immediately told them what we saw, re-iterated that a web API key should never be embedded inside code that runs on the end-user’s computer, and we invalidated that API key.
Then we kept digging. And over a short period of time we saw some of our other customers making the same mistake. We notified them as well, blocked those API keys, and quickly implemented a 1-ip address per API key rule. And that’s where we’ve been for the past year or so.
In the near future (after we get out some higher-priority releases) we’re going to make the web API key usage slightly more flexible. Namely, we’ll allow an API key to be used from 3 to 4 IP addresses in the period of 72 hours. Meaning if you have a small pool of servers that uses static IP addresses this upcoming change will make things easier for you.
In the meantime these customers can create a new user (and thus new web API key) for every separate static IP address they need to use.
We will never allow more than a handful of IP addresses to use any single web API key. Some have requested we enable a range of IPs that include whole services (e.g. AWS). We will never do that. All modern services offer static IP addresses for all of their services. Even so-called “serverless” (🙄) servers (like AWS lambda or Azure cloud functions) have options to use static IP addresses. Google the particulars for your web-host of choice.
In the coming months we’ll make a few separate product announcements that will eliminate the need for most common web API calls in the first place. Thus eliminating these problems (and the need for separate servers) altogether. These solutions will be rolled out gradually.
Why do we bother implementing any limit at all? It pisses-off some of our customers and it scares away other customers. The reason we do it is simple: we’re responsible for your customers’ data. Yes, these people are not our customers. But their data is in our servers and we need to ensure that that data is only transmitted to trusted end-points. By limiting API calls from a select number of IP addresses this forces you, as our customer, to consider your customers’ data safety and to properly implement data collection and transmittal.
Or, to put it another way: we actually take security seriously. So rather than implementing terrible security and writing a tepid PR-apology when data leaks, we’re proactive and go out of our way to ensure data doesn’t leak. It’s hard work and it sometimes requires usability trade-offs, but it’s what a serious software company should do. Namely, take data security seriously in the first place.
It’s not a perfect solution, but it’s a better solution than telling our customers to do things correctly (and hope & pray they do). How do we know? Because we tried that and a large number of our customers ignored us.
If you have questions, comments, or complaints about this policy shift, then feel free to comment down below.
– Wyatt O’Day
Founder & CEO of wyDay