JasonI am re-engineering our license purchase system and the LimeLM API restriction to certain IP addresses is adding a great deal of work, more than double the work. Our websites are hosted on AWS EC2s using auto-scale, we have no way of knowing what their IP addresses will be or for how long. I continue to maintain that this restriction is unnecessary. That other users were calling the API from their apps has nothing to do with me.
The rationale for the change that happened 2 years ago is described in detail here: https://wyday.com/blog/2019/when-in-conflict-security-supersedes-usability/
Long story short: it's about accountability & security. It's not *just* about our customers calling the web API from their apps.
There are various ways to engineer your network layout so that you have static IPs even for "dynamically scaled" deployments. Google for the specifics.
JasonI am aware of ways to engineer around this limitation, as my post made perfectly clear. It still costs time and money to do it. I am also familiar with the search engine known as Google. I don't know why you think talking to your customers in this condescending manner is appropriate.
I'm sorry, I didn't intend to be condescending.
Short term: the API limitations will remain as-is.
Longer term: we'll add a very small amount of flexibility to the API usage (2 to 3 IP addresses allowed per time period vs. just a single IP address). No ETA on this (very low priority right now).
Either way you split it, this is something that must be engineered into your usage of the API. Yes, it adds costs (time / effort). We were aware of that when we made the change and we made it despite those increased costs for our customers.
Also, the upcoming release of LicenseChest will remove a lot of use-cases for the web API by providing a free portal for end-users.
