Last modified: 2009-08-16 14:18:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13049 - API must be accessed through the primary script entry point error
API must be accessed through the primary script entry point error
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.12.x
All All
: Normal normal (vote)
: ---
Assigned To: Tim Starling
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-17 18:23 UTC by Bryan Tong Minh
Modified: 2009-08-16 14:18 UTC (History)
5 users (show)

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


Attachments

Description Bryan Tong Minh 2008-02-17 18:23:34 UTC
I get the following error when accessing the API on my local MediaWiki: "API must be accessed through the primary script entry point." even when the API is accessed through its primary script entry point, but only when a query string is appended.

From line 57:
$wgScriptPath/api$wgScriptExtension: /local/w-dev/api.php
$url: /local/w-dev/api.php?action=query&list=categorymembers&cmtitle=Category:Living_people
$strcmp( "$wgScriptPath/api$wgScriptExtension", $url ): -65

PHP Version 5.2.5 is running as FastCGI.

I wonder why strcmp is used as comparison. According to the PHP docs strcmp will only return 0 if the strings are equal, in which case === can be used.
Comment 1 Roan Kattouw 2008-02-17 21:57:28 UTC
Hmm, this is weird. Assigning to Brion as he was the one who introduced this in the first place.
Comment 2 Brion Vibber 2008-02-26 01:32:19 UTC
Can you dump the values of $_SERVER['SCRIPT_URL'] and $_SERVER['PHP_SELF'] ?

Comment 3 Bryan Tong Minh 2008-02-28 21:45:39 UTC
Url: http://localhost/local/w-dev/api.php?action=query&list=categorymembers&cmtitle=Category:Living_people
$_SERVER['SCRIPT_URL']: /local/w-dev/api.php?action=query&list=categorymembers&cmtitle=Category:Living_people
$_SERVER['PHP_SELF']: /local/w-dev/api.php/local/w-dev/api.php

That also looks like something wrong in the way PHP handles FastCGI in combination with Aliases in Abyss Web Server.
Comment 4 Brion Vibber 2008-02-29 00:25:50 UTC
Interesting... do you have the same problem with action=raw pages?

eg:

http://localhost/local/w-dev/index.php?action=raw&title=Main_Page


It looks like we may have to add a wrapper to strip the query string manually here.
Comment 5 Bryan Tong Minh 2008-02-29 12:36:14 UTC
"Raw pages must be accessed through the primary script entry point."
Comment 6 Brion Vibber 2008-08-11 23:12:16 UTC
Reassigning this one to Tim; fun little compatibility bug. :)
Comment 7 Mary Beebe 2009-02-11 15:15:21 UTC
I am getting this same error with server specifications:

Windows server 2003 R2 Service Pack 1
Window XP on the work station.  
IIS, php 5.2.8, mysql 5.0.22

I get it even with just mywiki/api.php.  One wiki on the server works all others do not.  
Comment 8 Roan Kattouw 2009-04-24 19:51:56 UTC
Should be fixed in r49833
Comment 9 Brion Vibber 2009-04-27 22:50:27 UTC
r49833 looks wrong; it'll pull the PHP interpreter URL in CGI configurations, and may or may not work at all on other configs. We need to test it more widely and make sure we've got a clear idea of what's working where.
Comment 10 Alex S.H. Lin 2009-06-15 12:50:22 UTC
I got a problem. cannot run API through secure link.It turn back:

Forbidden
API must be accessed through the primary script entry point.
Comment 11 Russell Blau 2009-06-15 12:53:55 UTC
Same problem as #10: https://secure.wikimedia.org/wikipedia/en/w/api.php returns HTTP 403 ("Forbidden") -- just started as an issue today, as a scheduled script ran without errors less than six hours ago.
Comment 12 Brion Vibber 2009-06-17 15:56:11 UTC
(In reply to comment #11)
> Same problem as #10: https://secure.wikimedia.org/wikipedia/en/w/api.php
> returns HTTP 403 ("Forbidden") -- just started as an issue today, as a
> scheduled script ran without errors less than six hours ago.

Local setup issue? Split out to bug 19263.
Comment 13 Bryan Tong Minh 2009-07-12 22:07:48 UTC
(In reply to comment #9)
> r49833 looks wrong; it'll pull the PHP interpreter URL in CGI configurations,
> and may or may not work at all on other configs. We need to test it more widely
> and make sure we've got a clear idea of what's working where.
> 

It does work for me, and I can confirm that the safety check still works.

Marking as fixed.
Comment 14 Tim Starling 2009-08-16 14:18:37 UTC
(In reply to comment #13)
> It does work for me, and I can confirm that the safety check still works.

Can you explain how you confirmed that the safety check works? Because I can't reproduce it. 

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


Navigation
Links