Bug #24765
closed
t3lib_userAuth::user_where_clause now protected - fatal error with simulatebe
0%
Description
TYPO3 4.5.rc1 gives a fatal error in the front end with simulatebe 2.0.0.
Front end error
Fatal error: Call to protected method t3lib_userAuth::user_where_clause() from context 'tx_simulatebe_pi1' in /home/typo3/public_html/typo3conf/ext/simulatebe/pi1/class.tx_simulatebe_pi1.php on line 74
Database Compare Wizard recomends an update even after update is applied
Changing fields
ALTER TABLE be_users CHANGE tx_simulatebe_feuserusername tx_simulatebe_feuserusername tinytext default '';
Current value: tinytext
- DEBUG SYSTEM INFORMATION - START ###
HTTP_HOST : www2.stmp.org
TYPO3_HOST_ONLY : www2.stmp.org
TYPO3_PORT :
PATH_INFO :
QUERY_STRING : TYPO3_INSTALL[type]=phpinfo
REQUEST_URI : /typo3/install/index.php?TYPO3_INSTALL[type]=phpinfo
HTTP_REFERER : http://www2.stmp.org/typo3/install/index.php?TYPO3_INSTALL[type]=database&TYPO3_INSTALL[database_type]=cmpFile|CURRENT_TABLES
TYPO3_REQUEST_HOST : http://www2.stmp.org
TYPO3_REQUEST_URL : http://www2.stmp.org/typo3/install/index.php?TYPO3_INSTALL[type]=phpinfo
TYPO3_REQUEST_SCRIPT: http://www2.stmp.org/typo3/install/index.php
TYPO3_REQUEST_DIR : http://www2.stmp.org/typo3/install/
TYPO3_SITE_URL : http://www2.stmp.org/
TYPO3_SITE_SCRIPT : typo3/install/index.php?TYPO3_INSTALL[type]=phpinfo
TYPO3_SSL :
TYPO3_REV_PROXY :
SCRIPT_NAME : /typo3/install/index.php
TYPO3_DOCUMENT_ROOT : /home/typo3/public_html/www2.stmp.org
SCRIPT_FILENAME : /home/typo3/public_html/www2.stmp.org/typo3/install/index.php
REMOTE_ADDR : 71.113.0.152
REMOTE_HOST :
HTTP_USER_AGENT : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.5
CONST: PHP_OS : Linux
CONST: TYPO3_OS :
CONST: PATH_thisScri: /home/typo3/public_html/www2.stmp.org/typo3/install/index.php
CONST: php_sapi_name: apache2handler
OTHER: TYPO3_VERSION: 4.5.0rc1
OTHER: PHP_VERSION : 5.2.6-3ubuntu4.5
imagecreatefromgif(): 1
imagecreatefrompng(): 1
imagecreatefromjpeg(: 1
imagegif() : 1
imagepng() : 1
imagejpeg() : 1
imagettftext() : 1
OTHER: IMAGE_TYPES : 15
OTHER: memory_limit : 256M
SERVER: SERVER_PORT : 80
SERVER: SERVER_SOFTW: Apache
SERVER: GATEWAY_INTE: CGI/1.1
SERVER: SCRIPT_NAME : /typo3/install/index.php
SERVER: PATH_TRANSLA:
T3CV_GFX: image_proc: 1
T3CV_GFX: gdlib : 1
T3CV_GFX: gdlib_png :
T3CV_GFX: im : 1
T3CV_GFX: im_path : /usr/bin/
T3CV_GFX: im_path_lz: /usr/bin/
T3CV_GFX: im_version: im5
T3CV_GFX: im_negate_: 1
T3CV_GFX: im_imvMask:
T3CV_GFX: im_combine: composite- DEBUG SYSTEM INFORMATION - END ###
(issue imported from #M17258)
- DEBUG SYSTEM INFORMATION - END ###
Updated by Georg Ringer over 13 years ago
this is a bug of the extension, not the core
Updated by Steffen Gebert over 13 years ago
#23438 (rev. 8681) introduced the protected statement for this method.
PHPDoc already stated before @access private. So this method was never deserved to be used by other classes.
Nevertheless, it could be removed again.. Xavier?
Updated by Xavier Perseguers over 13 years ago
Is there not another option? If phpDoc states from a very long time that this is private, then it is. If no other way exists to do this, then we may consider making it officially public but not without making sure it does not introduce a security flaw there...
Updated by Steffen Gebert over 13 years ago
I agree that change from @access private to visibilty protected is just logical.
Question is, how often it is used in wild.
Updated by Chris topher over 13 years ago
I also think simulatebe is the place to fix this.
Eric, this has already been reported for simulatebe here:
http://forge.typo3.org/issues/9578
I think we should go on there.
Updated by Oliver Hader over 13 years ago
The change was introcued as "cleanup" since the PHPdoc statet the private usage of that method. Thus, using the API wrong might have more negative side effects.
I share the opinion that this has to be fixed in the extension. At least the bug was reported 5 months ago in the tracker of the extension as Christopher pointed out.
Updated by Oliver Hader over 13 years ago
No change required, since extension should not call internal API methods (that it once worked is not an argument).