jbauguss

did you solve this? I just noticed yoast doing this and its causing validation errors left and right.

bgermann, have you had a chance to look into this??
sonika’s solution really doesn’t work for me. I shouldn’t be having to make any customizations to have this work when it used to work by default.

This was a built in feature and should remain so. It can’t be that hard to make sure the default value of an element autofills via the $_REQUEST variable of the same field name.

I guess in some weird way this was handled by the old default my-functions functionality. Odd but if that was the big change, it must have been done there.

I’m back to a normal work routine. Can we try and figure out a solution to this? I’m fairly certain when you removed those deprecated functions, it killed the ability for cforms to autofill fields based on the query string.

This was a really important feature.

no i don’t use any of those. I switched to your newer method a while back for post form processing and I’ve never used the other filters.

I have reverted the few sites I had upgraded back to 14.13.3. So I’m not panicked. I’m heading on vacation for a few days and won’t be able to follow up until later next week.

here is a cforms 14.13.3 install with zero customizations. straight up unzipped the old cforms2.zip file.

https://bauguss.net/test-form/?ListingID=12345

you can see it fills in the value of that first field. (or any field)
https://bauguss.net/test-form/?ListingID=12345&[email protected]

Forgot to note, 14.13.3 works fine.

Can’t you guys just document the hooks better for us? We shouldn’t have to go hunting for these things.

Is there going to be a point in time where if we don’t have the add_action method then the old my_cforms_action will stop getting called altogether? I have already converted the my-functions.php file to a plugin, but you hadn’t introduced the add_action method yet when I did that step.

I’ve searched with grep for do_action and apply_filter. Most are related to comments. I see the cforms2_after_processing_action in the lib_nonajax.php script.

