Page MenuHomePhabricator
Create Task
Maniphest T19790

User Will Not stayed logged in on HughesNet
Closed, ResolvedPublic
Actions

Description

Author: ron

Description:
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&amp;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&amp;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!

Version: 1.14.x
Severity: major
OS: Linux
Platform: Other

Details

Reference
bz17790

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:33 PM
• bzimport added a project: MediaWiki-User-login-and-signup.
• bzimport set Reference to bz17790.
• bzimport added a subscriber: Unknown Object (MLST).
• bzimport created this task.Mar 5 2009, 12:17 AM
• demon added a comment.Mar 5 2009, 1:50 AM

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).

• bzimport added a comment.Mar 5 2009, 12:07 PM

ron wrote:

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.

• bzimport added a comment.Apr 9 2009, 3:03 PM

cwilliams wrote:

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.

• bzimport added a comment.Apr 10 2009, 9:45 PM

emacabeo wrote:

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.

Betacommand added a comment.Jul 15 2009, 11:22 PM

Please contact your ISP and address the issue with them. their networking procedures should not interfere with core code

• bzimport added a comment.Jul 16 2009, 6:21 PM

cwilliams wrote:

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!

• bzimport added a comment.Jul 16 2009, 6:33 PM

ayg wrote:

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.

• bzimport added a comment.Sep 11 2009, 2:32 AM

herd wrote:

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).

• bzimport added a comment.Sep 13 2009, 2:22 AM

herd wrote:

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&amp;returnto=MediaWiki:Print.css
<TimStarling_> because it's doing the &amp; 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 &amp; on WMF for?
<TimStarling_> well, that would explain why WMF works

• bzimport added a comment.Sep 13 2009, 3:20 AM

ayg wrote:

To be fair to them, GETs are theoretically supposed to be idempotent . . .

• bzimport added a comment.Feb 15 2010, 6:27 AM

support wrote:

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.

MaxSem added a comment.Feb 15 2010, 3:58 PM

Created attachment 7125
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?

Attached:

hughes.net.patch1 KBDownload

MaxSem added a comment.Feb 25 2010, 8:33 PM

Fixed, committed a modified version of my patch in r62967 and r62973. All thanks go to Tim for investigating this matter.

MaxSem added a comment.Mar 5 2011, 12:10 PM
  • Bug 11448 has been marked as a duplicate of this bug. ***
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits