Bug #21384

Warning issued on first load of install tool

Added by Christian Kuhn about 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2009-10-27
Due date:
% Done:

0%

TYPO3 Version:
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

On first load of the install tool from the BE interface the following warning is issued. This was introduced with 4.2.10

Warning: Invalid argument supplied for foreach() in /path/to/TYPO3_4-2-10/typo3/sysext/install/mod/class.tx_install_session.php on line 349

debug($sessionSavePath);
/path/to/typo3/instance/typo3temp//sessions123-some-long-number-456

debug(glob($sessionSavePath . '/hash_*'));
empty

The warning vanishes if the install tool is selected a second time (when a hash_* file is existing).

This also happens always if I change the installTollPassword on first load.
(issue imported from #M12371)

12371.diff View (803 Bytes) Administrator Admin, 2009-10-28 19:42


Related issues

Related to TYPO3 Core - Bug #21335: Knowing the md5 hash of the password, it is possible to gain access to the install tool Closed 2009-10-22

History

#1 Updated by Ernesto Baschny about 10 years ago

I am not able to reproduce that. The "hash_" file is created as soon as I first hit the install tool, so there is always one there. Even when changing the password, it creates a new "session*" dir and a hash_* file inside.

Could you try to figure out how you could reproduce that and give more detailed steps?

#2 Updated by Christian Kuhn about 10 years ago

The gc callback in session_set_save_handler() is called before the write callback. Thats the reason why sometimes no file exists at this point.

This is also mentioned in http://bugs.php.net/bug.php?id=35479

#3 Updated by Ernesto Baschny about 10 years ago

Ok, the problem is that glob() seems to be returning false in your case, while it returns an empty array for me in this situation, thus never entering in this warning situation.

What PHP version are you running and which OS?

php.net docs on "glob()" say:

"Returns an array containing the matched files/directories, an empty array if no file matched or FALSE on error."

and also "Note: On some systems it is impossible to distinguish between empty match and an error. "

So it might be easier to just make sure it is an array before continuing just to be safe. Please try attached patch (for trunk) to see if it fixes your problem.

#4 Updated by Christian Kuhn about 10 years ago

Yep, patch fixed this.

The system is a std. debian lenny php package (php5-cgi/lenny uptodate 5.2.6.dfsg.1-1+lenny3) with suhosin, reverse proxy, open_basedir and eaccelerator.

Reading http://bugs.php.net/bug.php?id=47358 there seems to be a problem with return value of glob() in open_basedir environments. This is probably the root of all evil and your patch happily takes care of this. Thanks :)

#5 Updated by Ernesto Baschny about 10 years ago

Thanks. Pending in the core list

#6 Updated by Ernesto Baschny about 10 years ago

Commited to
- trunk rev. 6297 (beta3)
- 4.2 rev 6298 (4.2.11)
- 4.1 rev 6299 (4.1.14)

Also available in: Atom PDF