Bug #58029

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

Added by Gabe Blair about 7 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
Start date:
2014-04-17
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
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->initializeBackendUser#57 // TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->start#1000 // header#493 // TYPO3\CMS\Core\Error\ErrorHandler->handleError# // TYPO3\CMS\Core\Error\ErrorHandler->writeLog#147 // TYPO3\CMS\Core\Database\DatabaseConnection->exec_INSERTquery#200 // TYPO3\CMS\Core\Database\DatabaseConnection->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.

#1

Updated by Gerrit Code Review about 7 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

#2

Updated by Gabe Blair about 7 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?

#3

Updated by Christian Kuhn about 7 years ago

this is a regression from 6.2.0? could you confirm?

#4

Updated by Gabe Blair about 7 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.

#5

Updated by Kasper Ligaard about 7 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.

#6

Updated by Gabe Blair about 7 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?

#7

Updated by Christian Holzmann about 7 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.

#8

Updated by Gabe Blair about 7 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#9

Updated by Benni Mack over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF