TYPO3 Core

have you tried to empty the be_session table (via phpmyadmin)?

i tried creating a new admin user through the install tool, no effect.
However i'm not so familiar with mysql/phpmyadmin that i want to play around with manually editing tables. Maybe if you can tell me what this emptying of this table will do I'll give it a try (how exactly does one do this?).

I spotted a problem with the cookies at the backend login. Get sure register_long_arrays is enabled.

TYPO3 should also work with register_long_arrays = off, so it would be great if you could spot the exact line in which TYPO3 makes use of the long array instead of the $_SESSION... etc. superglobals.

Even better if you could supply a patch fixing all usages of long_arrays.

cheers
Ingmar

The BE login has been reworked in newer versions.

Since there was no feedback for more than four years(!) now, I think that this is also solved for the reporter and so propose to set this to "Won't fix".

While I basically agree, I think this should be solved the right way and Typo3 should get rid of HTTP_*_VARS usage.

typo3/init.php contains $HTTP_GET_VARS = $_GET (and similar for $_POST) - this is probably a workaround. OTOH, it won't make the HTTP_*_VARS available inside classes and functions.

I just grepped through the 4.3.3 code base:
grep -ri "HTTP_.*VARS" .

There aren't too many results, so it should be possible to get rid of the HTTP_*_VARS in the core quite quickly (extensions might be another story, but well, they shouldn't access those vars directly ;-)

Files that include HTTP_*_VARS are (not listing those that only do the workaround described above):
typo3/mod/tools/em/class.nusoap.php
typo3/sysext/cms/tslib/class.tslib_content.php
typo3/sysext/cms/ext_tables_static+adt.sql
typo3/sysext/t3editor/tsref/tsref.xml
typo3/sysext/css_styled_content/static/v*/setup.txt
typo3/sysext/css_styled_content/static/setup.txt
t3lib/class.t3lib_matchcondition.php
t3lib/class.t3lib_tsparser_ext.php
t3lib/matchcondition/class.t3lib_matchcondition_abstract.php (warning: $k will contain HTTP_*_VARS)
misc/phpcheck/reference.html
misc/phpcheck/incfile.php

Sorry for not providing a patch, but in some cases (especially in the non-PHP files like XML or Typoscript) I'm not sure if a change to $_GET and $_POST is the correct solution.

I just grepped the source. The only point where HTTP_[POST|GET]_VARS is really used, is here:

./typo3/sysext/cms/tslib/class.tslib_content.php:                       if ($conf['locationData']=='HTTP_POST_VARS' && isset($_POST['locationData']))   {
./typo3/sysext/cms/tslib/class.tslib_fe.php:                    $GLOBALS['HTTP_POST_VARS'] = $_POST;
./typo3/sysext/cms/tslib/index_ts.php:  $HTTP_POST_VARS = $_POST;
./typo3/sysext/css_styled_content/static/setup.txt:     locationData = HTTP_POST_VARS
./typo3/sysext/css_styled_content/static/v3.8/setup.txt:        locationData = HTTP_POST_VARS
./typo3/sysext/css_styled_content/static/v3.9/setup.txt:        locationData = HTTP_POST_VARS
./typo3/sysext/css_styled_content/static/v4.2/setup.txt:        locationData = HTTP_POST_VARS

I don't know, what locationData means. We should get rid of it and then remove the definition of $HTTP_*_VARS = $_*

The other occurance are only some CSH texts or so.