TOPIC: No captcha on 4.0

are the freetype and gd libraries installed?

where I need to check? I don't know 'em...

backend - > help -> system info

Is it ok in this way?

GD Support enabled
GD Version bundled (2.0.28 compatible)
FreeType Support enabled
FreeType Linkage with freetype

Can you give me a link to your web site. I want to see what error message the captcha is generating.

www.zonalibera.net

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, This email address is being protected from spambots. You need JavaScript enabled to view it. and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Can you find the server error log?

Where I could find it?

Your hosting plan should give you some kind of control panel such as cpanel or ispconfig?

I got those:

suexec policy violation: see suexec log for more details, referer: www.zonalibera.net/index.php?option=com_...rooli&catid=1:ultime

Premature end of script headers: captcha.php, referer: www.zonalibera.net/index.php?option=com_...rooli&catid=1:ultime

Aha!
Ok, that is a start, but I will need the help of your hosting support, since I'm not so into configuring servers.

here is a little information about alain.knaff.lu/howto/PhpSuexec/

You are running your web site in virtual host. Perhaps that is the reason why you get the next error message
Premature end of script headers: captcha.php, referer.

I don't know under what user the php script is executed:

Suexec functionality for PHP
On a standard Apache installation, suexec does not work for PHP, as PHP is implemented using a dynamically loadable module that runs within the context of Apache. All PHP scripts thus run under the same user as Apache itself runs as (www-data)

In order to allow users to safely execute PHP scripts, this paradigm must be changed: rather than using mod_php, user's PHP scripts should be executed via php-cgi. There are two steps necessary to make this happen:

1. Disable mod_php
2. Enable php-cgi

These 2 steps will be described in the next sections.
Disabling mod_php
The easiest method is to simply not install libapache2-mod-php5. However, php-cgi is less performant than mod_php and you might want to keep mod_php for safe system-wide web applications such as mediawiki, Horde/IMP, etc. Thus a solution is needed to only disable php for the users' home directories. This can be achieved using the following Apache config:

<Directory /home>
php_admin_flag engine off
</Directory>

Using php_admin_flag rather than simply php_flag makes sure that users can't re-enable php using their .htaccess file.
Enabling php-cgi
There are two ways to do it: suphp or suexec
Suphp
As of September 2008, the most recent released version of suphp does not yet support public_html. However, there is an unreleased snapshot that does:
www.suphp.org/download/suphp-SNAPSHOT-2008-03-31.tar.gz

Unpack this and compile it:

tar xfzv suphp-SNAPSHOT-2008-03-31.tar.gz
cd suphp-SNAPSHOT-2008-03-31
./configure --with-apxs=/usr/bin/apxs2 --with-setid-mode=owner
make
make install

and activate it by putting the following into Apache's config:

LoadModule suphp_module /usr/lib/apache2/modules/mod_suphp.so
<Directory /home>
AddHandler application/x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-php
suPHP_Engine on
</Directory>

and the following in /usr/local/etc/suphp.conf:

[global]
webserver_user=www-data
docroot=/var/www:${HOME}/public_html
check_vhost_docroot=false

[handlers]
;Handler for php-scripts
application/x-httpd-php="php:/usr/bin/php-cgi"

Please ask you hosting support to look into the problem. They should be of great help to us since they are competent in administrating web servers and I'm not

Now I' ve updated my php to 5.0 version, maybe something could change? At the moment, I don't receive more error logs...but it still don't works...

Well, you keep getting the internal server error.
www.zonalibera.net/components/com_commen...484ceef65a8700d34d0d

Could you check again the folder permissions and captcha.php permissions? (captcha.php should be 644)

permissions only for folders or "apply to enclosed items"?

now I read all the reports...little late delivery but all error logs, all the same problems... really too complicated... is it so dangerous for security use comments without captcha, but only for registred users? It's possible that some robots could pubblish register users and pubblish comments in this way?

try the following
components - 775
com_comment - 775
joscomment - 755
captcha - 755

captcha.php - 644

Basicly it is absolutly not dangerous to disable the captcha for registered users. You just have to make sure that there are no registered bots since they can post spam too

Using captcha with the registration can help (also don't forget e-mail account activation).

But please let us first make everything possible for the captcha to work.

Permissions are all right set, but still don't works... I don't know what else I could do...

can you try this one here: compojoom.com/forum.html?func=view&catid=10&id=2276#2288

How long should test? Is working from some minutes but nothing changes... still "Testing..."

Every time "Testing..." image and nothing else... Is it good or bad?