Last modified: 2011-04-30 01:16:49 UTC
This bug started as a simple settings problem. However the real root of the problem is that I am trying to access my wiki via hughes.net (HN). HN uses a set of processes in managing the data flow called turbopage. While my client IP shoes up correctly, the turbopage servers IP was showing up and used as the anyonomous IP. I took care of that with a SquidServer parm. But I am still being bumped off. I have had people that are connected via hardline to the net try to log in and edit with complete success. I have used two different computers here at the house try, one a PC the other a MAC, and both fail. My wife took her MAC to work and when connected via hardwire at work was successful. The test I have been performing is to log in and then simply refresh the page. I am unable to administer the system and I have a lot of information to put it. This is intended to be a non-profit professional assocations body of knowledge documentation site. www.farrierpractitioners.org/wiki Here is the output that I have captured: >>>> Debug from login <<<< <!-- Served in 0.259 secs. --><!-- Debug output: Start request GET /wiki/index.php/Special:SpecialPages Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* Accept-Language: en-us UA-CPU: x86 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB5; .NET CLR 1.1.4322) Cache-Control: no-cache Client-IP: 72.171.138.209 X-Forwarded-For: 72.171.138.209 Host: www.farrierpractitioners.org Cookie: aafpadmn_AAFPWiki_session=54b5e38ee422cd8843a1517442bf7551; aafpadmn_AAFPWikiUserID=1; aafpadmn_AAFPWikiUserName=AAFPAdmin; aafpadmn_AAFPWikiToken=e1d686718bfdd503d8b437a318edf4d6 Referer: http://www.farrierpractitioners.org/wiki/index.php?title=Special:UserLogin&returnto=Special:SpecialPages Connection: Keep-Alive Main cache: FakeMemCachedClient Message cache: MediaWikiBagOStuff Parser cache: MediaWikiBagOStuff Fully initialised Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgOut on call of $wgOut::_unstub from unknown Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgContLang on call of $wgContLang::checkTitleEncoding from unknown Language::loadLocalisation(): got localisation for en from source Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgMessageCache on call of $wgMessageCache::get from unknown Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgLang on call of $wgLang::getCode from unknown Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgUser on call of $wgUser::getOption from unknown Cache miss for user 1 Connecting to localhost aafpadmn_AAFPWiki... SQL: SET /* Database::open */ NAMES utf8 SQL: SET /* Database::open */ sql_mode = '' Connected SQL: BEGIN SQL: SELECT /* User::loadFromDatabase */ * FROM `user` WHERE user_id = '1' LIMIT 1 SQL: SELECT /* User::loadGroups AAFPAdmin */ ug_group FROM `user_groups` WHERE ug_user = '1' Logged in from session Connecting to localhost aafpadmn_AAFPWiki... SQL: SET /* Database::open AAFPAdmin */ NAMES utf8 SQL: SET /* Database::open AAFPAdmin */ sql_mode = '' Connected SQL: SELECT /* MediaWikiBagOStuff::_doquery AAFPAdmin */ value,exptime FROM `objectcache` WHERE keyname='aafpadmn_AAFPWiki:messages:en' MessageCache::load: Loading en... got from global cache Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgParser on call of $wgParser::firstCallInit from unknown Class SkinMonobook not found; skipped loadingZend Optimizer detected; skipping debug_backtrace for safety. SQL: COMMIT SQL: BEGIN SQL: SELECT /* LinkBatch::doQuery AAFPAdmin */ page_id, page_namespace, page_title, page_len, page_is_redirect FROM `page` WHERE (page_namespace=2 AND page_title='AAFPAdmin') OR (page_namespace=3 AND page_title='AAFPAdmin') SQL: SELECT /* User::checkNewtalk AAFPAdmin */ user_id FROM `user_newtalk` WHERE user_id = '1' LIMIT 1 --> >>>> Debug from a browser refresh done imediatly after login <<<< <!-- Served in 0.256 secs. --><!-- Debug output: Start request GET /wiki/index.php/Special:SpecialPages Accept: */* Referer: http://www.farrierpractitioners.org/wiki/index.php?title=Special:UserLogin&returnto=Special:SpecialPages Accept-Language: en-us UA-CPU: x86 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB5; .NET CLR 1.1.4322) Host: www.farrierpractitioners.org Client-IP: 72.171.138.209 X-Forwarded-For: 72.171.138.209 Connection: Close Cookie: aafpadmn_AAFPWikiUserID=1; aafpadmn_AAFPWikiUserName=AAFPAdmin; aafpadmn_AAFPWiki_session=54b5e38ee422cd8843a1517442bf7551; aafpadmn_AAFPWikiToken=e1d686718bfdd503d8b437a318edf4d6 Main cache: FakeMemCachedClient Message cache: MediaWikiBagOStuff Parser cache: MediaWikiBagOStuff Fully initialised Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgOut on call of $wgOut::_unstub from unknown Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgContLang on call of $wgContLang::checkTitleEncoding from unknown Language::loadLocalisation(): got localisation for en from source Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgMessageCache on call of $wgMessageCache::get from unknown Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgLang on call of $wgLang::getCode from unknown Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgUser on call of $wgUser::getOption from unknown Connecting to localhost aafpadmn_AAFPWiki... IP: 72.171.138.209 SQL: SET /* Database::open 72.171.138.209 */ NAMES utf8 SQL: SET /* Database::open 72.171.138.209 */ sql_mode = '' Connected SQL: SELECT /* MediaWikiBagOStuff::_doquery 72.171.138.209 */ value,exptime FROM `objectcache` WHERE keyname='aafpadmn_AAFPWiki:messages:en' MessageCache::load: Loading en... got from global cache Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgParser on call of $wgParser::firstCallInit from unknown Class SkinMonobook not found; skipped loadingZend Optimizer detected; skipping debug_backtrace for safety. Connecting to localhost aafpadmn_AAFPWiki... SQL: SET /* Database::open 72.171.138.209 */ NAMES utf8 SQL: SET /* Database::open 72.171.138.209 */ sql_mode = '' Connected SQL: BEGIN SQL: SELECT /* LinkBatch::doQuery 72.171.138.209 */ page_id, page_namespace, page_title, page_len, page_is_redirect FROM `page` WHERE (page_namespace=2 AND page_title='72.171.138.209') OR (page_namespace=3 AND page_title='72.171.138.209') SQL: SELECT /* User::checkNewtalk 72.171.138.209 */ user_ip FROM `user_newtalk` WHERE user_ip = '72.171.138.209' LIMIT 1 --> >>>>> Output to deb_log.txt from the refresh <<<<<< session_set_cookie_params: "0", "/", "", "", "1" Fully initialised Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgMessageCache on call of $wgMessageCache::get from unknown Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgContLang on call of $wgContLang::getCode from unknown Connecting to localhost aafpadmn_AAFPWiki... SQL: SET /* Database::open */ NAMES utf8 SQL: SET /* Database::open */ sql_mode = '' Connected SQL: SELECT /* MediaWikiBagOStuff::_doquery */ value,exptime FROM `objectcache` WHERE keyname='aafpadmn_AAFPWiki:messages:en' MessageCache::load: Loading en... got from global cache Language::loadLocalisation(): got localisation for en from source Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgParser on call of $wgParser::firstCallInit from unknown Zend Optimizer detected; skipping debug_backtrace for safety. Unstubbing $wgUser on call of $wgUser::getOption from unknown Session user ID (0) and cookie user ID (1) don't match!
Suggest closing WORKSFORME. There's nothing I see here that we can really do. It's a known fact that satellite internet providers (such as HughesNet) do funny things with proxies and cookies. To quote [[Wikipedia:Village_pump_(technical)]]'s FAQ: "Some ISPs use transparent proxies which cause problems logging in." If you find that you are automatically logged out just after you have logged in, and removing all your Wikipedia cookies does not fix the issue, try using the secure server (much slower) to bypass the proxy. This happens most often with some satellite ISPs (particularly HughesNet/DirecWay/DirecPC).
While I understand the sentiment and the problems that are being cause by the way some ISP's handle things, these ISP's are now accounting for a growing percentage of the user population. I believe it is unreasonable to just through one's hands up and ignore those users. Finding a work around would seam inportant in this environment.
> I am also having this problem. I use Hughesnet and cannot stay logged in to my > install of the newest version of mediawiki. I can stay logged in to older > versions of mediawiki with no problem, but cannot administrate my own wiki > because of this. >
I'm also having the same problem, my ISP provider is also with Hughesnet due to my remote location. I upgraded from MediaWiki version 1.13.5 to 1.14.0 and soon after the upgrade was unable to stay logged in. I partially solved the problem by using an older version of the monobook skin (Version 1.13.5) to stay logged in but with consequences, I was not able to edit pages with css or js on it (i.e. MediaWiki:Common.js)I will always get logged out. Due to being unable to administer my own wiki using version 1.14.0, I had to roll back to version 1.13.5 and everything's back to normal. Hopefully this will not be my last version update with MediaWiki. Thanks in advanced to anyone willing to listen and try to solve this.
Please contact your ISP and address the issue with them. their networking procedures should not interfere with core code
That is such a cop-out. WHY would the software only start doing this after updating to 1.14.0? As myself and EMacabeo have said, this only occurred after version 1.14. Obviously something was changed in the core code between previous version and that one, and it should be a findable and fixable problem!
Not findable by us, if we can't reproduce the problem. At least one dev has tried and failed to get the issue to occur. Since the problem occurs for you, and we can't reproduce it, you'll have to isolate it. You might want to try checking out revisions from trunk intermediate between 1.13 and 1.14 and see which one is the first to cause the problem. If you aren't able to give us more precise information on what change caused the problem, there's not anything we can do to fix it. You might want to try disabling Zend Optimizer. I've heard that can cause problems. I don't know, it's worth a shot. Not much else we can say without being able to reproduce the problem ourselves.
Just a note: This problem has been reported on Wikipedia periodically long before 1.14 came out. It appears on the VP/T as far back as October 2006: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=92400326 (1.14 was branched Jan 8 2009).
Since nobody has noted it here yet: http://toolserver.org/~amidaniel/chanlogs/%23mediawiki/20090912.txt <TimStarling_> HughesNet just picked the logout link out of the HTML and preloaded it for you <TimStarling_> GET /index.php?title=Special:UserLogout&returnto=MediaWiki:Print.css <TimStarling_> because it's doing the & thing with the original CSS URLs, it gets served HTML instead <TimStarling_> and then it scans that HTML, assuming it's CSS, for more URLs <Splarka> is this the "broken client" that domas blocked & on WMF for? <TimStarling_> well, that would explain why WMF works
To be fair to them, GETs are theoretically supposed to be idempotent . . .
I work with a number of Hughes-connected customers in Alaska. We work with a number of authentication required sites, such as Moodle, WordPress, and other CMS sites with WikiMedia being a major component for one of my customers. Everybody on the Hughes.net connections experiences the same problems as noted above but only on the WikiMedia section of their site. With over 3,000 registered users, their site shows the following Page statistics: Content pages 4,302 Pages (All pages in the wiki, including talk pages, redirects, etc.) 13,152 Uploaded files 7,210 Edit statistics Page edits since OpenContent was set up 49,382 Average edits per page 3.75 Known fact or not regarding Hughes.net connections, I'd suggest that this problem can be resolved as we do not see similar characteristics with the other CMS sites we run. I can provide more information if needed. Please let me know what you need, although I must request this info from end users as I am not on a Hughes connection. Thank you.
Created attachment 7125 [details] Proposed patch If there is a problem, we must fix it if we can. Because Tim's hack from IRC seems to work fine, I've prepared its beautified version and going to commit it in a couple days if there will be no objections. To Hughes.net users: I need your help: if you add the link [[Special:Search/Special:Userlogin]] to a page, does your ISP's precacher hit Special:Userlogin when you visit that page?
Fixed, committed a modified version of my patch in r62967 and r62973. All thanks go to Tim for investigating this matter.
*** Bug 11448 has been marked as a duplicate of this bug. ***
