Last modified: 2009-08-16 14:18:37 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.
Hmm, this is weird. Assigning to Brion as he was the one who introduced this in the first place.
Can you dump the values of $_SERVER['SCRIPT_URL'] and $_SERVER['PHP_SELF'] ?
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.
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.
"Raw pages must be accessed through the primary script entry point."
Reassigning this one to Tim; fun little compatibility bug. :)
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.
Should be fixed in r49833
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.
I got a problem. cannot run API through secure link.It turn back: Forbidden API must be accessed through the primary script entry point.
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.
(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.
(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.
(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.
