Stelio Kontos

The updated version you provided in the support thread resolves these issues. Thanks for the excellent support and attentiveness to your users. Keep up the great work.

Do you run WooCommerce in HPOS or legacy mode ?

legacy mode

Please, submit ticket to https://algolplus.freshdesk.com/ and we’ll share fixed version asap .

ticket created (check git blame for “class-wc-order-export-order-fields.php:335”)

Ops, customer_user should be 0 for guests.

IMO, using an empty value for guests is technically the correct way to handle it, since it reflects a missing value and more closely aligns to what is stored in the database (null) and how it should be handled in data pipelines (ie <NA>). But it is a major change, so perhaps rolling it back and reintroducing it later (or even better, offering an option to choose how a null value should be represented on a per-column basis) is probably a good idea.

Thanks for the prompt response and a fantastic product.

• This reply was modified 7 months ago by Stelio Kontos.

@akiow17 it is usually necessary to resave your permalinks (Settings->Permalinks) after enabling the option, for the actual license keys to appear on that page under My Account.

Untested, but modifying line 75 in /includes/api/Authentication.php to the following should force non-ssl requests to fall through to the else condition if ssl is required:

if (is_ssl() || (is_ssl() && Settings::get('lmfwc_disable_api_ssl'))) {
    $userId = $this->performBasicAuthentication();
}

While changing the active environment in Postman to test on a bare WP install on my local dev env, it occurred to me that I was not specifically including https:// in the base url portion of the requests. As soon as I added that to the url, both PUT and POST requests worked as expected (with the create License call no longer returning the entire array of licenses).

While I’m relieved to have finally found the problem, it does appear that sending API calls without the https:// to a site with SSL installed could be exploited to dump all licenses, and I would suggest that your dev team look into this. Note that API routes were disabled for insecure http connections.

Specifically disabling the v2/licenses route prevents this anomaly, returning a “lmfwc_rest_route_disabled_error” response when attempting to create a license using POST method.

It appears that the POST method is being blocked due to the API request being made over an insecure connection, but since the “create” and “list licenses” requests both share the same request route, it returns the standard response as if the request method was GET – when in fact, it should abort the request completely with an appropriate http 4XX response code.

Leaving this thread marked as unresolved for now pending a resolution on the above mentioned vulnerability.

• This reply was modified 2 years, 3 months ago by Stelio Kontos.

Just tested with the same json fields you have in your video, and no change in behavior for me. See gif:

View post on imgur.com

I’m on the latest (released) version, v 2.2.7: https://i.imgur.com/1kKL5rt.png

Are there any known conflicts with other plugins that may be contributing? Perhaps a cache plugin etc.

I will test again this morning and let you know as soon as I am at my PC. I have reviewed the docs extensively, and there is no mention of that field being required, nor am I getting an error response when that field is omitted. If it is indeed required, the docs should mention that fact, and I would expect the API to reject that request with the appropriate http status.

This also does not explain why the Update license request fails for me also.

Is there any server configuration that I may be missing that would cause PUT and POST method calls to be silently ignored, that may be interfering with the request?

@haseeb0001 no problem. Would you like me to open a PR with the change?

@haseeb0001 happy to help. If you’d like me to test and open a PR let me know.

Any update? Or can anyone else who may be reading this thread confirm if the PUT and POST API calls for licenses work for them? The fact that nobody else seems to have reported this issue makes me wonder if it could be an issue on my end, perhaps with the server ignoring those types of REST method calls. My experience with WP’s REST API is limited, however, and honestly not sure where to go from here.

Ye that’s what I expected. For now, using your current workflow for generating license keys manually, just generate them with a “sold” status, then manually change it to “delivered” after the key has been created.

IMO I would consider this a bug; since a license key has to be sold before it can be delivered, creating a license key with an initial status of “delivered” should pass the same checks it would if the status was “sold” during the license generation.

Note to devs (bug report): The conditional statement in the insertGeneratedLicenseKeys function only sets the $expiresAt field if $status == LicenseStatus::SOLD.

Proposed change to logic:

// includes/integrations/woocommerce/Controller.php:199
if ($generator->getExpiresIn() && ($status == LicenseStatus::SOLD || $status == LicenseStatus::DELIVERED)) {
//...

@mennovink Generate a key with status set to “Sold” (NOT “Delivered”) and see if it works.

I’m not sure if this is a bug or intentional, but if it is intentional, would it be possible to add a boolean indicating if it is expired?

Most likely an oversite; the “activate” and “deactivate” api requests both check if the license has expired. I do agree that it should be included in api calls to “validate”; simply adding one line to the $result array at includes/api/v2/Licenses.php:872 would accomplish this:

'hasExpired' => boolval($this->hasLicenseExpired($license)),

Alternatively i could use /licenses/ and check the expiresAt key. But what kind of time is that, is that server time? Or UTC maybe?

– UTC for “activate” and “deactivate” api requests.
– GMT for setting the expiresIn value when inserting a newly generated key in the db (using a generator).

See screenshot here.

Edit: I’m not involved in the development of the plugin, and am referencing the GitHub repo (which may not be as up to date as the latest svn source).

• This reply was modified 2 years, 3 months ago by Stelio Kontos. Reason: disclaimer

@mennovink by “manually generated licenses” and “generating a new key”, are you referring to creating a new key with the “Add New” button on the “License Keys” page, or manually generating a new key using a specific generator with the “Generate” button on the “Generators” page?

@thisvo not sure I follow…could you post a screenshot of what you’re referring to? The screenshots in my last post (https://i.imgur.com/rhSteyu.png) are from the cart page, which would match what’s shown during checkout and confirmation.