What I don’t see are replacements for custom form validation functions. One thing I was able to do before was to do a rudimentary check for spammers. I’d validate fields like phone to make sure no letters were used…I’d validate first and last name to make sure they weren’t the same values…(both of these these spammers do a lot) I was able to use the my_cforms_logic for this. (admittedly it was ugly but it worked. If I detected spam I’d just set the adminTo to a dummy address and set the error message to something like “go away spammer”

I just experienced this same issue. The problem is they’ve completely changed how this works. It doesn’t auto look for cforms-custom anymore. It expects you to make a plugin out of your my-functions.php file. The instructions are not very clear really. I was able to get the gist of what they wanted with the new method though.

What I did was renamed my-functions.php in cforms-custom to cforms-custom.php.

I then put this at the top of my new cforms-custom.php
/*
* Plugin Name: cforms2 custom handler
* Description: some description
*/

Then go to the plugins admin. You will now see a new plugin called cforms2 custom handler. Enable it.

Your custom code should now work.

As an aside to the new devs…This was a horrible thing to do. You completely killed backwards compatibility and if someone had auto update turned on, they’d likely not figure out their custom code wasn’t working for quite some time.

What was the downside to the old method? What is the upside to this new method?

Luckily I figured this out the hard way on a site in development. I have started using the new plugin tho as a replacement to the original. I’m just lucky I’ve only used it on a couple sites and I haven’t upgraded to 14.9 which broke the old functionality.

I know this is way too late but I’ll reply here in case someone else has this issue.

there is a way to do this in linux IF you have shell access to the server. It involves using the ‘find’ tool and the ‘sed’ tool.

However, it is NOT for the faint of heart. You really need to know what you are doing at the server level.

this is a simple example..

find . -name “*.php” -print | xargs sed -i ‘s|words to find|replace with (can be blank)|g’

You would run that from the /home/ directory. It would recursively find all files on all user accounts that are .php files…would then do the replacement

It is a good idea to backup before attempting this sort of thing.

For the advanced coder, sed is a regular expression capable engine. So you could do sed -i ‘s|<script>.*</script>||g’

one way to test this before throwing it at the whole filesystem is to run sed by itself on a single file.

sed -i ‘s|replaceme|withme|g’ testfile.php

then you can make sure it works and does the job before going global.

Lots of resources exist on this..just search google for ‘find and sed’

obscurity isn’t total security. But obscurity would make these bots jobs a whole lot harder if not impossible. This in turn makes you more secure. (and saves resources)

We’ve got to do something about these bots. WordPress install already has an option for db table prefix names. Why not give us the ability to customize the wp-admin and wp-login.php names as well? these settings would become part of wp-config.php

It complicates the install a little bit, but the protection it offers seriously outweighs the downsides of a couple more steps during the install. (renaming the wp-admin folder and wp-login.php file…not exactly hard. certainly easier than setting up a dbase)

I’m willing to have this be an optional thing…but the wordpress world would be better off if it was forced on new installations and made widely known to the wordpress world for existing installs.

First, I really appreciate the 2 of you chiming in. While it may be a touchy subject, it should be one that is constantly addressed.

Security vs resource consumption: The fact that wordpress is inherently open to brute force attacks makes it insecure. This is probably true of any CMS. My main point is that it is high time something be done about it. even if its extreme measures. Is my main motivation for this thread resource consumption? Very much so yes. I actually have almost no concern for someone actually getting into one of my sites as I enforce very strong passwords. But my concern for resource consumption leads to this broader topic of security.

The elephant in the room is proxy style attacks and botnets. Normal BFD detection just doesn’t work on that. I’m sitting watching a server right now. There have been 62 different ip addresses hit a wp-login page on different sites in the last 5 minutes. (I’m sure they aren’t legit users based on behavior and knowing my user base) These bots seek out anyone regardless of popularity with the main goal of getting in and putting spam links up on every post.

And no, a plugin just doesn’t work. Whatever the solution is, it should be default behavior. It would go a long way into making every installation better without the need for a installer to learn about hardening a wordpress install.

If we keep the attitude of making it a plugin, this problem will NEVER be solved.

Probably one of the easiest solutions would be to not have it called wp-admin or wp-login.php. Custom name per install. Yes there is a plugin that does this but again, this should be a core feature. This idea has been around forever. I see posts on www.ads-software.com that are 7 years old that suggest this exact idea. To me, this screams that the WP team isn’t listening.

I just want this to be a debate and I want the team to acknowledge it in some manner. Seeing as they run wordpress.com, surely this affects them to a much much larger degree than it does little ole me.

While I’m sure they take security seriously, I don’t understand why there are still things that I had to heavily research to learn how to stop/prevent. This stuff should be standard.

Having a theme/plugin editor built into the backend only encourages folks to apply bad permission levels. I’ve seen plenty of hacked sites where they had chmodded the theme folder to 777 just so they could edit in wp-admin.

Is it a nice feature? for some sure it is. But it leads to bad security. Why not make the theme editor and plugin editor available via a plugin if we are arguing for everything to be a plugin? Why not make the xmlrpc script a plugin?

ha..ya my username sure is my email…thanks. I don’t think it used to be like that. Or i just didn’t care. I like signing up for usernames as my email as its far easier to remember. But that raises a point. Display name SHOULD NOT default to username!!! The wordpress install page should ask for a name. Is it easy enough to change, sure. The problem is most people don’t.

Still, my username is a semi secret. IF I’m not displaying it anywhere. On our installs we don’t print the author names on posts/pages. We also disable ?author=X via a mod rewrite rule. The wordpress built in handling of author= is a security hole and it really needs to be plugged.

Brute force attack scripts have begun checking for ?author=X to find out the username of author=1. They do this since its becoming semi normal for people to not use admin as a username.

As for brute force detection. As far as I can tell, it is impossible to stop the brute force attacks that use proxy services in their attack. I already do brute force protection at a server level. But that only stops folks who try from a single ip address. The proxy based attacks never try from an ip address more than 2 or 3 times. So mod_security, fail2ban, BFD, all are useless in these cases. And this type of attack is more normal today than a hacker trying from the same ip address. You can’t set a failed threshold that low as real users would be hurt by it. I have tried to do this and even a setting of 10 failed attempts within 3 minutes has lead to several customers complaining that they’ve been locked out.

The question is, what can wordpress do to make logging in more secure? Yes, that is a truly loaded question but one that I think needs to be explored. WordPress’s poor focus on security is what has brought us here. It’s lack of user awareness and security holes of the past have made it a prime target. (and the fact that it reached critical mass)

– would captcha on wp-login.php be one deterrent or can bots bypass this now?
– would a anti-bfd ip list service that wordpress could check (similar to spamhaus for anti spammers) be a way to stop this? key here is that it would be a service that collects ip addresses of failed logins from wordpress installs around the world. It’s threshold would be relatively high and it should only flag abusers if they’ve hit more than one wordpress site. (this is key to avoid banning real users who simply forget their password and perform several failed attempts)

any other ideas. The wordpress dev team is not stupid. It just feels like they haven’t focused on this at all aside from putting up a couple pages on www.ads-software.com.

The key here is that it shouldn’t be a plugin. WordPress needs to be improved at its core to put an end to this. People who update to the latest version should be auto protected. The option to disable any new security methods could be provided if need be.

and yes, I mean a .htaccess rule by default should stop php/cgi from executing in the uploads dir. I do this in a server wide apache config. It is meant to stop these scripts that get installed into a uploads folder via a insecure theme or plugin.

and while I’m at it, directory permissions is something that should be enforced by wordpress. 777 on the themes folder is the worst offender. I’ve helped many people who have come to me saying they got hacked and the first thing I find is an editable themes/plugins folder. The only way to edit these things should be via ftp. It doesn’t matter that ftp might be a bit much for some folks. But when it comes to security, we should be secure first and user friendly second.

xmlrpc may be required by some 3rd party tools. but it is a major attack vector. Before I added a server wide apache config directive to make xmlrpc a 404, I was seeing constant attacks on it.

These attacks cause huge server load issues even on very good servers. I shudder to think what big shared hosting companies have to deal with because of this.

I freely admit that I’m not a security expert. I do what I can with my servers and I’ve done alright. I would really like to see smarter people address this issue via the wordpress core code. It shouldn’t be a plugin as the majority of folks out there won’t hear about it. And if the wordpress team really wants to make it a plugin, it should be like the akismet plugin. Meaning, provided by default letting us enable or not. Though, I really think it should be enabled by default to protect users.

the other problem with db logging ip’s is that it still creates heavy server load. These bots will attack many many times a minute from many many ip’s. They can bring a dedicated server load pretty high due to constant db selects.

the default wordpress robots.txt file should only be

User-agent: *
Disallow: /wp-admin/

This will keep any site that has a theme or plugin that makes use of js files provided by wordpress (like jquery) from being blocked by googles indexer.

So I’m seeing no feedback from wordpress folks. I’m beginning to think this is a HUGE HUGE deal.

We have been investigating the crawls on several of our sites. The number of indexed pages has dropped like a rock and the number of “blocked by robots” has increased from zero to several hundred on many many sites.

We fixed a robots.txt file on one and the problem went away with the next crawl and we are seeing pages get indexed again.

Someone on the wordpress dev team seriously needs to see this post.

I’ve got a client that is experiencing the same issue. The problem appears to be that a sudden burst of traffic occurs that completely clobbers mysql. Funky thing is that there isn’t a real visitor burst in stats. I’m still researching this though.