[CONFIRMED+FIX] Joomla! 1.0.13 Admin session dies for certain $task values

[jlleblanc]

Description:
Clicking toolbar buttons in the backend other than 'save' or 'apply' results in being logged out when using Joomla! hosted on IIS.

Reported on:
1.0.13

Affected functions:
initSessionAdmin()

Related files:
includes/joomla.php

Steps to replicate:
Install Joomla 1.0.13 on an IIS webserver, then log in to the backend. Click on Add New Content, then click Cancel. You will then be returned back to the login screen with the message "You need to login." I am not able to reproduce this on Apache.

Proposed fix(es):
$session_id is matching the md5 hash generated on line 771, but then we end up in the block where the old session is removed and a new session id is generated. Could it be that the session is destroyed and the browser is redirected before a new one is created?

System info:
PHP built On:  Windows NT ATOCAPP30 5.0 build 2195
Database Version: 5.0.41-community-nt
PHP Version: 5.1.4
Web Server: Microsoft-IIS/5.0
WebServer to PHP interface: cgi-fcgi
Joomla! Version: Joomla! 1.0.13 Stable [ Sunglow ] 21 July 2007 16:00 UTC
User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5
Relevant PHP Settings:
Joomla! Register Globals Emulation: OFF
Register Globals: OFF
Magic Quotes: ON
Safe Mode: OFF
File Uploads: ON
Session auto start: OFF
Session save path: D:\PHP\sessiondata
Short Open Tags: ON
Output Buffering: OFF
Open basedir: none
Display Errors: ON
XML enabled: Yes
Zlib enabled: Yes
Disabled Functions: none



Session configuration from phpinfo:

Session Support enabled
Registered save handlers files user
Registered serializer handlers php php_binary wddx

Directive Local Value Master Value
session.auto_start Off Off
session.bug_compat_42 On On
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 100 100
session.gc_maxlifetime 18000600 1440
session.gc_probability 1 1
session.hash_bits_per_character 4 4
session.hash_function 0 0
session.name 55e9073d3573b2d22a51f573877f72ed PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path D:\PHP\sessiondata D:\PHP\sessiondata
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0

Edit: added better system information and clarified that this problem does not occur on Apache.
Edit 2: added session configuration information from phpinfo.
Edit 3: changed topic heading, as this issue is experienced across platforms.

[Geraint]

This is a serious issue and makes the admin interface pretty much unusable.  By the way I am seeing this problem Apache 2.0.54 with PHP 5.2.3 running on a windows server.

Geraint

p.s. I posted a bug report on Joomlacode about session_id problems before 1.0.13 was released but it was not fixed

[edit : added server config]

[Geraint]

Some insights (and a fix?)

The problem arises if you have a component that doesn't use a mosRedirect at the end of processing a 'save' or 'apply' task.  You can simulate the problem by commenting out the mosRedirct at line 789 in admin.content.php and then saving some content.

This is the warning you get:

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at C:\Documents and Settings\Geraint\Documents\joomlacode\Joomla1.0.x\includes\joomla.php:4145) in C:\Documents and Settings\Geraint\Documents\joomlacode\Joomla1.0.x\includes\joomla.php on line 800

This is caused by an attempt to set the session cookie (in initSessionAdmin) after the headers have already been sent via the doGzip() at the end of index2.php.  If you put the doGzip right at the end of the file (AFTER the call to $mainframe->initSessionAdmin( $option, '' );) then everything works.

Geraint

[netshine]

The way I fixed this on my component was to add a line at the end of my toolbar.php file to clear the $task variable like so:

Code: Select all

$task = ""; //Have to clear it, otherwise Joomla tries to start a new session (as of 1.0.13)

[Geraint]

That isn't quite enough - I have to set

$GLOBALS["task"]="";
$_REQUEST["task"]="";

at the end of the component.

Geraint

p.s. Having said that the problem is caused by the fact the Joomla 1.0.13 is failing to set the new session cookie

[netshine]

Yes, of course that assumed the $task variable was registered with "global $task" earlier in the script (which it typically would be in a toolbar file). Clearing it at the end of the component file was not enough because the toolbar file was called afterwards, and still needed to know the value of $task.

[Geraint]

I had to set the REQUEST value too because some admin modules etc. reset the global $task after the toolbar and component was called.

Anyhow the point is - its Joomla 1.0.13 that should be fixed since there are no trivial universal workarounds.

[user deleted]

Geraint,

Thanks for all the info on this bug. To make sure, I'll try to replicate on a IIS webserver asap, but without a doubt I will probably be able to replicate the issues.

[Geraint]

Thanks Rob

Just to confirm - I am seeing this problem in Apache (running on a windows server)

Geraint

[pavini]

Hi all,

I have some problem on Apache and Linux Fedora 4

Tanks

[mgs]

this problem also arises in 3rd party component like virtuemartand joomfish.

for those of us who upgraded too soon...could you give us an advice what to do until this has been fixed? someone has reported that uploading the old joomla.php file gets rid of the warning and the admin is not going to get kicked out.

thx for any tips.

[sgreen]

This problem also apparent on OS X Server 10.4.10 and Apache 1.3 running PHP 4.4.4.  Also apparent on Fedora 6 and Apache 2.0 running PHP 4 & 5.  Certainly isn't platform independent!

[pippo]

make test on separate  folder and read all post you can

after some time  upgrade

[sgreen]

never upgrade soon

make test on separate  folder and read all post you can

after some time   upgrade

So what do you do if you are starting a server from scratch?  Use an old version?  I think not.  If the release is launched as 'Stable' it shouldn't really be as stable as a jelly in a hurricane.....

[pippo]

So what do you do if you are starting a server from scratch?  Use an old version?  I think not.  If the release is launched as 'Stable' it shouldn't really be as stable as a jelly in a hurricane.....

I agree you    but as you can see  it seem no

[soeren]

Well,
VirtueMart is also affected by this bug.
The problem is indeed a wrong order of the calls to initSessionAdmin and doGzip at the end of the file /administrator/index2.php.
If we change

BEFORE

Code: Select all

103		doGzip();
104		
105		// if task action is 'save' or 'apply' redo session check
106		if ( $task == 'save' || $task == 'apply' ) {
107			$mainframe->initSessionAdmin( $option, '' );
108		}

to

Code: Select all

102		// if task action is 'save' or 'apply' redo session check
103		if ( $task == 'save' || $task == 'apply' ) {
104			$mainframe->initSessionAdmin( $option, '' );
105		}
106		doGzip();

the problem is gone.

I have posted a Hotfix for Joomla! 1.0.13 on the VirtueMart Homepage.
Feel free to try it. It just contains the updated index2.php file.

ciao, Sören

[pavini]

soeren,

Very, very, very tanks!

My VirtueMart Admin already working fine

Tanks again

[mgs]

the problem is gone.

Hello Sören,

thx for the hotfix. dont know if you have seen this threadon virtuemart.net but there are a couple of people who get kicked out after they log in as admin.

[mgs]

My VirtueMart Admin already working fine

Hello Pavini,

you reported the same problem on the vm forum. would you mind telling us what you did because its not working here.

thx.

[mgs]

ok. there was a second hotfix regarding the admin session.

thx Soeren!

[jlleblanc]

The hotfix doesn't work on my end. Fortunately, I'm only testing this on a dev site for the moment. Thanks for your work though, Sören (both now and for the past several years!).

[mgs]

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at C:\Documents and Settings\Geraint\Documents\joomlacode\Joomla1.0.x\includes\joomla.php:4145) in C:\Documents and Settings\Geraint\Documents\joomlacode\Joomla1.0.x\includes\joomla.php on line 800

we can confirm that Soerens second admin hotfix let us 1) save and 2) stay logged in in the admin backend and (3) gets rid of the warning.

[Geraint]

VirtueMart is also affected by this bug.
The problem is indeed a wrong order of the calls to initSessionAdmin and doGzip at the end of the file /administrator/index2.php.

Hi Soeren

There appears to be consensus that initSessionAdmin will not work if its called after doGzip (since the session cookie cannot be set after the headers are sent to the browser).  As a member of the Q&T team, can you get the problem resolved and a repackaged version of 1.0.13 (or 14) released asap?

Geraint

[sgreen]

The problem is indeed a wrong order of the calls to initSessionAdmin and doGzip at the end of the file /administrator/index2.php.
the problem is gone.

Doesn't cure the problem at this end.  Having made the change, the problem is still apparent.  This is found on both Safari and Firefox on the Mac.

[Geraint]

Doesn't cure the problem at this end.  Having made the change, the problem is still apparent.  This is found on both Safari and Firefox on the Mac.

If you set display_errors on and the error reporting level to E_ALL do you get any error messages? 

And just to double check - the problem the change fixes is just the auto logout behaviour not the authentication problem for bridges and other components.

Geraint

[user deleted]

VirtueMart is also affected by this bug.
The problem is indeed a wrong order of the calls to initSessionAdmin and doGzip at the end of the file /administrator/index2.php.

Hi Soeren

There appears to be consensus that initSessionAdmin will not work if its called after doGzip (since the session cookie cannot be set after the headers are sent to the browser).  As a member of the Q&T team, can you get the problem resolved and a repackaged version of 1.0.13 (or 14) released asap?

Geraint

Geraint,

RobS is looking into the issue, as developer. I would be the one to initiate a 1.0.14 release but I want to wait untill I have some feedback from Rob first.

Edit; talked to Rob briefly, he will be looking at the issue in the next few days and will report back to me.

[merolhack]

I have the same problem with Joomap 2.05

[mtk]

I have the same problem with Joomap 2.05

Can you please try soeren up here?
Let us know..

[althoffm]

I have the same problem with Joomap 2.05

Try the hot fix Soeren posted (see above) I have also seen a fault, in Joomap as soon as you save you get logged off from Joomla administrator.  after I replaced the file from the hot fix
the save error resolved. (testing Joomla 1.0.13 on a Fedora Core machine)

It did not resolve the problem I’m having with Sef patch Advanced. As soon as I go to components – Sef patch Advanced and click on a configuration item two of the three times I get logged of completely. Spoke to the developer but came to the conclusion the it is not in his package.

[althoffm]

I have the same problem with Joomap 2.05

Try the hot fix Soeren posted (see above) I have also seen a fault, in Joomap as soon as you save you get logged off from Joomla administrator.  after I replaced the file from the hot fix the save error resolved. (testing Joomla 1.0.13 on a Fedora Core machine)

It did not resolve the problem I’m having with Sef patch Advanced. As soon as I go to components – Sef patch Advanced and click on a configuration item two of the three times I get logged of completely. Spoke to the developer but came to the conclusion the it is not in his package.