Fingerprint already activated when using wp-config setup

Peter T Wise

We're having an issue around our staging workflow and the wp-config license setup. (I figured https://community.commandui.com/d/34-feedback-wanted-commandui-license-managment was too old and I should start a new discussion)

Steps to repeat:

add per-client license key in the dashboard. We gave them 3 sites per key so hopefully that would work on production, staging and local.
add the license key to all locations with define( 'CUI_LICENSE_KEY', 'ak_********' )
copy the database from production to staging (plus additional normal steps like find and replace with the staging domain, etc)

At this point we get the error message in the dashboard "Please activate a license key to keep using CommandUI without disruptions. [Activate CommandUI License] [Dismiss for a day]

If we click Activate License it brings us to the activation screen and the proper key is already filled. If you then click "Activate Site" the following error comes up:

Error: The fingerprint is already activated for this license.
Code: commandui_api_error.fingerprint_already_active
API Request ID: req 01ka9p7i0y364knleb6x7ekbxe

Let me know if I'm missing a step or should be setting this up differently.

Thanks!

Calvin Alkan

Peter T Wise

Is the domain already activated with another (old) license key? That is most likely the issue here.

Can you check this in your account dashboard?

The fingerprint is the full domain name, i.e. staging.site.com

Peter T Wise

It's not an "old" license key - it's the shared key for the staging/local/production sites.
Is there some hash stored in the database that ties the key to the current domain or something like that?

Our workflow is to copy production site.com db to staging.site.com (and/or site.localhost )

If I remove the staging or local from the CUI dashboard and then activate again from the WP settings page it works.
I was just hoping to not have to do that every time we copy the database - sometimes multiple times per day.

Calvin Alkan

Peter T Wise

Do you copy over the database? There is one wp option that we use where we store some metadata about the license to be able to keep track of when people change their site url, etc. In order to auto port over the license.

The license server stores only the TLDs.

You can't activate the same TLD twice, but If you copy over the wp option it should work, and not even ask you for a license.

dkod

We have the same issue. We registered two licences for one of our website under construction: one for staging (domain.fr.prod.company.fr), one for development (domain.fr.docker).

As soon as we dump the database from staging to development and do the search-replace of urls in the database, the licence deactivates itself and we need to go to the licensing portal remove the licence, recreate one, reassociate the environment.

This is too much constraints, and honestly we don't want a productivity tool to slow down our workflow.

Hope you'll find a solution quickly or we'll have to init the refund process.

Calvin Alkan

dkod @Peter T Wise

When you you push from staging to development, or vice-versa, and then go to the CommandUI settings page, is this the message you see?

'commandui.license_status.fingerprint_not_found', 'License information was found in the WordPress database, but the site fingerprint is not a match.'

Calvin Alkan

I've dug into the licensing internals again, and I tried to solve this problem already in the past:

    // Store license status indexed by fingerprint hash to support common WordPress
    // deployment workflows where sites get pushed between prod/staging/dev environments.
    // This way, each environment maintains its own valid license status without requiring
    // reactivation when moving between environments.
    // In practice, this allows one WordPress database to hold license status for production and staging.
    // We use a fingerprint because the plain domain name is likely to be overwritten by hosting companies
    // "search and replace" scripts during migrations.
    $all_activations[fingerprintBlake2b($fingerprint)] = [
        'first_connected' => time(),
        // Connection key can't be used for "write actions".
        // It's not sensitive and only used for potential reconciliation.
        'connection_key' => $response_body['connection_key'],
        // Store the original fingerprint as well,
        // so that we could later display which "domains" have been activated on this site.
        // Though note that this can change during "search and replace scripts",
        // so we will need to match it against the array index key.
        'maybe_original_fingerprint' => $fingerprint,
    ];

How it's supposed to work ideally:

You activate the license once, on dev.domain.com , your wp_options commandui_activations now has the license information for that domain.

Now, you push to staging.domain.com, and there is no license information yet, but you should be able to activate the new domain (either via wp-cli, or in the settings) without adding a new license key, or changing anything inside the license server dashboard.

Thats the theory, at least. Maybe some information is getting lost inside the staging/dev pushes, or the database is not pushed?

It would be helpful if you can provide the content of the commandui_activations option after a staging push.

Calvin Alkan

Just tried this on commandui.com itself; when pushing from production => staging, I see this message, which is expected:

Note: We found an existing activation key and pre-filled it above. This typically happens when you've moved your WordPress site (e.g., to staging or a new URL).
You can use this same key to activate CommandUI on this new location.

