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

[mtk]

I can confirm Soeren's patch solving:

• VirtueMart
• JoomFish
• Joomap

each and every components tested on a new J!1.0.13 installation (& combinations)...

[Woodega]

I'm not sure if this is the same problem or not, but almost every time I try to select an item in the top menu on the admin page, I get logged out with the message "You need to login". It even happens when I click on the "Home" button in the top menu. Icons buttons in the Control Panel, however, work properly, as do items in the "Logged", "Components", "Popular", etc. tabs. I was even able to upload a new template, but now I can't get to the template installer for being logged out.

At first, I thought that maybe it was because my session save path was not set in php.ini, so I set it to /tmp and restarted Apache. I can watch the directory and see the session files created. I've also completely turned off gzip compression in Global Configuration. I've applied the soren's hotfix, but still no luck.

Fortunately this is on my local development server, but I'd like to get this going because I need to work on my site before rolling the changes to the live server. Well, I guess I could just downgrade using my backups.

If it makes any difference, my server is my iMac, Mac OS X 10.4.10, PHP 5.2.2, Apache 1.3.

[Woodega]

Okay, this is pretty odd...

Just for giggles, I launched Firefox and logged in. Everything works normally!

I was previously logged in using Safari 3.0 beta. I guess I could go back to Safari 2.x and see how that works, but I'm just happy to be able to get some work done.

Maybe this isn't related at all, maybe there's something about the way the session data is sent and interpreted by Safari 3.0 -- I  have no idea. Maybe this additional info will help you Joomla! folks track down the issue, if indeed I'm experiencing the same issue as the rest here in this thread.


Woody

[Echooff3]

I'm getting a simular error except for when I click 'Save', 'Apply', or 'Cancel' I get logged out. Everything else seems to work fine. I've applied the hot fix and did the nulling out of the $task variables. Still getting the same results.

Any Ideas???

[pcpbslack]

Just installed 1.0.13 on IIS5/PHP 5.2.3, and I am getting Logged Out when I click Cancel. Can please somebody put a fix for this, because is so annoing.

Thank all for the good job!

[RobS]

Hi guys,

I have been trying to duplicate the problem but I am unable to.  Can you guys tell me which web server software (Apache/IIS/etc) you experience this problem with and which version of that software and what PHP version you are using?  I am using Apache 2.2.x and PHP 5.2.3.

Rob

[pcpbslack]

As I told before, I have an Windows 2000 Small Business, with IIS5 installed, and PHP 5.2.3. I am gettig logged out from the administration area, when I push the Cancel button. Everything else works ok, so far.

PS: The Joomla version is 1.0.13.

[Echooff3]

I'm using brinkster.com as my host. You can see their specs here

http://www.brinkster.com/hosting/Pro.aspx

[Geraint]

I have been trying to duplicate the problem but I am unable to.  Can you guys tell me which web server software (Apache/IIS/etc) you experience this problem with and which version of that software and what PHP version you are using?  I am using Apache 2.2.x and PHP 5.2.3.

Hi Rob - see http://forum.joomla.org/index.php/topic ... #msg916809 for how to make the content component fail as a simple test case. 

I am running Apache 2.0.54 , PHP 5.2.3 fast CGI on Windows server.

Geraint

[pcpbslack]

For me, this issue is solved. When PHP is installed as an ISAPI module this issue is history. Update your servers and install PHP as an ISAPI module and everything should work as expected.

[akede]

The point is that this problem is not only an IIS issue. I also have this problem on an Apache Server (2.0.55) with ZendPlatform 2.0 (PHP 5.2.1) installed as fastcgi.

Alex

[Edit]
PS: Forgot to mention that switching the two lines of code solved the issue for me

[pcpbslack]

Yes, the problem appears when PHP is installed as CGI binary and not as a module.

[sgreen]

The way that PHP is installed should not affect the way that Joomla works.

I'm running Apache 1.3 and PHP 4.4.7 on an OS X Server and the problem is apparent with Joomla 1.0.13.  It is both time-consuming and irritating that this problem manifests itself in such a fashion.  I have other Joomla sites on the same server that are running Joomla 1.0.12 and they run perfectly fine.

Reading through the thread, just because this problem is apparent on one setup and not the other, doesn't make it a client or server problem.  Something fundemental changed between R12 and R13.  Whatever that change is, it isn't 100% compatible with all platforms so it needs to be resolved.  The hotfix released earlier on up the page doesn't totally solve the problem on all platforms.

Come on, team.  Joomla is such a good product, this is really frustrating to see such a problem arise.  The benefits of the OpenSource community should mean that this can be resolved quickly and effectively.  All that seems to have happened so far is that you've been dissing the people who are supporting the platform by telling them it is their server problem and not a problem with your code.

