I think I know why CAPTCHA images are broken

Hi Greg,
I have the same problem and the captcha images are broken. It′s really nice to hear someone fix the problem.
I don′t know anything about write code, could you send us your .htaccess in order I can try use the syntax?
Thanks a lot

Hi Vadanic – My .htaccess won’t do you any good because I did all my protecting using the httpd .conf files. I’ll paste both of them in below. Here’s what I did for my .htaccess file – I just commented everything out.

[root@www wpcf7_captcha]#
[root@www wpcf7_captcha]# pwd
/usr/share/wordpress/wp-content/uploads/wpcf7_captcha
[root@www wpcf7_captcha]# ls -al
total 12
drwxrwxr-x. 2 apache apache  47 Jan 20 10:44 .
drwxrwxr-x+ 5 apache ftp     48 Dec 22 00:06 ..
-rw-r--r--. 1 apache apache 112 Dec 22 20:08 .htaccess
-rw-r--r--. 1 root   root   102 Dec 22 19:55 .htaccess-disabled
[root@www wpcf7_captcha]# more .htaccess
##Order deny,allow
##Deny from all
##<Files ~ "^[0-9A-Za-z]+\.(jpeg|gif|png)$">
##    Allow from all
##</Files>
[root@www wpcf7_captcha]#

And here is what I did in my infrasupport.conf file. It turns out, there are other plugins and pieces that need special permissions on other files and directories. And near as I can tell, these aren’t documented anywhere and there’s no consistent guidance on how to do them. So every single plugin may have similar issues. My workaround will not be universal.

[root@www conf.d]# pwd
/etc/httpd/conf.d
[root@www conf.d]# ls
autoindex.conf  infrasupport.conf  perl.conf  README      ssl.conf      webalizer.conf  wordpress.conf
BackupPC.conf   manual.conf        php.conf   squid.conf  userdir.conf  welcome.conf
[root@www conf.d]#
[root@www conf.d]#
[root@www conf.d]# more infrasupport.conf
##<VirtualHost www.infrasupport.com:80>
<VirtualHost *:80>
    ServerAdmin [email protected]
    DocumentRoot /usr/share/wordpress
    ServerName www.infrasupport.com
##    ErrorLog  "/usr/share/wordpress/logs/error_log.log"
##    CustomLog "/usr/share/wordpress/logs/access_log.log" combined

Alias /wordpress /usr/share/wordpress

<Directory /usr/share/wordpress>
  #
  # Directives to support Permalink settings by post name instead of the default.
  # See Settings...Permalinks.
  #
  <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
  </IfModule>

  AllowOverride Options
  <IfModule mod_authz_core.c>
    # Apache 2.4
    ##Require local
    Require all granted
  </IfModule>
  <IfModule !mod_authz_core.c>
    # Apache 2.2
    Order Deny,Allow
    Deny from All
    Allow from 127.0.0.1
    Allow from ::1
 </IfModule>
</Directory>

<Directory /usr/share/wordpress/wp-content/plugins/akismet>
  <FilesMatch "\.(php|txt)$">
    Order Deny,Allow
    Deny from all
  </FilesMatch>
</Directory>

#
# Need this for the ReallySimple CAPTCHA plugin
#
<Directory /usr/share/wordpress/wp-content/uploads/wpcf7_captcha>
  Order deny,allow
  Deny from all
  <Files ~ "^[0-9A-Za-z]+\.(jpeg|gif|png)$">
    Allow from all
  </Files>
</Directory>

<Directory /usr/share/wordpress/wp-admin>
##  AllowOverride Options
  AllowOverride All
  <IfModule mod_authz_core.c>
    # Apache 2.4
    ##Require local
    Require ip 10.10.10
    ##Require all granted
  </IfModule>
  <IfModule !mod_authz_core.c>
    # Apache 2.2
    Order Deny,Allow
    Deny from All
    Allow from 127.0.0.1
    Allow from ::1
    Allow from 10.10.10
  </IfModule>
  <Files "admin-ajax.php">
    <IfModule mod_authz_core.c>
      # Apache 2.4
      Require all granted
    </IfModule>
    <IfModule !mod_authz_core.c>
      # Apache 2.2
      Order Deny,Allow
      Allow from All
    </IfModule>
  </Files>
</Directory>

</VirtualHost>
[root@www conf.d]#

Just ran into this same issue on a wordpress install hosted on DigitalOcean. Ended up just commenting out the lines in the htaccess file and going from there. Definitely a frustrating problem. Thanks to the OP for saving me a few hours of digging around!

I am running the same version of wordpress on two different folders on the same server. Both are running Contact Form 7 and this plugin. Both folders have the same permissions. One site has a working captcha, and the other isn’t showing an image. The only difference between the two is the theme. Not working: https://www.toledohomesinspectionshousesinspectors.com/

Working: https://www.brintelectric.com

Any suggestions would be appreciated. Thanks.

For vigorwebsolutions – just now saw this – thanks for the kind words!

For spaycanjil11 –
Just taking a stab in the dark – in the non-working one, what do the permissions look like on the file,
https://www.toledohomesinspectionshousesinspectors.com/wp-content/uploads/wpcf7_captcha/664484767.png

