Page MenuHomePhabricator

Requests fail with Access-Control-Allow-Origin errors when using ForeignApi on iOS Safari
Open, MediumPublicBUG REPORT

Description

Steps to replicate the issue:

  • Open Safari on iOS.
  • Go, for example, to the testwiki;
  • Add the following user script to your common.js:
mw.loader.load( 'https://test.wikipedia.org/w/index.php?title=User:Serhio_Magpie/testCors.js&action=raw&ctype=text/javascript' );
  • or execute the following code in the browser console:
mw.loader.using( [ 'mediawiki.util', 'mediawiki.ForeignApi' ] )
    .then( () => {
        const test = ( hostname ) => {
            const api = new mw.ForeignApi( 'https://' + hostname + mw.util.wikiScript( 'api' ) );
            const params = {
                action: 'query',
                meta: 'siteinfo',
                siprop: 'general',
                format: 'json',
                formatversion: 2,
            };
            api.get( params )
                .done( response => {
                    console.info( `======= ${ hostname } pass =======` );
                    console.log( response );
                } )
                .fail( error => {
                    console.info( `======= ${ hostname } fails =======` );
                    throw new Error( error );
                } );
        };

        test( 'meta.wikimedia.org' );
        test( 'www.mediawiki.org' );
        test( 'www.wikidata.org' );
    } );
  • See the errors in the browser console:
Mobile site:
Inspect_OQHfzutGJv.png (1,885×579 px, 59 KB)
Desktop site:
image.png (1,912×217 px, 57 KB)

What happens?:
On the latest iOS 18.5 Safari, the first request made to the project using ForeignApi constantly fails regardless of desktop or mobile site version. All content blockers are disabled. On the latest Chrome or Firefox on Windows 11, all requests pass as they should.

Mobile site:
chrome_9j7X2blWCM.png (706×1,088 px, 61 KB)
Desktop site:
chrome_No7QOVeVuh.png (813×1,093 px, 72 KB)

Event Timeline

HCoplin-WMF added a project: Web-Team.
HCoplin-WMF added subscribers: Catrope, HCoplin-WMF.

MediaWiki Interfaces doesn't currently have expertise to dig into this. Tagging Web-Team for additional support. @Catrope -- would you be able to take a look? It seems like Safari did make some CORS related changes recently: https://developer.apple.com/documentation/safari-release-notes/safari-18_4-release-notes

Jdrewniak subscribed.

@HCoplin-WMF Web team is no more. We've been split into Reader Experience Team and Reader Growth Team , but I'm not sure if this issue is a good fit for either. I don't think this is an issue with MobileFrontend either.

CORS header access is maintained in a list of domains here in mediawiki-config

We should test if this happen on all wmf domains on mobile safari or just teswiki.

I've tried to reproduce this and it looks like it happens on all mobile domains, and desktop domain, on iOS Safari, except enwiki (I can't reproduce on either en.m.wikipedia.org or en.wikipedia.org)
But only as a logged-in user. As an anonymous user, the requests seem to pass in the browser console.

ssingh subscribed.

[Removing Traffic since this is a MW issue. Please re-add if you disagree.]

This issue is now different, after T421778: Action API requests with centralauthtoken=… or OAuth bearer token should produce CORS headers if the token is invalid was rolled out. The problem now is that cross-wiki ForeignApi requests return badtoken: 'centralauthtoken is not valid' non-deterministically.

I don't have any devices I could reproduce this on.

This issue is now different, after T421778: Action API requests with centralauthtoken=… or OAuth bearer token should produce CORS headers if the token is invalid was rolled out. The problem now is that cross-wiki ForeignApi requests return badtoken: 'centralauthtoken is not valid' non-deterministically.

Any reason to believe this is related to the iOS issue? I saw some logs about invalid centralauthtokens recently (T424846#11871633), but did not have the time to investigate them.