Activate Add-ons dialog can reset user codes

[Jim_Kring]

I noticed what I would consider a usability bug in the Activate Add-ons dialog.

If you don't enter an Activation Code (you leave the default values of "0") and press the Activate >> button.

You will get an invalide code error.

Then, when you click the << Back button, you'll see that the User Codes have changed!

The problem is that customers have send us the previous User Codes and are waiting for us to issue Activation Codes.  They want to close this dialog and enter the Activation Codes later, when they get them. They think that hitting the Activate >> ("Next") button will close the dialog (since that's the next step in their workflow).  This results in them having to resent us new User Codes, since the Activation Codes we generated from the old (now invalid) User Codes won't work!

My suggestion is to not attempt to activate if the values in the Activation Codes fields are "0" or empty, so that the User Codes don't get reset.  You could just disable the Activate >> button until at least one of the Activation Code fields is entered.

[Thoric]

Jim,

I've been playing with all this a lot recently, and came across this exact issue months ago. Whilst I agree with your suggestion above not to change these values when someone clicks Activate and there are no activation codes, I think that, when building your license file in SoftwareKey's LFEdit routine, setting a flag for "allow delayed trigger codes" affects the generation of these user codes and means that delayed activation will work. In other words, if a user closes this dialogue box after sending you the user codes, then you send them activation codes, these codes still work.

Again, I would need to test this again to be sure, but I know that I have this box checked and in one of my own test activations, I was able to activate the toolkit after closing and reopening the dialog.

[RDR]

We resolved the issue when canceling out of the dialog a few releases ago and no longer reset the codes every time, but as Jim points out we do reset the codes when a user attempts to enter invalid codes - this prevents the chance of a brute force attack on the licensing system.  BUT, there's really not a reason to allow users to enter 0 & 0 so I agree with Jim on this one and we'll file a CAR on the issue to see what our R&D team can do about it.

Good call on the "allow for delayed trigger codes", this may be a viable workaround for those who use the Advanced Mode licensing & have access to LFEdit.  I'll post back with a CAR # in a few minutes.

Kind regards,

-RDR

[RDR]

I've reported this to R&D under ID #430940.

[Jim_Kring]

Bob: Thanks for the CAR.

Richard: Thanks for the tip about "allow delayed trigger codes".