[wp-hackers] wp-denyhost

[Alexander Beutl]

Good thoughts.

> one can use a php-accelerator like xcache
yep but that isn't something a plugin has to deal with. Code optimization
and stuff has nothing to do with the benefit you can gain with such stuff -
anyway you will not have this with shared hosting wich is where most WP
Blogs are.

>Relying on these files it a very bad behavior for a "program" that is
written in a language like PHP
Who says anything about relying upon it? I ment after X Spammy-Comments
WordPress will be loaded again from the same IP Adress. In the 'init'-Hook
the Plugin blocks access and adds a new deny rule to .htaccess. If
htaccess-option is turned off it wouldn't do this anyway. So it will block
it in the init section everytime it isn't stopped by .htaccess. The only
thing I said is: Blocking it at that - directly via WordPress accessable -
level will stop php parser from having to load and will stop php to go until
running the init-hook and the specifical plugin is called.

But coming back to your server:
When this script would add the stuff to .htaccess this would result in no
difference at all to *not* adding it there because it would block the
connections with php anyway.

If you say writing a lightweight script:
Where would you like to add that? In index.php as the first line would work
- any later point is everything but not leightweigt.

Yes there are many different Servers around, and maybe you can not write a
plugin to fit them all perfectly but for each server one could write one
plugin fitting it perfectly well. Anyway: Stuff which will require an extra
deamon will be a bit of an overkill with the spam of today. If spammers
start visiting your page every 2 sec's or whatever this will of course be an
issue to be discussed but today it really isn't that bad as far as I know.


2008/4/18, Volkmar Seifert <vs at nifelheim.info>:
>
> Hello all.
>
> After reading the whole thread, here now my two cent and thoughts on the
> topic...
>
> First of all, I think that this plugin is a great idea. I am using
> something  like that (with a similar name ;) ) for protecting my sshd.
>
> The usage of .htaccess-files limits and binds you to apache. But there are
> alternative and mostly even more efficient web-servers around, and many of
> them don't bother with .htaccess-files. Relying on these files it a very
> bad behavior for a "program" that is written in a language like PHP which
> implies a certain independence of architecture and system. Especially when
> talking about software like web-servers, the freedom of choice should be
> encouraged, and I do not talk about the freedom of choice about using or
> not using the plugin, but the freedom to use any web-server I want or
> need.
>
> Myself, I am using lighttpd as a webserver, and it doesn't care about
> .htaccess. There are no possibilities of on-the-fly blocking by using any
> kind of server-configuration-file that is read upon access to a certain
> directory. lighttpd reads its config upon startup, and then never again.
> This approach has advantages as well as disadvantages and might be
> discussed elsewhere, but considering the current discussion-thread,
> webservers like this should not be ignored. Especially, when thinking
> about high-load web-servers, which very often use alternative web-servers.
>
> These web-servers are left with two choices:
>   - Using PHP for blocking, which would work on any web-server supporting
>    PHP.
>   - using /etc/hosts.deny for those, who use tcpwrappers, which are
> probably
>    only a few.
>
> For those servers who can make use of /etc/hosts.deny, a way needs to be
> found to access that file, since hopefully the web-server- and
> php-processes are not allowed to do that. A separate daemon could this,
> which would have the responsibility of removing the addresses again,
> whenever they approach the "ttl". This would even be faster than the
> .htaccess-method, as hosts.deny would result in a "connection refused"
> message - as if there would be no server listening on the requested port.
>
> For those requiriung the use of PHP for blocking, a lightweight-script
> should probably be used, as it has already been discussed in this thread.
>
> Some ideas for such a lightweight-script:
>
> - To avoid the php-parser to run, one can use a php-accelerator like
> xcache.
>   It caches the compiled version of a php-script and uses that whenever it
>   is accessed without being changed on disc in-between. As it is a
>   php-plugin, it works transparently on any web-server-software.
>
> - Having several php-processes already in-waiting for serving request,
> e.g.
>   by using something like fastcgi or similar
>
> - Using memcached for storing the ip-adresses.
>   memcached can be used to store and retrieve the ip-addresses faster as a
>   database, and it has the advantage of sitewide-availability, which is a
>   bit more difficult to achieve by direct database access. While this is
>   irrelevant for a standard WordPress installation, WordPress MU
>   installations would benefit from quite a lot.
>   To ensure the lightweightness, the connection-information for the
>   memcached-access could be needed to be provided directly into given
>   variables in the first few lines of the script.
>   This, of course, needs to be sufficiently documented in the
> install-docs,
>   and could only be done by a site-admin.
>
> - Volkmar
>
>
> --
> http://blog.nifelheim.info/tech
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>