Alexandre Froger

Hi @jacobrossdev

When trying to activate a plugin by license key on a localhost, I get an error “Malformed response” in the XHR requests.

Seems like it’s a feature, not a bug ?? – this applies to localhost (which ain’t a domain), licenses are per domain. Licenses are for plugin updates when the plugin is in production environment, whereas localhost is typically used for development or tests.

Second bug, the inline notice/warning is persistent asking for a license key depite having successfully activated one. This causes confusion for clients that think they haven’t registered my plugin correctly.

I’d be happy to help troubleshoot this in a separate issue (BTW it’s easier on Github for keeping track of things).

It’s also kinda ugly lol.

Indeed, it’s barebone – that’s code sitting in the lib folder of the dev’s plugin, devs are free to extend the WP_Package_Updater and override the methods to include different templates. I’ve been trying to keep assumptions to a minimum here and cater to immediate needs: have a field to input licenses for themes and plugins, have an error message. Devs can and are encouraged to improve the interface as they see fit.

Hi @jacobrossdev!
Thank you very much for the information!
You are right – I assumed the class ZipArchive would be available. I added it as a requirement on plugin activation and in the readme.txt for v1.4.8

Again, thank you so much!

Hello @jacobrossdev
Thank you for the hard work – I wasn’t expecting you to spend even half of the time you spent on it, merely giving feedback would have been greatly appreciated already.

If you’d still be keen on attempting to resolve the issues you’re experiencing, I added even more server logs to the WPPUS_Zip_Package_Manager class to help. Also FYI, meaningful error messages were already in place, and set to be shown via trigger_error, provided WordPress debug mode is activated.

The packages are deleted whenever there is an issue repacking the files coming from the remote repository in the following cases – this is so that the file system does not contain the remnants of failed attempts to create the archive:

• There is an error determining the local temp path of a package downloaded from the repository (logs the message of the wp_error object)
• The local temp path is empty
• The file system is not accessible
• The archive could not me moved (usually a permission issue)
• Unzipping the archive received from the remote repository failed
• Zipping the archive when relevant changes have been applied failed
• The archive received from the remote repository contains more than one directory (invalid package structure)

On that last one in particular, it does not mean the repository itself must contain a single directory – it means the archive, when unzipped via WordPress’s call to PclZip, must contain a single directory. For example, when visiting https://bitbucket.org/user_name/package_name/src/branch_name/, I see all the files and directories contained in the final package_name, with the main file package_name.php at the root of the repository.
If I go to https://bitbucket.org/user_name/package_name/downloads/ and click “Download repository”, I get an archive named user_name-package_name-some_ID.zip.
When manually extracting user_name-package_name-some_ID.zip, I get a user_name-package_name-some_ID repository containing all the files of the package at its root. Because the name of the downloaded zip archive does not correspond to WordPress naming convention for packages, WPPUS_Zip_Package_Manager needs to unpack, rename, and repack the archive, and for that to happen, a specific file structure must be in place. I am not saying this is where the problem is for sure (not having access to your repository or code base), but if it is the case, I do hope the information helps.

All these cases are now logged in v1.4.7 even when the WordPress debug mode is not active, for troubleshoot purposes.

• This reply was modified 6 years, 5 months ago by Alexandre Froger.
• This reply was modified 6 years, 5 months ago by Alexandre Froger.
• This reply was modified 6 years, 5 months ago by Alexandre Froger.
• This reply was modified 6 years, 5 months ago by Alexandre Froger.
• This reply was modified 6 years, 5 months ago by Alexandre Froger.
• This reply was modified 6 years, 5 months ago by Alexandre Froger.
• This reply was modified 6 years, 5 months ago by Alexandre Froger.

@jacobrossdev v1.4.6 is out with better error handling and output to server logs.

Another thing: the content of wp-content/wppus/logs/ may give us a clue, as it logs the requests going out to the repository service (bitbucket).

Edit – it logs the incoming requests, not the outgoing ones – never mind…

• This reply was modified 6 years, 5 months ago by Alexandre Froger.

Glad to see most of it is working!

Regarding the remote repository part, could you confirm with me the value in the field “Remote repository service credentials” follows the format Key|Secret where Key and Secret are the values provided by the OAuth consumers section in bitbucket (with no space, just the 2 values separated with a pipe)?