Do you have a way to do a tail -f on your httpd error_log and watch it in one window as you open the Contact page? That’s what led me to my clues.

– Greg Scott

I had this problem as well, and it turns out that if you are running Apache 2.4, the “Order” directive has been phased out in favour of a different way of specifying allow/deny.*

Here’s what works for me, using Apache 2.4:

<Directory "/var/www/mysite.com/wp-content/uploads/wpcf7_captcha" >
     Require all denied
     <FilesMatch "^[0-9A-Za-z]+\.(jpeg|gif|png)$">
          Require all granted
     </FilesMatch>
</Directory>

I put that in the per-site .conf file in /etc, and then commented out everything in the .htaccess file in /var/www/mysite.com/wp-content/uploads/wpcf7_captcha. If you’re in a shared hosting environment, YMMV.

(* If you want to read up on the details of the change in Apache 2.4, here’s a link. Look under “Access Control”.)

Could you help me?

I moved my site to new server and find out a common problem – captcha images don’t show.

My temporary folder has still the same path as before migration: wp-contents/uploads/wpcf7_captcha. GD and FreeType PHP libraries are installed on my server.

Of course I tried to change permissions:

Order Allow,Deny
<FilesMatch "^[0-9A-Za-z]+\.(jpe?g|gif|png)$">
Allow from all
</FilesMatch>

No result.

Later on I tried to install other captcha plugins. It helped – I could see images but I couldn’t send any message. Clicking on submit button caused an error “your message could’t be send”.

I’d be grateful for some advice. My website

For Gombroo – Per the post from AngelaNorton above, do you know what version of Apache is running on your web host? If version 2.4, try her suggestion to change your .htaccess file. The .htaccess file the plugin generates has a syntax error – that was the root of my problem. And even doing the captcha image by generating a tmp file seems like a questionable design decision in the first place, just because of all these issues. But it’s easy for me to complain from the sidelines, not so easy to build this stuff.

– Greg

@gregscott I’ve asked server admin and he wrote me that my site runs on modified version of APACHE IdeaWebServer due to https://phpinfo.home.pl/.
@angelanorton do you knonw how to manage this problem?

OK, so it’s a modified version of Apache. Modified from what original version? If it’s modified from version 2.4 then try the suggestion from AngelaNorton.

Will your server admin let you look at the file named error_log when you test that captcha? That might also give some clues.

Or… Maybe just try formatting your .htaccess file per AngelaNorton’s suggestion and see what happens.

– Greg

I have a similar problem … I know what is happening but I cant fix

I run a Debian style multi-site server
which is a little different from the wordpress multisite.

What is happening is that the captcha data is being written to a file in /srv/www/wp-content/domain name/uploads/wpcf7_captcha

while when rendering the page apache is looking for the file in
/usr/share/wordpress/wp-content/uploads/wpcf7_captcha …. which does not exist

My rules are written into the individual website virtualhost conf files
Perhaps someone can suggest what I need to add

What if you did a hack with symbolic links? Something like

ln --symbolic /srv/www/wp-content/domain name/uploads/wpcf7_captcha /srv/www/wp-content/domain name/uploads/wpcf7_captcha

ok I can do a symlink like this which works
ln -s /srv/www/wp-content/domain name/uploads/wpcf7_captcha /usr/share/wordpress/wp-content/uploads/wpcf7_captcha

however this excludes any other domains from using the plugin

I maintain a set of plugins and themes that are available to all however something I have done recently seems to have broken the individual sites access to their own uploads directory except when editing … Possibly in making permalinks work … can/t understand the rewrite module works correctly but apache is failing to go to the right directory

here is the my virtualhosts template

<VirtualHost *:80>
UseCanonicalName Off

ServerAlias DOMAIN
ServerName https://www.DOMAIN
VirtualDocumentRoot /usr/share/wordpress
DirectoryIndex index.php
Options All

#To Place wp-content in /srv/www/wp-content/$0
RewriteEngine On
RewriteRule ^/wp-content/(.*)$ /srv/www/wp-content/DOMAIN/$1
RewriteRule ^index\.php$ – [L]

# For permalinks to work
RewriteCond /usr/share/wordpress%{REQUEST_URI} !-f
RewriteCond /usr/share/wordpress%{REQUEST_URI} !-d
RewriteRule . /usr/share/wordpress/index.php [L]

<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>

#CustomLog /var/log/apache2/access.log vhost_combined

# this is needed when activating multisite, WP needs to to a
# fopen(“https://randomname.domain.com&#8221;) to verify
# that apache is correctly configured
php_admin_flag allow_url_fopen on

</VirtualHost>

I cheat with my stuff – I have 2 websites and each has its own virtual machine. If I did this in any kind of bulk, it wouldn’t scale, but I don’t have to solve any problems around shared hosting this way. I wonder how some of the other shared hosting sites do it?

I eventually solved the problem by adding two additional lines to my rewrite rules before the rule about wp-content

RewriteRule ^/uploads/(.*)$ /srv/www/wp-content/domain name/uploads/$1 [L,NC]
RewriteRule ^/wp-content/uploads/(.*)$ /srv/www/wp-content/domain name/uploads/$1 [L]

That seems to work without breaking permalinks etc
Still having an issue getting WP-Super-Cache to work but will spend time on that over the week-end