And then I can activate it,

License key configuration, two sites for staging + production:

I suspect that something in the staging/dev database push is interfering.

Peter T Wise

Hi @Calvin Alkan

I'm still unable to get the reauthorization to happen without deleting the key in the CUI dashboard. Here's some additional info on how to replicate our scenario:

Starting setup:

orionmagazine.org
orionmagazine.localhost
They both have the license key installed in wp-config like this:
define( 'CUI_LICENSE_KEY', 'ak_123example123' );

Each has individually be authorized to the same key.

Local commandui_activations value:
wp option get commandui_activations --format=json
{"20b3baf00ef350c820a4bd018e7e4f7d":{"first_connected":1765469324,"connection_key":"ck_***************CoWszhM","maybe_original_fingerprint":"orionmagazine.localhost"}}

Production commandui_activations value:
wp option get commandui_activations --format=json
{"da93498ff319fcca5b15c3925840f3b2":{"first_connected":1748967410,"connection_key":"ck_***************UeKYkbk","maybe_original_fingerprint":"orionmagazine.org"}}

Both sites show successful license connection at /wp-admin/options-general.php?page=commandui

Now we run our sync process:

pull down a copy of the production database
import into local
we do a find replace that includes https so wp search-replace 'https://orionmagazine.org' 'https://orionmagazine.localhost' --all-tables - so that won't replace the bare domain in the commandui_activations option.

After this is done the value of commandui_activations is the production site value, but we're now on the localhost URL. This causes the scenario like described above to happen. Everywhere on the dashboard:

Please activate a license key to keep using CommandUI without disruptions. Activate CommandUI License / Dismiss for a day

On the /wp-admin/options-general.php?page=commandui page:

Activate your CommandUI License
Please activate a license key to activate CommandUI on this site.
[ the key from wp-config is filled in the field ]
Note: We found an existing activation key and pre-filled it above. This typically happens when you've moved your WordPress site (e.g., to staging or a new URL).
You can use this same key to activate CommandUI on this new location.

Now if they key has a slot available and you press Activate you get:

Error: The fingerprint is already activated for this license.
Code: commandui_api_error.fingerprint_already_active
API Request ID: req_01kc7ge3y83hf9yhrnz085ze5m

Or if the key has no slots available - even if the current URL is on the list of sites taking up a slot for that license - then you get this error:

Error: The license key is configured to allow a maximum of 3 sites. You can not connect another site to this license key.
Code: commandui_api_error.license_key_max_sites_reached
API Request ID: req_01kc7gth48p79qke4smnv5k5v5

This is kind of the crux of the situation. It seems like if you try and re-authorize a site that's already on this key it should work and refresh the value in commandui_activations to a valid one. Or even better - if the key in wp-config is valid for the current domain name of the current site but commandui_activations is out of date, refresh it for us automatically so we don't have to go back and click the button again.

What currently works to resolve this?

delete the site under "Connected Sites" in https://my.snicco.io/licenses/ and then click Activate in WP
store somewhere before the sync and re-assign the old value of commandui_activations for the target site.

Just seems like it should be much easier than that to authorize prod/staging/local for a project one time and then just have them all work with no additional tinkering around as long as the wp-config value is valid.

Calvin Alkan

Peter T Wise Now we run our sync process:
pull down a copy of the production database
import into local
we do a find replace that includes https so wp search-replace 'https://orionmagazine.org' 'https://orionmagazine.localhost' --all-tables - so that won't replace the bare domain in the commandui_activations option.

Thanks for the detailed information. I understand exactly what the issue is now.

The commandui_activations option on purpose stores multiple entries so that all these various staging <=> prod workflows people do work.

But , you are overwriting the local CommandUI license information when you replace the database contents, and it goes out of sync at that point. The license server does not allow activating/"taking over" a site with a different license key if the local information is not present.

Peter T Wise Just authorize each URL once and then make sure commandui_activations option has the combined value with all of your different versions of your site on all of your sites that are a SOURCE for database syncs.

Yes, you should end up with all three, the order does not really matter.

Peter T Wise It would be nice if this were a bit more automatic somehow, but at least the above is a one time process that you can setup once and then just have it work going forward.

What part would you like to see automated more?

So, thinking it through, all of the following should already work:

Local dev first

