Hey team, we’re building a plugin for DaVinci Resolve for MacOS and Windows and cryptlex is generally working great for our users. However, we have one user on MacOS where cryptlex fails to write to ~/Library/Application Support/.
As a result, what they see is they load the plugin, it asks them for their license key and tells them they successfully activated. Then, next time they load the plugin, it prompts them again for their license key. For all our other users, it behaves as you’d expect where once activated, the plugin can detect that it’s already activated via IsLicenseGenuine() and not prompt the user for a license key. I’ve checked and on their computer, the iConf folder does not exist within that directory like it does on mine. In the cryptlex admin panel, it says the user has indeed used one of their activations for their license key, as expected. We’re using node locked per-user license keys, if that matters.
The user is running MacOS Sequoia on an M1 MacBook pro, which is essentially the same machine I was using during development too.
Anyone know what might cause this sort of problem? I’m happy to provide anything to help diagnose the issue.
Hi,
Thank you for reaching out, I am Anees from Cryptlex!
Could you please confirm if you are checking the correct path, i.e. the user-specific path and not the system-level one? The iConf folder should exist in the user’s /Users/username/Library/Application Support directory path once the activation succeeds.
Additionally, could you please help us with the permission flag being passed to the SetProductId() function during activation?
Hey Anees,
For context here’s what the function looks like (we’re using LA_USER in SetProductId)
// Called every time the plugin is initialized
int getActivationStatus() {
int status;
status = SetProductData(CRYPTLEX_PRODUCT_DAT);
if (LA_OK != status) {
log("SetProductData error: %d", status);
return status;
}
status = SetProductId(CRYPTLEX_PRODUCT_ID, LA_USER);
if (LA_OK != status) {
log("SetProductId error: %d", status);
return status;
}
status = IsLicenseGenuine();
if (LA_OK == status) {
log("License is genuinely activated: %d\n", status);
return status;
} else {
log("License is not activated: %d\n", status);
return status;
}
}
// Called when the user clicks the "activate" button
int activate(const std::string& key) {
std::string trimmed_key = key;
trimmed_key.erase(0, trimmed_key.find_first_not_of(" \t\n\r"));
trimmed_key.erase(trimmed_key.find_last_not_of(" \t\n\r") + 1);
std::string license_key = trimmed_key;
int status;
status = SetProductData(CRYPTLEX_PRODUCT_DAT);
if (LA_OK != status) {
log("SetProductData error: %d", status);
return status;
}
status = SetProductId(CRYPTLEX_PRODUCT_ID, LA_USER);
if (LA_OK != status) {
log("SetProductId error: %d", status);
return status;
}
status = SetLicenseKey(license_key.c_str());
if (LA_OK != status) {
log("SetLicenseKey error: %d", status);
return status;
}
status = ActivateLicense();
if (LA_OK == status) {
printf("License activated successfully: %d\n", status);
} else {
printf("License activation failed: %d\n", status);
}
return status;
}
I have had the user run ls -ld ~/Library/Application\ Support/iC* and no iConf folder was present, so indeed it does appear that cryptlex isn’t writing to their directory. Generally, it’s working for the vast majority of our users though, and there’s certainly a ~/Library/Application Support/iConf folder on my MacBook.
Hi,
Thanks — that’s a helpful report. This normally isn’t a Cryptlex problem in the licensing engine itself (the license shows as activated in the admin panel), it’s that the Cryptlex runtime can’t persist the activation data on that Mac. On macOS the runtime writes activation data under the current user’s ~/Library/Application Support/… (that iConf folder you mentioned). If Cryptlex can’t create or write that folder, the next time the plugin loads it can’t find the stored activation and prompts again.
Most likely causes
-
File-permission or ownership problem for ~/Library or ~/Library/Application Support (or the iConf subfolder).
- The plugin / host app (DaVinci Resolve) is being launched from a quarantined/translocated location (e.g., directly from a DMG) or is not a normal app bundle under /Applications. That can make file paths behave unexpectedly.
- The plugin is being executed under a different user account (rare, but possible if Resolve is launched by another user/service).
- Some unusual macOS privacy/containment setting or third-party security software blocking writes.
Quick check
ask the user to run this in Terminal
mkdir -p ~/Library/Application\ Support/iConf && echo "ok" > ~/Library/Application\ Support/iConf/testfile && ls -la ~/Library/Application\ Support/iConf
If this fails, note the exact error (permission denied, etc.).
It seems that the user has write access via terminal and was able to make the testfile there. I also have the hypothesis it might be some kind of permissions issue, but I’m having difficulty figuring out what that might be and how to diagnosis that. I’ve asked the user about the first three of these bullet points you mentioned so far.
The host is indeed installed and running from the /Applications folder, and this user only has one account on his machine.
In the top half of the below screenshot, you’ll see their permissions for their Library and Application Support directories given by ls -ld
I’ve also had them run the command you offered and that’s in the bottom half of the below screenshot.
Do let me know if there’s something we can use to diagnose the fourth option of there being some sort of unusual setting or third party software. I’m thinking it’s probably the most likely, if you think these permissions shown by ls look about right. The user does say they’re not aware of any antivirus software on their computer.
Alternatively, if there’s a workaround that would allow us to write the activation data somewhere that we know we can write to, that’s another possible option here.
Hi,
Kindly reach out to our support channel via support@cryptlex.com. We may need to share a debug build to investigate the issue in more detail.
Thank you Anees, I reached out to that email address and hopefully we’ll figure out what went wrong
1 Like
