Bug #58029: 6.2.1: TYPO3\CMS\Core\Authentication\AbstractUserAuthentication tries to call header() in CLI context - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #58029

closed

6.2.1: TYPO3\CMS\Core\Authentication\AbstractUserAuthentication tries to call header() in CLI context

Added by Gabe Blair over 10 years ago. Updated about 6 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Target version:

next-patchlevel

Start date:

2014-04-17

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

6.2

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

Starting in 6.2.1, if you try using the CLI dispatcher (assuming you've got your BE user set up, etc.), e.g.:

typo3/cli_dispatch.phpsh scheduler

... you get something like this back (markup removed for clarity:

caller: TYPO3\CMS\Core\Database\DatabaseConnection::exec_INSERTquery
ERROR: Column 'IP' cannot be null
lastBuiltQuery: INSERT INTO sys_log (userid,type,action,error,details_nr,details,IP,tstamp,workspace) VALUES ('0','5','0','1','0','Core: Error handler (BE): PHP Warning: Cannot modify header information - headers already sent by (output started at /Users/gblair/src/hammer/Source/typo3conf/ext/t3site/ext_tables.php:429) in /Users/gblair/src/hammer/Source/typo3_src/typo3/sysext/core/Classes/Authentication/AbstractUserAuthentication.php line 493',NULL,'1397760691','-99')
debug_backtrace: TYPO3\CMS\Core\Core\Bootstrap-&gt;initializeBackendUser#57 // TYPO3\CMS\Core\Authentication\AbstractUserAuthentication-&gt;start#1000 // header#493 // TYPO3\CMS\Core\Error\ErrorHandler-&gt;handleError# // TYPO3\CMS\Core\Error\ErrorHandler-&gt;writeLog#147 // TYPO3\CMS\Core\Database\DatabaseConnection-&gt;exec_INSERTquery#200 // TYPO3\CMS\Core\Database\DatabaseConnection-&gt;debug#215

Looks like AbstractUserAuthentication::start() tries to send HTTP headers, which throws an exception (or warning, maybe?) that can't be logged because user has no ip address (a different can of worms?). A quick check for CLI context before sending header() output seems to do the trick to work around this. I'll see if I can get a patch submitted.

Actions

Copy link

Updated by Gerrit Code Review over 10 years ago

Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/29554

Actions

Copy link

Updated by Gabe Blair over 10 years ago

Ernesto, I hope you don't mind me adding you as a watcher to this. I'm not sure who to pick as a reviewer in Gerritt...perhaps you can suggest someone?

Actions

Copy link

Updated by Christian Kuhn over 10 years ago

this is a regression from 6.2.0? could you confirm?

Actions

Copy link

Updated by Gabe Blair over 10 years ago

Thanks. I started noticing it immediately after trying the upgrade to 6.2.1, but I'm going to check out the 6.2.0 tag and double-check. I'll let you know what I find out.

Actions

Copy link

Updated by Kasper Ligaard over 10 years ago

If it helps narrowing down the problem: I have had this problem since 17. March (According to my CI-server build log); this error wasn't there on the build done 11. March.

Actions

Copy link

Updated by Gabe Blair over 10 years ago

I played around a bit, and determined with a little more detail the behavior: it is indeed new for 6.2.1, and it only occurs if "System caches" are flushed prior to running cli_dispatch.phpsh.

$ cd typo3_src
$ git describe --tag
6.2.0
$ cd ../
$ typo3/cli_dispatch.phpsh scheduler
    [NO ERROR]
$ typo3/cli_dispatch.phpsh cleartypo3cache all [DataHandler cache clearing script]
$ typo3/cli_dispatch.phpsh scheduler
    [NO ERROR]
$ cd typo3_src
$ git checkout TYPO3_6-2-1
Previous HEAD position was 4924c9e... [RELEASE] Release of TYPO3 6.2.0
HEAD is now at 4707e42... [RELEASE] Release of TYPO3 6.2.1
$ cd ../
$ typo3/cli_dispatch.phpsh cleartypo3cache all
$ typo3/cli_dispatch.phpsh scheduler
    [ERROR HERE, assuming cache has been cleared]
$ typo3/cli_dispatch.phpsh scheduler
    [NO ERROR]
$ typo3/cli_dispatch.phpsh cleartypo3cache all
$ typo3/cli_dispatch.phpsh scheduler
    [ERROR AGAIN]

You'll notice in my sample I used a cache clearing CLI script for illustrative purposes. The problem also manifests if you instead "Flush system caches" from the TYPO3 back end.

So, my submitted patch may be just a band-aid solution? At any rate, it seems to solve the problem -- what do you guys think?

Actions

Copy link

Updated by Christian Holzmann over 10 years ago

FYI: This is also happening to me in TYPO3 6.1.8!

Gabe Blair wrote:

Starting in 6.2.1, if you try using the CLI dispatcher (assuming you've got your BE user set up, etc.), e.g.:
[...]

... you get something like this back (markup removed for clarity:
[...]

Looks like AbstractUserAuthentication::start() tries to send HTTP headers, which throws an exception (or warning, maybe?) that can't be logged because user has no ip address (a different can of worms?). A quick check for CLI context before sending header() output seems to do the trick to work around this. I'll see if I can get a patch submitted.

Actions

Copy link