If this is not it, then I’ll investigate further. I personally use this plugin with Bitbucket for my own projects, therefore it may be a very specific error I do not experience.

For me to help troubleshoot with more more information from you, the code would need to be edited. Indeed, this particular alert does not give the most meaningful message… I’m improving it right now, with extra server logs output, and will commit a new version in approximately 8 hours (I’m on Beijing time).

I tested just now and noticed the package name string is not the same as the intended plugin slug – it has the date appended to it.
Extract from the on-screen help:

The archive needs to be a valid WordPress plugin or theme package.
In the case of a plugin the main plugin file must have the same name as the zip archive – for example, the main plugin file in package-name.zip would be package-name.php.

Thank you ; I can see the there is license_error property, which means license check is activated for this plugin. Is it intentional? This is where the download_url property should be instead.
If this is not intentional, please make sure to disable the license for this plugin in the “Overview” tab, and maybe omit the last boolean parameter when calling new WP_Package_Updater in your main plugin file.

If the license check is activated for the plugin, then the URL to visit in the browser above should include more parameters (license and signature in particular), which I cannot guess – you can find them using Query Monitor would you decide to test with license checks enabled.

Aside from this license_error, everything seems to work as intended ; once a download_url property can be found, the update process can work.

• This reply was modified 6 years, 5 months ago by Alexandre Froger.
• This reply was modified 6 years, 5 months ago by Alexandre Froger.

I see – thank you for the information.
In the browser, after clearing your permalinks, what would be the result of visiting the following URL (edited where applicable and assuming the licenses are not enabled for this plugin)?

https://your-update-server-domain.tld/wppus-update-api/?update_action=get_metadata&plugin_id=woocommerce-product-table

• This reply was modified 6 years, 5 months ago by Alexandre Froger.

I seem to have found the issue regarding the second message you sent: it’s how Windows system paths are handled. The issue would not happen on a production server (assuming it’s not a Windows server).

There is a mix up between the use of wp_normalize_path (which converts backslashes into forward slashes in a string, among other things) in the constructor call of the updater class in dummy plugin, and the use of DIRECTORY_SEPARATOR in the class itself.

I will update the dummy plugin and dummy theme to fix the issue. In the meantime, you can safely replace DIRECTORY_SEPARATOR by / in the WP_Package_Updater class.

Regarding the issues noted in the first message, I would still need to investigate – it seems to me this type of issue is harder to troubleshoot for me as they occur on a localhost: the plugin was developed using a development and a staging server to make sure it reflects real life use, therefore its is difficult for me to replicate the environment leading to the 400 Bad Request error. Is there more information you could provide, such as the result of API calls inspected with Query Monitor?

• This reply was modified 6 years, 5 months ago by Alexandre Froger.

Hello @jacobrossdev
Thank you for the feedback. I’ll investigate with the provided information, and report back here shortly.

Marked as solved as per this comment.

Hey Alex,
I suspect your logs are not output – there was an error on plugin activation and the plugin has been updated to fix it. Without more information I’m afraid I cannot say if the issue is related.
On another note, I realize it’s been 1 week this issue is open and strangely enough I did not receive an email about it. I should add a note on the plugin page that issues may be better dealt with on github instead of here.

Hi @mbrsolution,

Are you able to provide more information, as suggested in your first answer?

The License Verification key is the only way for the SLM “to know” that a message is really coming from a product, that is authorized to communicate with the SLM.

Only you, the SLM and any software products that use that specific SLM should know the License Verification key. For high value products, written in human readable code (PHP or Javascript), you might consider the use of a code obfuscation tool to ensure the security of the License Verification key.

Were I an attacker, the only thing I could do without licenses to check against is DOS attacks – no matters I have the “Secret Key for License Verification Requests” or not. It’s just a matter of how many requests I’d need to fire away (with the secret, the impact of a request is slightly higher since it hits the database a little bit more, but so slight it can be neglected), and chances are if I’m performing an attack, I have the firepower.

Regarding obfuscation, nothing prevents me from checking what’s getting out of my client installation, grab the payload, and see the “Secret Key for License Verification Requests” in clear. Security by obfuscation is not security.

• This reply was modified 6 years, 6 months ago by Alexandre Froger.