TYPO3 Core

Is that the same as #17104?
What was the version you updated from? TYPO3 4.4.0? Did it work there?
Do you have safe mode enabled? --> #17104.

Update from running 4.4.0 - yes it worked there.
safe_mode disabled

no other changes to system today - only T3 update

and it's PHP-5.2.6 not 5.3 running on this system - sorry

Then one of the changes between these two versions broke it for you; as far as I see it, this could only be the recent security fixes.

You find old versions of the files here:
http://forge.typo3.org/projects/typo3v4-core/repository/show/branches/TYPO3_4-4/typo3/sysext/install/mod?rev=8139
Please download the files named class.tx_install.... and use them in your installation.
Does this prevent the error?

Attention: These old versions do NOT include the recent security fixes! Only use them for testing and replace them with the originals again afterwards!

This bug is also present in Typo3 Version 4.3.4

For 4.4.1 using the class_tx_install... files from revision 8139 prevents the error

I checked two of our installations on different servers.
Both (4.4.1) works as expected.

One installation has PHP 5.2.x and the other one is running on PHP 5.3.x
So I couldn`t reproduce this.

@ Klaus: Could you check which of the security fixes exactly caused this problem?

The critical revisions are:
class.tx_install_session.php was changed in revision 8367,
class.tx_install.php was changed in revision 8429 and
class.tx_install_ajax.php was changed in revision 8274.

Same Situation here: After updating to 4.1.1 theres no Login to Install Tool possible (tried from TYPO3 Backend and direct URL).

Typo3 4.4.1
PHP 5.2.14

Password is correct but it redirects to the Login Form.

Have you installed "ameos_formidable"? Manual disabling this extension in localconf.php makes the install tool work again. But i don't know why?

I can confirm this. I updated from 4.3.3 to 4.4.1 - no login possible (if I use a wrong password, I got the message with the hash value and so on, if I use the right one, the login screen is shown again (without the message)).
After downgrade to 4.4.0 I can login without any problems

PHP Version 5.2.9
MySQL 5.0.83
TYPO3 4.4.1
safe_mode off
Linux

If you need any more information, please let me know!

[EDIT]I do NOT have ames_formidable installed at all.[/EDIT]

reverting the change in revision 8367 fixes the problem

i also have the extension "ameos_formidable" installed, disabling it fixes the problem even with all security fixes

In my case, uninstalling ames_formidable also made the install tool login work again.

The problem is that ameos_formidable has in its ext_localconf.php:

if(!isset($GLOBALS["_SESSION"])) {
                        session_start();
                }

which starts a PHP session on every request (be it BE or FE). This conflicts with any other TYPO3 session, one of which is used by the install tool.

I am not sure why ameos_formidable needs its own _SESSION, but it might be better if it uses the TYPO3 session management, or only starting the session when really needed (in the frontend probably?).

Cheers,
Ernesto

A potential bugfix in ameos_formidable is wrap a:
if (TYPO3_MODE === "FE") {
}
around the session initialization in ext_localconf.php.

Same problem with 4.2.13 and 4.3.4, after update login to install tool is not possible.
PHP Version 5.2.11-pl1-gentoo
Edit: First update from 4.2.12 to 4.3.3 and then to 4.3.4 works fine, an update directly to 4.3.4 don´t work.

@ Christian, Basti and Markus:
Can you check, what causes this problem for you? (Might also be another extension...)

I reduced the extension list to the "default" localconf.php entry:
$TYPO3_CONF_VARS['EXT']['extList'] = 'tsconfig_help,context_help,extra_page_cm_options,impexp,sys_note,tstemplate,tstemplate_ceditor,tstemplate_info,tstemplate_objbrowser,tstemplate_analyzer,func_wizards,wizard_crpages,wizard_sortpages,lowlevel,install,belog,beuser,aboutmodules,setup,taskcenter,info_pagetsconfig,viewpage,rtehtmlarea,css_styled_content,t3skin';

And I still could NOT login to install tool :-(

[EDIT]And of course deleted the configuration cache...[/EDIT]

class.tx_install_session.php is the problem. After download it from the link above the login works fine in 4.4.1

I cannot reproduce this in a clean Install.
@Christian, @Freddy

Wild guessing:
$TYPO3_CONF_VARS['EXT']['extList']
might be multiple times in localconf.php, have you checked that?

how about
$TYPO3_CONF_VARS['EXT']['extList_FE']
anything special in there

Since it's all about cookies, can you please delete all cookies before trying again.

What browser are you using?

During testing I've had similar issues too, but all were solved after cleanly shutting down Chrome or other browsers and starting them again.
All google chrome share the session cookies, so if you leave just one open, it still might come to that problem.

Best would be to "reboot" your client PC and try again.

Also note which extensions you have active (in the Ext.Manager). Send us a list here, if it is still not working after the reboot.

I've posted to the FORMidable newsgroups about this.

In regard of ameos_formidable, this is clearly a severe bug in this extension,
doing a session_start() at this place. It leads to circumvention of
all security measures done in the install tool's session implementation
(seperate file in a "secret" path, session fixation precaution, regenerating of
session id etc.).

@Helmut:
yes, I checked that ALL 'extList' are commented out - including the extList_FE. I removed all CACHE Files in typo3conf. I removed all Cookies from the Browser. And I tested in Firefox, InternetExplorer and Safri.
As soon I link back to the 4.4.0 sources the install tool works without any problems. (don't need to clear any caches - just changing the symlink back to 4.4.0 and everything is fine)

The team in charge of formidable is working on this at this right moment. So far I've not been able to reproduce the bug in a fresh 4.4.1

What's the procedure to reproduce ? (funny fact: procedure is an anagram of reproduce, just noticed it ;)

Steps to reproduce (in my case):

1. install ameos_formidable 1.1.3
2. in the user settings, create the install tool file
3. click on "install" in the BE
4. enter your install tool password

expected result:
logged in, install tool options visible

actual results:
install tool login screen again (no message about an incorrect password)

@Christian: Thanks for testing!

Can you please post here what cookies are stored for your domain?

If I clear all cookies, the directly go to typo3/install/index.php, I only have on cookie named "Typo3InstallTool" e.g.:

Typo3InstallTool=<somerandomnumber>; path=/4-4/; domain=localhost

I case of formidable installed, I also have:
PHPSESSID=<anotherrandomnumber>; path=/; domain=localhost

• http://formidable.typo3.ug/svn/changelog/#c786
• http://formidable.svn.sourceforge.net/viewvc/formidable?view=revision&revision=420

I'm going to backport the bugfix to branch 1 as well; this should have been done in the first place anyway.

@Helmut:

with 4.4.1:
PHPSESSID
Typo3InstallTool

with 4.4.0:
PHPSESSID
(not InstallTool Cookie)

AND because this is another big thing in this Thread: no formidable installed!

First of all, this behavior is only on updated systems. I tried to reduce the extension list and on my local testserver one installation works fine, on the live server nothing happens. I will update more of my systems, to find out what extension will cause this behavior, hope so....

BTW: you can "hijack" the session:
1. use the 4.4.0 sources
2. login to install tool
3. change the source to 4.4.1
4. you are still logged in to the install tool

BUT: once logged out, you won't be able to login again :-(

@Freddy and @Christian. It might help the search if you scan for "session_start()" in all your typo3conf/ext/ files. Maybe you might find other extensions that do something like this?

@Ernesto:

-bash-3.2$ find . -type f -exec grep -l "session_start" {} +
./sr_freecap/pi1/freecap141.php
./phpmyadmin/modsub/index.php
./phpmyadmin/res/phpMyAdmin-3.2.5-all-languages/config.inc.php
./phpmyadmin/res/phpMyAdmin-3.2.5-all-languages/libraries/common.inc.php
./phpmyadmin/res/phpMyAdmin-3.2.5-all-languages/libraries/auth/signon.auth.lib.php
./phpmyadmin/res/phpMyAdmin-3.2.5-all-languages/libraries/auth/swekey/swekey.auth.lib.php
./phpmyadmin/res/phpMyAdmin-3.2.5-all-languages/libraries/session.inc.php
./phpmyadmin/res/class.tx_phpmyadmin_utilities.php
./sr_feuser_register/model/class.tx_srfeuserregister_data.php
./th_mailformplus/pi1/class.tx_thmailformplus_pi1.php
./t3quixplorer/mod1/geshi/php-brief.php
./t3quixplorer/mod1/geshi/php.php
./tipafriend_captcha/pi/class.ux_tx_tipafriend.php
./tipafriend/pi/class.tx_tipafriend.php
./pmtipafriend/pi1/class.tx_pmtipafriend_pi1.php

@Oliver:
I attached the bugfix to this ticket. Would you be kind enough to apply it and tell me if your install tool let you in again ?

On my test instance, it does.

Yes, the patch solves the problem for me (after deleting the typo3conf/temp_CACHED* files after applying the patch).

My problem is a serverproblem. 3 of 4 servers works as expected, so I try to find the bug with my provider.

@Freddy, check for permissions of typo3temp directory and its subdirectories (if the install tool is able to create and update files / directories there)

@Christian, can you somehow find out where the php session cookie comes from?

Btw. did you access the install too directly after clearing the cookies? If not please try to.

@Helmut: no idea how to find out?
Yes I did access the install tool directly after clearing the cookies.

@Christian, is it possible that you give me access to your installation so that I can do some debugging?
if so, just contact me via skype (helhum) or mail (helmut at typo3 dot org)

I got it!
The problem is the PHP setting "session.auto_start"
If this is set to "ON" - you cannot login to the install tool. If you set it to "OFF", the Install Tool works again!

If you need this setting to be "ON", you can change it for the subdir "typo3/install" to "OFF" and you will be able to login! :-)

@Christian: Ah, thanks for finding that out!
Probably we should show an error message, if the session already has been started:

if (defined('SID')) {
throw new Exception('Session has already been started by session.auto-start or session_start().');
}

thats it, thank you christian

@Helmut: I don't know if there isn't a way that it's still working? In older Versions of TYPO3 session.auto-start was no problem!?

BUT an error with a hint will be much better than just reloading the login form! ;-)

@Christian: Older TYPO3 versions were vulnerable to session fixation. There's no way to achieve a secure session handling, if a session is started before it is configured to be secure. session_autostart may be easy for small scripts but a no go fo bigger web applications imho.

Alright! Thanks to everybody for digging into the FORMidable thingy and the session.auto-start setting in PHP. Can somebody please create a patch that shows a warning to turn of session.auto-start if enabled? Thanks in advance!

@Olly: A die() is enough, or do we need some stylish error message here?

Attached a patch which adds a die() if session has already been started or session.auto_start option is detected

Thanks a lot Helmut!

I changed the message a bit and also added some templating in newer versions to make the message more user friendly. And I created the -v2 serie of patches for all releases.

Please test and give your comments on the core list, where I just posted a RFC for this.

attached new patches which uses Exceptions instead for 4.2 ot trunk

• TYPO3_4-1 (rev. 8473)
• TYPO3_4-2 (rev. 8474)
• TYPO3_4-3 (rev. 8475)
• TYPO3_4-4 (rev. 8476)
• Trunk (rev. 8477)

released in
4.1.15
4.2.14
4.3.5
4.4.2