StuG

[jlleblanc]

The way that PHP is installed should not affect the way that Joomla works.

I'm running Apache 1.3 and PHP 4.4.7 on an OS X Server and the problem is apparent with Joomla 1.0.13.  It is both time-consuming and irritating that this problem manifests itself in such a fashion.  I have other Joomla sites on the same server that are running Joomla 1.0.12 and they run perfectly fine.

Reading through the thread, just because this problem is apparent on one setup and not the other, doesn't make it a client or server problem.  Something fundemental changed between R12 and R13.  Whatever that change is, it isn't 100% compatible with all platforms so it needs to be resolved.  The hotfix released earlier on up the page doesn't totally solve the problem on all platforms.

Come on, team.  Joomla is such a good product, this is really frustrating to see such a problem arise.  The benefits of the OpenSource community should mean that this can be resolved quickly and effectively.  All that seems to have happened so far is that you've been dissing the people who are supporting the platform by telling them it is their server problem and not a problem with your code.

StuG

Hold on here. I've written open source software myself and bugfixes don't always come quickly. The Joomla! team has only so many resources (volunteers) available to test the software on a reasonable range of setups. I've had people report bugs in my software that I can't reproduce; this is very frustrating for developers too because we know users are having problems with the software and we can't help them.

[jlleblanc]

To update: it appears that the webserver software itself may not be the issue, leading me to think that it's a PHP configuration issue. With the configuration on Windows box I'm (forced to) run, J!1.0.13 has the issue even with the hotfix. This is not the case with my Mac server: both J1.0.13 and the hotfix seem to work there. Here is the session section of phpinfo for both servers:

Windows running IIS 5.0, PHP 5.1.4, doesn't work
session
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


Mac running Apache 1.3.33, PHP 5.2.0, works
session
Session Support enabled
Registered save handlers files user sqlite
Registered serializer handlers php php_binary wddx

Directive Local Value Master Value
session.auto_start Off Off
session.bug_compat_42 Off Off
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_httponly Off Off
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 1000 1000
session.gc_maxlifetime 2400 1440
session.gc_probability 1 1
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name 7258b327765c0de45616fecaef4081f9 PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path no value no value
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0


I suggest that anyone else experiencing the issue even after the hotfix post the session section of their phpinfo(). You can get this by going to System > System Info, PHP Info tab in the backend.

Edit: added PHP versions

[sgreen]

You're missing the point.  An application such as Joomla should not require any server-side configuration with such a minor version change.  If R12 was working, why change something in R13 without fully researching the implications?  PHP Config posted below.

Output from OS X Server (10.4.10) running PHP 4.4.7 and Apache 1.3.33

session

Session Support enabled
Registered save handlers files user

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 2400 1440
session.gc_probability 1 1
session.name 546b302b9c7534377a7f734e162ab7a8 PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path /tmp /tmp
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid Off Off

[io2002oi]

Just to say hot fix #1 worked for me - My joomfish (1.7) always log me out to admin main page after saving

Thanks !

[tcp]

Moving the new code to a point in the file before output is generated also seems to resolve this problem, for me at least.

Code: Select all

ob_end_clean();


if ( $task == 'save' || $task == 'apply' ) {
	$mainframe->initSessionAdmin( $option, '' );
}

initGzip();

[jlleblanc]

Moving the new code to a point in the file before output is generated also seems to resolve this problem, for me at least.

Code: Select all

ob_end_clean();


if ( $task == 'save' || $task == 'apply' ) {
	$mainframe->initSessionAdmin( $option, '' );
}

initGzip();

Still fails over here.

[Geraint]

Still fails over here.

Have you set your error reporting to the highest level - if so do you see any warnings or notices?

[jlleblanc]

Still fails over here.

Have you set your error reporting to the highest level - if so do you see any warnings or notices?

Error reporting cranked up full blast. It's still logging out and saying that I need to log in.

[sgreen]

OK, I've had the day off today and I spent a couple of hours looking at this.

Following the response to this problem which posted the OS X Server session config, I duplicated my session config to match a known working version.  Guess what - FAULT STILL APPARENT.  Yes, I restarted Apache, and then I restarted the server.

Also tried moving the code as suggested above in both 'fixes'.  Guess what - FAULT STILL APPARENT.

Have turned logging up as high as I can, and no errors are reported.  Anywhere.

I'm starting to wonder if this is a PHP Session problem at all.  If it were, how can the problem manifest itself differently in two identical session configurations on the same server platform?

BTW, the problem rarely occurs if I log in to admin and ONLY use menu links across the top.  Say I go back to the administrator home and click on, say, Menu Manager and select a menu to edit from the icon within there, the next time I click on ANY link from the menus across the top, "You need to log in" appears.  Not just once.  Not just twice or three times.  Sometimes this happens more than FIFTEEN times which, frankly, makes the system unusable.

