I’m implementing the web API in our product to manage activation and automatic renewal (LexActivator would require us to build with cgo which we are trying to avoid)
I’ve been able to activate and deactivate licenses just fine, but am getting an INVALID_ACTIVATION_FINGERPRINT error when I try to renew with PATCH /v3/activations/{id}
I’m sending the exact same data in the PATCH request as in the POST request which creates the activation, the fingerprints are identical:
carson@archlinux ~/g/s/g/c/orchesto> go run main.go -activate B93413-C6CB8F-4FE284-21D6BA-7A93AA-91E25A
POST /activations:
{
"key": "B93413-C6CB8F-4FE284-21D6BA-7A93AA-91E25A",
"metadata": [],
"os": "linux",
"fingerprint": "9b3031cbdbeeaf97f51b647525389def90200008fa1d2cde86752ca839957aac",
"hostname": "archlinux",
"appVersion": "0.0.0",
"userHash": "6557a98c5b070d56c568b3bd8fe978cb1ea14a58940941e1a80da510df2d55dc",
"productId": "a6ec15de-49a6-4f9a-9625-5121a35167c1"
}
carson@archlinux ~/g/s/g/c/orchesto> go run main.go -renew
PATCH /activations/9f06dce9-c379-4caf-a34b-871ac7438e37:
{
"key": "B93413-C6CB8F-4FE284-21D6BA-7A93AA-91E25A",
"metadata": [],
"os": "linux",
"fingerprint": "9b3031cbdbeeaf97f51b647525389def90200008fa1d2cde86752ca839957aac",
"hostname": "archlinux",
"appVersion": "0.0.0",
"userHash": "6557a98c5b070d56c568b3bd8fe978cb1ea14a58940941e1a80da510df2d55dc",
"productId": "a6ec15de-49a6-4f9a-9625-5121a35167c1"
}
main: <ERROR> Could not renew license: API Error INVALID_ACTIVATION_FINGERPRINT (400 Bad Request) Server sync failed!
The activation id in the endpoint is correct, I pull it straight from the activation token and confirm in our dashboard that it’s right (and the rest of the details appear correct as well when printing the stored license data:)
carson@archlinux ~/g/s/g/c/orchesto> go run main.go -license
Product key: B93413-C6CB8F-4FE284-21D6BA-7A93AA-91E25A
Key: B93413-C6CB8F-4FE284-21D6BA-7A93AA-91E25A
ProductID: a6ec15de-49a6-4f9a-9625-5121a35167c1
ActivationID: 9f06dce9-c379-4caf-a34b-871ac7438e37
Type: node-locked
Issued At: 2018-31-10 09:42:03 UTC
Expires: 2019-31-10 00:43:12 UTC
Renew By: 2018-31-10 10:42:03 UTC
Renew By Latest: (no grace period included in license)
Renew Interval: 1h0m0s
Operating System: linux
Node Fingerprint: 9b3031cbdbeeaf97f51b647525389def90200008fa1d2cde86752ca839957aac
Does the invalid fingerprint error refer to the node fingerprint I send in the request or is there something else about the request that isn’t right?
Fingerprinting is quite simple at the moment, we plan to work on it to make it more flexible. Is there any documentation on how fuzzy fingerprint matching works for future reference?
I’ve taken care of the encryption and signature verification already. My main concerns are getting fingerprinting working well enough and finding a way to implement VM detection, which is also very challenging without cgo as it typically requires particular machine-language instructions which can’t be used by go directly
I verified and decoded the JWT token and used it to inform the product of things like product features, renew times and expiration dates.
Is using PATCH /v3/activations/{id} the correct way to refresh an activation? As a fallback I’m deactivating the license and making another call to POST /v3/activations
You can’t use “fuzzy” fingerprint matching strategy with a custom fingerprint. It works only for fingerprint generated through LexActivator.
Many keys in the JWT token are abbreviated, I hope you were able to understand them properly. I can provide you with full names, in case of any ambiguity. Please do honor server sync frequency interval, that way you can control it from the dashboard.
Yes, it is the correct way. Your fallback option will only work if fingerprint doesn’t change.
Is the fuzzy matching specific to LexActivator fingerprints? As in it’s a trade secret and can’t be leveraged while using the API? Is it the same for the loose matcher?
I have set the matcher to exact, however I still get the invalid fingerprint error when using the PATCH endpoint despite the request bodies being identical for creation and updating of the activation.
Regarding the delete/create flow, it seems to me it would still work if the fingerprint changes, no? Since the delete endpoint doesn’t require a fingerprint, the subsequent activation would just contain the new token, right?
Yes, it is a trade secret. I previously mentioned that fingerprint strategy should be exact, actually for custom fingerprints this property is ignored, and the match is always exact.
Fingerprint should have been base64 encoded, we have removed this restriction for custom fingerprints and it should work now.
Yes delete/create flow will work. Since you are using API, make sure you do implement suspend/revoke functionality so that you can control it from dashboard.
Yes, LexActivator uses only these three endpoints for license activation/sync/deletion. If you want to implement trials too, you will need to implement trial activation endpoints too.