Put the license key in the configuration
wp plugin activate (will see the license key and automatically register the site. See also the accepted answer here if you want full automation.
Now you have one site in the commandui_activations
Push the wp-config.php (that has the API key) to staging, and activate the plugin. Now you have two sites in commandui_activation
Push staging to prod andactivate. Now you have three sites in commandui_activations on prod.
Push prod => staging; now you have three sites in staging's commandui_activations.
Pull staging (or prod) to local, now you have three sites in local's commandui_activations

Staging/remote-dev site first

Entirely the same, but you start with staging, instead of local.

I think your issue was just that you tried to independently activate it on localhost, and then on staging as well. Now both sites had just one activation stored each. And then you overwrote that one option.

All that said, the license server should still support reconnecting a site automatically, as these mistakes can happen.

Peter T Wise

Ah - wait - new interesting info:

If I authorize the plugin on production, then do the sync, then remove and re-add on local, then the value of commandui_activations contains both sites.

{"da93498ff319fcca5b15c3925840f3b2":{"first_connected":1748967410,"connection_key":"ck_****************eKYkbk","maybe_original_fingerprint":"orionmagazine.org"},"20b3baf00ef350c820a4bd018e7e4f7d":{"first_connected":1765485153,"connection_key":"ck_**************Ncn5Ep","maybe_original_fingerprint":"orionmagazine.localhost"}}

Our workflow requires all of the following to be able to happen:

Sync Prod to Stage
Sync Prod to Local
Sync Stage to Local

So it seems like the proper setup method for this would be:

create a new license key with 3 slots
authorize the Production site
sync Prod to Stage
authorize the Staging site
sync Stage to Local
authorize the Local site
Now the value of commandui_activations should have all 3 sites on local.
Copy that combined triple value up to the production and staging databases

I have not tested yet, but theoretically if you do the above steps once then you should be able to copy databases around at will and not have to constantly be reauthorizing things.

Peter T Wise

Confirmed that the above works!

Just authorize each URL once and then make sure commandui_activations option has the combined value with all of your different versions of your site on all of your sites that are a SOURCE for database syncs. And make sure all sites have the key in wp-config. Then you should be good to go forever without clicking anything or having to reset anything.

🍾

It would be nice if this were a bit more automatic somehow, but at least the above is a one time process that you can setup once and then just have it work going forward.

dkod

Late to this. Thanks for the update, I will check that in details next week and provide feedback.

dkod

Ok, some updates relative to our workflow.

We have a fully automated site creation workflow and we need to figure how to manage the licensing of commandui correctly.

Sites are autogenerated locally through a code generator then a bunch of script shells using essentially WP cli are executed to provision the default state of the website depending on the customer and then they are auto deployed to a production environment on a temporary domain then when the site is ready the final domain is used.

Here is how we handle the licensing:

Currently in initialization process, we set commandui licence in db:
wp option set commandui_license_key "ak_***************"
then
wp plugin activate commandui

wp option get commandui_activations     
array (
  'hash' =>
  array (
    'first_connected' => 1765982027,
    'connection_key' => 'ck_****',
    'maybe_original_fingerprint' => 'domain.com.docker',
  ),
)

Save DB, deploy DB to (pre)production env.

In deployment process,

wp plugin deactivate commandui && wp plugin activate commandui

The license is created in (pre)production:

wp option get commandui_activations     
array (
  'hash' =>
  array (
    'first_connected' => 1765982027,
    'connection_key' => 'ck_1****',
    'maybe_original_fingerprint' => 'domain.com.docker',
  ),
  'hash2' =>
  array (
    'first_connected' => 1765985608,
    'connection_key' => 'ck_2****',
    'maybe_original_fingerprint' => 'domain.com.preprod.agency.com',
  ),
)

So basically, the solution seems to do :

wp plugin activate commandui locally before any deployment
automate wp plugin de/activate on deployments

That's not a big deal, but honestly I would prefer a dedicated "license_activate" / "license_check" command because it will prevent the deactivation => activation process which is slow by nature because it triggers a ton of hooks.

I gave a look quickly at the commandui plugin file, and it looks like the effort to achieve that is minimal. Basically, the function defined in the register_activation_hook should be defined externally. So we can even trigger it in a custom deployment hook or though a WP CLI. Ideally, the WP CLI is also bundled in your plugin.

Thanks for having worked on that issue quickly,

Calvin Alkan

dkod

Yeah, this is a bit annoying right now. And it should be a separate function as well.

Would a CLI command help? CommandUI doesn't really have a "public" PHP API.