View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003452||Ham Radio Deluxe||Maintenance||public||2019-09-22 12:22||2019-11-08 02:32|
|Target Version||Fixed in Version||22.214.171.124|
|Summary||0003452: Change/improve the way keys bind to the software|
|Description||Problem statement - when a user attempts to activate the software on a machine with a "Computer ID" (ComputerName) that already exists in QLM (registered to another customer), the system prevents them from activating the software. It gives them an error message that says something like "the machine has already been activated." Well, customers believe they're being told that the software has already been activated on THEIR machine (which it hasn't). They get frustrated. Eventually, they contact us and we ask them to change their "Computer ID" (machine name, ComputerName, whatever) and they (a) have no idea what/how and (b) they reasonably don't believe it's necessary (they see this as OUR problem; and it is).|
We originally made the decision to bind the keys to the computer. The was implemented by binding the key to the ComputerName. (I guess I thought that was ComputerName per email address.) What's happening is that we're seeing lots of people (all over the world), who have the exact same ComputerName (things like "My-PC", "PC", "HOME-PC"... and so on.)
About a month after we put this into production, in order to attempt to enforce the number of trials that a user could do, we changed the parameter in QLM to where a unique computer could have only one install. Prior to that, you would see many entries in the database for the same Computer ID. After that change, the problem began. But it's imperative that folks cannot game the system and get multiple trials (a point that is not entirely resolved yet.
Tim talked to someone at Soraco (probably John) who send him this link and suggested using "QlmUniqueSystemIdentifier1." It looks like binding to this - rather than ComputerName - attempts to bind the beginning with the most likely unique... to the least likely unique. As it turns out, we decided to bind to the least likely unique characteristic. I like this idea. Not only will it solve the existing problem, but it will likely improve our ability to lock-down trial keys also.
Soraco provided the following link to Tim - https://support.soraco.co/hc/en-us/articles/360001183583-QlmLicense-LicenseBinding
|Steps To Reproduce||Build a machine called "PC" (which already exists in QLM with a different customer's key).|
Attempt to activate a valid key on that machine; observe the error
Change the computer's "Computer ID"
Attempt to activate a valid key on that machine; observe that there is no error
|Tags||No tags attached.|
|Module||SW License Mgmt|
|Sub-Module||SW License Client|
More details upon testing, this "unique" compuer ID policy with QLM is ONLY on trial keys
I switched QLM from binding on computer name, to this QLM unique id
It is a easy to change for new users. However the toothpaste is already out of the tube for the existing activated keys, because they are already use the "computer name" as the id in the QLM database.
I coded up a workaround as follows
Case for a new 6.7+ user
Code now uses a real "computerid"
License will only validate properly in the future if the computer id continues to match
Case for an existing 6.6 user on a previously validated machine...
Attempts to validate with the computerid
When this fails, it tries to validate with "computer name" (this should normally pass, but if this fails, the overall license check will fail and require user to re-license)
If it passes (and offline) then it allows the user to use the software
If it passes (and online) then it deactivates this users license using the "activation key" and "computer name"
After deactivate it immediately reactivates using the "computer id" (all of this is done in background)
If we push this to next release our test cases should include
New unlicensed using latest release user on VM
New unlicensed latest release user on PC
first run of a previously licensed 6.6 user that upgraded to latest release (online)
first run of a previously licensed 6.6 user that upgraded to latest release (offline)
Known probably low-risk problem: Any user that licenses on latest release, and then goes back to 6.6 on that machine, will fail their license validation.
checked in in changeset 5161
I haven't built this yet, I will like WA9PIE decide when we want to do that.
||Unable to test|
||I tested this. I think the approach will satisfy the requirement.|
|2019-09-22 12:22||WA9PIE||New Issue|
|2019-09-22 12:22||WA9PIE||Status||new => assigned|
|2019-09-22 12:22||WA9PIE||Assigned To||=> WA9PIE|
|2019-09-22 12:37||WA9PIE||Assigned To||WA9PIE => DOUG|
|2019-09-22 12:37||WA9PIE||Description Updated||View Revisions|
|2019-09-22 12:37||WA9PIE||Steps to Reproduce Updated||View Revisions|
|2019-09-22 12:37||WA9PIE||Module||(select) => SW License Mgmt|
|2019-09-22 12:37||WA9PIE||Sub-Module||(select) => SW License Client|
|2019-09-22 14:15||WA9PIE||Description Updated||View Revisions|
|2019-09-23 23:21||DOUG||Assigned To||DOUG => WA9PIE|
|2019-09-23 23:21||DOUG||Status||assigned => resolved|
|2019-09-23 23:21||DOUG||Resolution||open => fixed|
|2019-09-23 23:21||DOUG||Note Added: 0008621|
|2019-10-29 15:52||K7ZCZ||Fixed in Version||=> 126.96.36.199|
|2019-11-06 04:06||g3ucq||Note Added: 0009155|
|2019-11-06 16:33||WA9PIE||Status||resolved => closed|
|2019-11-06 16:33||WA9PIE||Testing||Not Started => Beta Successful|
|2019-11-06 16:33||WA9PIE||Note Added: 0009184|
|2019-11-08 02:10||WA9PIE||Fixed in Version||188.8.131.52 => 184.108.40.206|
|2019-11-08 02:32||WA9PIE||Project||3 - Current Dev List => Ham Radio Deluxe|