Come on guys - some of us don't have time to dismantle your code and put it right and we do rely on your patches and hotfixes to correct problems and not introduce new ones.  I've been with Joomla! for a couple of years now and I've NEVER experienced any problems like this, so it is unusual.  However, how it even got there in the first place needs to be addressed so that it doesn't happen again.

Hope this shines a little more light onto this problem.

Cheers,

StuG

[bassman]

I´m not shure if Fireboard is causing problem, in fact it´s not possible to login so you can write in the forum.

[sgreen]

Can't be Fireboard in my case as it isn't being used on this Joomla! site.  It is something more generic.

StuG

[akede]

Hi Sgreen,

Thanks a lot for all the efforts to trace down the problem from your site. I tested the issue myself on various setups now and will do some more but it seems it is a kind of strange combination of things which cause this bug.

Come on guys - some of us don't have time to dismantle your code and put it right and we do rely on your patches and hotfixes to correct problems and not introduce new ones.  I've been with Joomla! for a couple of years now and I've NEVER experienced any problems like this, so it is unusual.  However, how it even got there in the first place needs to be addressed so that it doesn't happen again.

I'm wondering how someone who is around already several years has only 11 posts in our official forum :-P. The primary issue we face here and we faced that in the past already is that we can't reproduce the bug easily. When Rob developed that code and tested everything it worked. Also the Q&A team tested it and didn't found that bug and as far as I can say it works also with most of the core extensions. So it is a combination of effects and those things are always a bit complicate to find.

We are working on it - thanks for being a bit patient with us.

Alex

[tcp]

The basic problem seems to be that the new code is trying to set a cookie when output has been pumped out already.  If this is the case, the session check should appear earlier in the code.  I can reproduce this bug, and moving the new code up resolved the problem for me and several users that I work with, but apparently is doesn't for everyone.  Well, if it did, that would be too easy, yeah!

My sys info.
PHP built On: Darwin apsara.lan 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386
Database Version: 5.0.19
PHP Version: 5.2.1
Web Server: Apache/2.2.3 (Unix) Zend Core/2.0.0 PHP/5.2.1 mod_ssl/2.2.3 OpenSSL/0.9.8d
WebServer to PHP interface: apache2handler
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) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

[sgreen]

Thanks for your reply.

I'm wondering how someone who is around already several years has only 11 posts in our official forum :-P.

This is because Joomla! has been such a robust and stable application, I haven't needed to get in and report a bug!

StuG

[consigliere]

Hi guys,

I have been trying to duplicate the problem but I am unable to.  Can you guys tell me which web server software (Apache/IIS/etc) you experience this problem with and which version of that software and what PHP version you are using?  I am using Apache 2.2.x and PHP 5.2.3.

Rob

I am having the same problem,  Joomla Logs me out automatically when trying to open an item for editing. This is my enviroment:

Joomla 1.0.13
XhtmlSuite 1.8
Firefox 2.0.0.6
PHP 4.3.11
WebServerX  Apache 1.3.33 (Unix)

[hotnuts21]

I had a total login problem on IIS server, we fixed it by changing the php session.save_path from d:/webs/sessiondata to d:/session obviously you have to create the session folder first, IIS the shorter path seemed to make IIS happy. You have to update this in php.ini of course.
We also changed the session.cookie_path from / to "/" and it fixed 90% of our login problems, we are only now experiencing problems with the templates (add new and set default).

I will try the above hotfix to see if that helps.

This may (or may not) help those on an IIS server, its worth a try at least.

[LupoAlberto74]

Hello,
SOEREN's solution of doesn't solve the problem for me. Nor TCP's. 

So, let's do some other login every 'cancel', and sometimes when 'save' or 'apply'   

For our Joomla Heroes (thank you for your work), here's my configuration:

PHP built On:  Windows NT LUCIFERO 5.0 build 2195
Versione database: 5.0.24-log
Versione PHP: 4.4.0
Web Server: Microsoft-IIS/5.0
WebServer to PHP interface: cgi-fcgi
Versione Joomla!: Joomla! 1.0.13 Stable [ Sunglow ] 21 July 2007 16:00 UTC
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Relevant PHP Settings:
Joomla! Emulazione Register Globals: ON
Register Globals: ON
Magic Quotes: ON
Safe Mode: OFF
Caricamento File: ON
Session auto start: OFF
Session save path: C:\PHP\sessiondata
Short Open Tags: ON
Output Buffering: OFF
Open basedir: none
Display Errors: ON
XML enabled: Si
Zlib enabled: Si