View Issue Details

IDProjectCategoryView StatusLast Update
0003452Ham Radio DeluxeMaintenancepublic2019-11-08 02:32
ReporterWA9PIEAssigned ToWA9PIE 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.7.0.244 
Summary0003452: Change/improve the way keys bind to the software
DescriptionProblem 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 ReproduceBuild 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
TagsNo tags attached.
ModuleSW License Mgmt
Sub-ModuleSW License Client
Testing Beta Successful

Activities

DOUG

2019-09-23 23:21

developer   ~0008621

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.

g3ucq

2019-11-06 04:06

viewer   ~0009155

Unable to test

WA9PIE

2019-11-06 16:33

administrator   ~0009184

I tested this. I think the approach will satisfy the requirement.

Issue History

Date Modified Username Field Change
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 => 6.7.0.239
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 6.7.0.239 => 6.7.0.244
2019-11-08 02:32 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe