IRD-dev

Mike and Suncat3 –

I confirm that, with the addition of the previously-unmentioned file “/includes/wc-attribute-functions.php”, this bug is NOW FULLY RESOLVED.

Thank you again, Mike. I am also pleased to learn that my follow-up report to you (“error on line 340”) was indeed factual and not related to my implementation.

For anyone else interested, this change is presumably part of the forthcoming WooCommerce 2.6 release which is presently in BETA.

The two files that were changed are:
/includes/wc-attribute-functions.php

and

/includes/class-wc-product-variable.php

Copy and paste the two file’s contents from the repository (linked above) and promote to your web server thereby replacing the former copies.

2016-May-17

Jan, while we’ll agree to disagree, I think we all understand the importance of a strong password. As for me, I’d still prefer WordPress not to reveal usernames .. and to take every precaution to ensure that 3rd party plugins / extensions adhere to this policy as well. Moreover, to DISALLOW installation / execution of such, should they fail to remain in compliance. A “responsible” framework, at the core.

With WordPress 4.5 about to be released you also will be able to log into your installation with your email address as your user name.

Whatever the key may be, username or email address, it’s only good until revealed publicly as a viable means of access.

I’d like to put your faith in “password-only security” to the test. Please reveal to us in your next reply the following info:

• Your full email address
• The URL to that mailbox’s webmail portal

Assuming you have a strong password, I trust that you’ll have nothing to fear.

@scott Allen – Thank you – first and foremost for your service to the USofA (you mentioned being deployed). Secondly, thank you for the verbose feedback and your support of this seemingly-controversial subject.

I, too, was perplexed, after seeing some of the facile (perhaps even discourteous) responses this thread has received. It was as if the subject matter was personally insulting to the almighty WordPress establishment itself. My only goal was / is to chime-in and continue to raise awareness and visibility of this factual issue with WordPress security. Yes; it’s come a long way .. but much more needs to be done. And there are too many 3rd-party services offering plug-in or similar support, acting as band-aids, which merely serves as empirical evidence on this overall point.

In regard to the Username dataleak, intrinsic to WordPress, I’ve worked for numerous, global companies who took EVERY precaution not to have Usernames exposed to the public .. or even a corporate passer-by. Was it 100% foolproof? Of course not .. but RISK and COMPLIANCE still considered it mandatory. The best option is to cover as many bases as one can, within reason.

As you pointed out, and not unlike other software, the WordPress platform has suffered numerous and significant breaches – many of which received publicity, whether due to WordPress itself or a 3rd party plugin/extension. When I suggest the WordPress platform to my more savvy clients, that’s their FIRST reaction. I spend the first part of my sales pitch, deescalating their valid and founded concerns.

I don’t wish to be misunderstood. I love WordPress, as much as the next developer, and have earned some decent coin working on client projects. Yet, in the same breath, the client perceives the final solution as a reflection of MY services. Hence, if it’s insecure, clients will blame me. In fact, a good friend and full-time WP developer was overburdened in 2015-Q3/Q4, after a publicized exploit of WordPress impacted their clients and resulted in bringing their business to a grinding halt while amends were made to each and every client’s site .. and many clients felt obligated to have the work performed pro bono.

While I am not sure that this particular (one of MANY) threads is the most beneficial place for ongoing, transparent discussion .. perhaps you can start a new domain where WP devs may congregate and constructively share working examples of applied WP Security?

While unrelated to the above, security doesn’t end here. As developers, we also have the responsibility to secure and protect our client’s credentials on our local or cloud-based development machines. Aside from the client’s admin credential, the WP-CONFIG.PHP file contains their WordPress credentials and other sensitive data. For example, I choose to ZIP-encrypt that file, once development concludes. I mentioned this to another avid, professional WP developer who, admittedly, never gave that a moment’s thought. Should their dev environment be compromised (and, let’s face it, everything is being hacked today), all of their client’s data would have been compromised, in one felled swoop.

Please be encouraged to head over to this post and chime in.

My post recently received some sensible feedback from one Scott Allen.

To those interested, here’s a related article posted today, covering WordPress and WooCommerce topics “Post-launch security steps to take in WooCommerce“.

Needless to say, we’re not alone in these concerns.

Here’s a related article posted today, covering WordPress and WooCommerce topics “Post-launch security steps to take in WooCommerce“.

@jjbte – Good additions to this thread. Thank you. Will also consider your .HTACCESS suggestion, where applicable.

It’s amazing to me .. look at some of the sarcastic replies that I received on the aforementioned thread from a few “self-professed security gurus”. I’ve worked for global companies and they took EVERY precaution not to have Usernames exposed to the public or even a corporate passer-by. 100% foolproof? Of course not .. but RISK and COMPLIANCE still considered it mandatory. The best option is to cover as many bases as one can, within reason.

Whats your meaning of

I assumed that you made some enhancement to the Search & Replace plugin, per our discussion in this thread. If so, I was wondering if those changes would be included in the next public release here or only by downloading it from the URL that you provided above.

Danke mein Freund!

Hello Mike. As you have not responded, I have changed the status to NOT RESOLVED. Perhaps that is why you weren’t notified. Not trying to stalk you, brother ??

Thank you for replying. Due to time constraints, I ended up leveraging a different plugin “Search & Replace” which (at the time) was unable to support my special scenario.

In the end, I used that plugin’s “Dry Run” report as a reference, and swept the WPDB using phpMyAdmin.

For example, I used the following SQL command to update the list of WP tables below:

UPDATE wp_comments
SET comment_author_email = REPLACE(comment_author_email, 'clientname.net.temp.mydevhost.com', 'clientname.net')
WHERE comment_author_email LIKE '%clientname.net.temp.mydevhost.com%'

Tables : columns manually updated:

wp_comments : comment_author_email
wp_layerslider : data
wp_options : option_value
wp_postmeta : meta_value
wp_posts : post_content
wp_posts : guid

As for changing the DNS, etc, I was already familiar but do appreciate the insight nonetheless. My issue was solely looking for an automation tool to search the various WP tables and perform the aforementioned change in one felled swoop.

Hallo und danke, Rene.

I apologize for the delay in responding. Due to time constraints, I was unable to await your kind enhancement to the plugin. As I previously mentioned, I did reference the “dry run” report and then manually performed the work against the WP database tables which I also listed above.

I will certainly try your plugin again, with my next project, as this approach is how I typically develop a new customer / project.

Will you be promoting the enhancement to the official plugin .. or is that only available at your special URL: https://github.com/inpsyde/search-and-replace/archive/master.zip ?

Hello Mike. Sorry to bother .. was hoping for a follow-up on the aforementioned error.

2016-Apr-10: I wanted to circle back and update readers that the above idea works perfectly, even after Posts have been published.

Simply log into phpMyAdmin, select your WP database, browser the WP_USERS table, and alter (for every user) the “user_nicename” value to something different than the actual login name .. and, of course, unique across all records in this table.

In my opinion, this action should be completed IMMEDIATELY after creating a new username .. and certainly BEFORE exposing your website to search engine crawlers.

I performed a test, by posting TWO articles – one with a WP User “my-test-user” whose “user_nicename” value was the same as their login name. Google results included both articles and, in particular, the article published by the aforementioned user revealed their username as such: https://mydomain.com/author/my-test-user/

Supporting articles for manually editing the “user_nicename” value:
https://www.ads-software.com/support/topic/how-can-i-change-the-user_nicename

https://itpixie.com/2012/10/hide-your-wordpress-login-from-author-archive/#.VcO2lM_JC9I

Granted, there are other more promising means to protecting one’s WordPress security (as outlined throughout this post). However, I do not understand why WordPress has not taken measures to fix this “information leak”.

On a related note, I may also try an online scanning service such as this free 14-day trial with Acunetix (formerly WebsiteDefender.com).

@lagunas and @jjbte :
I agree 100% with both of you! In fact, I also raised this concern on the following WordPress post.

Readers should know that this idea works perfectly, even after Posts have been published.

Simply log into phpMyAdmin, select your WP database, browser the WP_USERS table, and alter (for every user) the “user_nicename” value to something different than the actual login name .. and, of course, unique across all records in this table.

In my opinion, this action should be completed IMMEDIATELY after creating a new username .. and certainly BEFORE exposing your website to search engine crawlers.

I performed a test, by posting TWO articles – one with a WP User “my-test-user” whose “user_nicename” value was the same as their login name. Google results included both articles and, in particular, the article published by the aforementioned user revealed their username as such: https://mydomain.com/author/my-test-user/

Granted, there are other more promising means to protecting one’s WordPress security (as outlined throughout this post). However, I do not understand why WordPress has not taken measures to fix this “information leak”.

Hello.
I was hopeful that, after this website moved from development to live, the last remaining error/warning would be eliminated.

However, despite that the site is now resolving at MyDomain2.com, the contact form is still throwing an error on FROM: [your-name] <[email protected]>

Error is shown in red: “This email address does not belong to the same domain as the site.”

Regardless, the form is functioning as expected.