#2 — Perishable

Hmmm… good question. I will look into it..

#4 — Perishable

Lee,
If that works for you, great. Often, there are multiple ways of writing htaccess expressions. For example, here is the last line of the same htaccess code currently presented on the WordPress Codex:

RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

Further, here is the corresponding line we are currently using at Perishable Press:

RewriteRule ^(.*)$ ^http://www.google.com/$ [R=301,L]

..which has been working fine for quite a while.

Also, an absence of errors doesn’t necessarily translate into proper functionality. You should throw down with some tuf log action:

RewriteEngine On
RewriteLog /absolute/path/to/your/wwwroot/public_html/rewrite_log.txt
RewriteLogLevel 2

..to ensure that your syntax actually produces the desired results (i.e., blocking spambots, etc.). Either way, thanks for the information concerning your specific issue — it may prove beneficial to others experiencing the same type of error.

Cheers!

#6 — Perishable

Your specialness is obvious, danielle ;)

#8 — Perishable

My pleasure, Jenny — thank you for the feedback :)

#11 — Perishable

@Rick: Yes indeed, spam sucks — it’s like a perpetual cyberspace battle: spammers attack, bloggers defend themselves, spammers defeat the defenses and attack some more.. ad nauseam. As to the secret purpose of blocking empty user agents, I will never tell!

@a name: Beyond the pain of perpetual updates, I see no reason why such code would cause any issues — in fact, it seems like an excellent alternative to the htaccess method. Thanks for sharing :)

#14 — Perishable

Yes, that would be one way to do it. If you are allowing visitors to comment via proxy, you may want to test the method before implementation. It is really a double-edged sword, dealing with no-referrer requests: it is nearly impossible to avoid false positives and false negatives. Frankly, I have been contemplating removing the method described in this article. If so, it will be done as a test and I will report the results in a future post.

#16 — Jeff Starr

Hi Web Designer, I have never heard of the wp-comments-post.php file having any inherent blacklisting capabilities, but I have not investigated the file in newer versions of WordPress, so it may be the case. Another thing you could check is whether or not your “gigaturn” URL has been flagged as spam within the Akismet database. If you go to the site or Google for something like “remove site from Akismet” (or similar), you should find all the information needed to investigate and possibly remedy the issue. Good luck!

#19 — Jeff Starr

Perhaps I am confused as to what you are trying to do. Are you trying to post comments at gigaturn.com? Or are you trying to post comments on other sites using gigaturn.com as the commentator link? Or something else..? I guess I need more information as to what’s going on and where..

#21 — Jeff Starr

@balisugar: don’t cry! You should be able to deny requests for that specific query string by adding the following directives to your root htaccess file:

# BLOCK XXX.COM QUERY STRINGS
<ifmodule mod_rewrite.c>
   RewriteCond %{QUERY_STRING} xxx\.com [NC,OR]
   RewriteRule .* - [F,L]
</ifmodule>

Once in place, this code should block any query-string requests containing the character string “xxx.com”.

For more information on this technique, check out my article, Improving Site Security by Preventing Malicious Query-String Exploits.

#23 — Jeff Starr

@balisugar: My pleasure — happy to help! :)

#25 — Jeff Starr

@balisugar: htaccess and robots.txt perform two different functions. htaccess is responsible for per-directory configuration of various Apache server directives (such as rewriting, redirecting, and many others), while robots.txt directives merely instruct robots (such as Googlebot and Slurp) on how to go about crawling your site (which URLs to ignore, sitemap location, et al). Unfortunately, there are precious few robots that actually obey the directives specified in the robots.txt files, while they really have no choice but to follow the rules specified via htaccess files.

So, to answer your question, if you need to block a specific URL, referrer, or request, it is best to handle it via htaccess — robots.txt is the wrong tool for the job.

#28 — Jeff Starr

@Json: Yes you can use the REQUEST_URI variable to match just about anything in the request string, including individual files. The targeted string is a regular expression and will match any instance of itself within the requested URI. Something like this should work great:

RewriteCond %{REQUEST_URI} page-you-want-blocked\.php

To verify that it works, try loading the page directly in a browser. For more information on blocking with the REQUEST_URI variable, check out the fifth method in this article.