After the upgrade the status report says that register_globals is enabled. However devel as well as manual php info vias info.php (tested in several folders) and the hosters admin backend tell me that register_globals is disabled. PHP Version is 5.2.5, Webserver: Apache/1.3.39 (Unix) mod_auth_pam/1.1.1 mod_fastcgi/2.4.6 mod_ssl/2.8.30 OpenSSL/0.9.8g mod_jk/1.2.25 FrontPage/5.0.2.2510

I'd be happy to track down this error myself, maybe I only need someone pointing me into a direction like "Drupal looks here if register_globals is enabled".

Thanks
protramper

Comments

s.daniel’s picture

s.daniel commented
Status: Closed (duplicate) » Active

Forgot to mention: Other drupal sites on the same (shared) account don't bring the error.

/edit: Thank you. Sorry didn't find the issue / didn't look propperly.

Tested the patch but the error remains.

webernet’s picture

webernet commented
Status: Active » Closed (duplicate)

http://drupal.org/node/209409

shardy1’s picture

shardy1 commented
Version: 5.6 » 6.12

Hello,

I've read all the entries for this problem, and it seems that the patch(es) created were integrated into Drupal 6.X. However, I'm still getting the following status report error :

register_globals is enabled. Drupal requires this configuration directive to be disabled. Your site may not be secure when register_globals is enabled.

Has anyone else had this problem recently? Any ideas how to solve it?

Thanks!

dddave’s picture

dddave commented
Status: Active » Closed (duplicate)

resetting

Larry Jones’s picture

Larry Jones commented
Version: 6.12 » 7.x-dev

Yes, same problem with drupal 7.0-dev, shared hosting (HG). I think this relates to having multiple php.ini files on the current path in a shared hosting environment. The default version at /usr/local/bin has register_globals ON. Within my account, php.ini sets register_globals OFF. Default PATH puts the shared libraries ahead of the user environment. Perhaps someone can point me to a better source of guidance for sorting out shared hosting environments for drupal use.

The problem: 

  [myname ~/public_html/drupal]$ drush updatedb
  register_globals is enabled. Drupal requires this configuration      [warning]
  directive to be disabled. Your site may not be secure when
  register_globals is enabled. The PHP manual has instructions for how
  to change configuration settings. (Currently using PHP register
  globals Enabled ('1'))
  No database updates required                                         [success]
  Finished performing updates.

Running phpinfo() outside drupal reports PHP Version 5.3.3, with
Configuration File (php.ini) Path /opt/php53/lib
Loaded Configuration File /home/name/php.ini
and also reports
register_global OFF

I cannot edit /opt/php53/lib/php.ini (with register_globals ON). I thought the php.ini inside my directory (with register_globals OFF) overrides it.

$PATH reports:
/usr/kerberos/bin:/usr/lib/courier-imap/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/myname/bin:

I apologize if I am posting this in the wrong place, but the problem is the same and I do not know where else to post.
Suggestions please?

s.daniel’s picture

s.daniel commented
Status: Closed (duplicate) » Active

The original issue is not relevant any more but to get yours some attention I set the status to active. Maybe you should open a new one.
Does this issue only relate to drush or also to admin/reports/status?

Sorry I can't be more helpful.

Larry Jones’s picture

Larry Jones commented

This appears to be a drush issue that appears under certain shared hosting environments. Admin/reports/status board is clear, all green. Prior posts in this thread report the problem in drupal versions 5.6 and 6.12; now seeing it in 7.x.

If anyone else stumbles on this thread with the same problem (drush reporting register_global is on, a security issue, but it's not), then focus on the various configuration files relating to your shared hosting environment. If I figure it out, I will add to this.

morbus iff’s picture

morbus iff
they/them
commented
Status: Active » Closed (fixed)

Drush is a command line PHP script and thus uses the command line PHP configuration files (often represented by php-cli.ini, but not always). A php.ini file stored in the Drupal directory will have *no effect* on command line scripts, as they are only intended for PHP-through-the-webserver configurations (usually handled by FastCGI, PHP as CGI, suPHP, etc., etc.). This is not Drupal specific, nor Drupal-version specific - if your command line PHP configuration does not shut off register_globals, and you have no access to do so yourself, you're stuck and need to contact your web host. Or, as above, you can just ignore it.

Resetting back to closed.