Last modified: 2013-07-30 00:10:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T35951, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33951 - During install, should do some check to make sure load.php output doesn't have random analytics code appended
During install, should do some check to make sure load.php output doesn't hav...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.18.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-25 23:33 UTC by Bawolff (Brian Wolff)
Modified: 2013-07-30 00:10 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Bawolff (Brian Wolff) 2012-01-25 23:33:55 UTC
It appears that some hosts append user tracking code to the end of load.php output. The specific code appended (to both js and css files):

<!-- www.000webhost.com Analytics Code -->
<script type="text/javascript" src="http://analytics.hosting24.com/count.php"></script>
<noscript><a href="http://www.hosting24.com/"><img src="http://analytics.hosting24.com/count.php" alt="web hosting" /></a></noscript>
<!-- End Of Analytics Code -->


This obviously breaks stuff. (Additionally on people who have this issue also seem to somehow get load.php output a can't contact db server error somehow. not sure what the deal with that is).

We should during the install process somehow check for this, and complain if load.php can't output stuff correctly.
Comment 1 Mark A. Hershberger 2012-01-30 17:25:22 UTC
It seems to me that you'd really have to use some sort of external site to check this since an internal check probably wouldn't show this.

Does it show up if you do "curl http://LOCALDOMAIN/load.php" from the command line on the host?
Comment 2 Chad H. 2012-01-30 20:01:16 UTC
(In reply to comment #1)
> It seems to me that you'd really have to use some sort of external site to
> check this since an internal check probably wouldn't show this.
> 

Furthermore, load.php isn't going to work until after MW's installed.
Comment 3 Bawolff (Brian Wolff) 2012-01-31 02:35:41 UTC
>Furthermore, load.php isn't going to work until after MW's installed.

That doesn't stop us from having a dummy php script that outputs js that we can use to check if its mangled. Without any information to back this up - I imagine doing Http::get( <url to self> ); would catch most cases - this doesn't have to bullet proof. Ideally it would just check if the result is totally mangled. If it can't connect to itself it could simply ignore checking for this.

(In reply to comment #1)
> It seems to me that you'd really have to use some sort of external site to
> check this since an internal check probably wouldn't show this.

Worst case scenario one could use ajax - but really I think that's overkill.

> Does it show up if you do "curl http://LOCALDOMAIN/load.php" from the command
> line on the host?

I have no idea - its not my server. My intuition is its something that hooks into processing php files - in which case it would probably show up still, but that's just an unfounded guess.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links