Page MenuHomePhabricator

Upstream ForeignAPI code in MobileFrontend into core/CentralAuth
Closed, ResolvedPublic

Description

In MobileFrontend we have support for requesting cross domain tokens using centralauth token. We've had to use this code for Wikigrok work and are likely to need it gain.

To kill MobileFrontend we should move this api code to a more logical place. As @Legoktm rightly points out core is not necessarily the right place for this, but CentralAuth may be.

Details

Reference
bz64636
Related Gerrit Patches:
mediawiki/extensions/CentralAuth : masterImplement a mediawiki.ForeignApi extension
mediawiki/core : mastermediawiki.ForeignApi: Module should target mobile
mediawiki/core : masterIntroduce mediawiki.ForeignApi

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:18 AM
bzimport set Reference to bz64636.
bzimport added a subscriber: Unknown Object (MLST).
Jdlrobson renamed this task from Upstream getToken code in MobileFrontend into core to Upstream ForeignAPI code in MobileFrontend into core.Jan 15 2015, 9:21 PM
Jdlrobson edited projects, added Readers-Web-Backlog; removed MobileFrontend-Uploads.
Jdlrobson set Security to None.
Jdlrobson moved this task from Incoming to Epics/Goals on the Readers-Web-Backlog board.
Legoktm added a subscriber: Legoktm.Jul 2 2015, 2:28 AM

Core shouldn't have any knowledge about CentralAuth.

Jdlrobson renamed this task from Upstream ForeignAPI code in MobileFrontend into core to Upstream ForeignAPI code in MobileFrontend into CentralAuth.Jul 2 2015, 8:39 PM
Jdlrobson updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 13 2015, 9:27 PM
matmarex renamed this task from Upstream ForeignAPI code in MobileFrontend into CentralAuth to Upstream ForeignAPI code in MobileFrontend into core/CentralAuth.Aug 13 2015, 9:41 PM
matmarex updated the task description. (Show Details)

Mobile's ForeignAPI handles more than just CentralAuth (and its 'centralauthtoken'), it also handles the usual cross-origin AJAX woes. I think we could try splitting it into mw.ForeignApi (which would extend mw.Api and live in core), and mw.CentralAuthForeignApi (which would extend mw.ForeignApi and live in CentralAuth).

So the problem is that we want any code to be able to just depend on mw.ForeignApi and not need to worry about whether CentralAuth or any other auth-related extension is installed. If we did it like I suggested above, then every RL module wishing to use cross-wiki API, and handle both CentralAuth-enabled and other wikis, would have to be conditionally registered with different dependency (either mw.CentralAuthForeignApi or mw.ForeignApi).

Here's how we could solve it:

  • We have a mediawiki.ForeignApi module, which is the user-visible one. Transparently handles the usual cross-domain business, CentralAuth and anything else. It doesn't have any code; instead, it depends on:
    • Modules created by extensions such as CentralAuth, which implement extension-specific cross-wiki business (like 'centralauthtoken'). Each must ensure that nothing terribly bad happens when pointed to a wiki without the extension (for example, a wiki with CentralAuth installed must still be able to communicate with non-CentralAuth wikis via mw.ForeignApi). We'd have a new hook, let's call it ResourceLoaderForeignApiModules, through which extensions would inform MediaWiki of these modules. Each of the modules would depend on:
      • mediawiki.ForeignApi.core, which is where the real mediawiki.ForeignApi code would live. Here we take mw.Api and extend it with CORS-handling and 'origin'-handling code and name it CoreForeignApi. We also alias mw.ForeignApi = CoreForeignApi.
    • The extension modules each run their own code, extending mw.ForeignApi and naming it their thing, say CentralAuthForeignApi. Then they alias mw.ForeignApi = CentralAuthForeignApi (etc.).
  • By the time we get to mediawiki.ForeignApi, mw.ForeignApi will be set and extended by each of the extensions. Success!
matmarex triaged this task as Normal priority.
matmarex removed a subscriber: wikibugs-l-list.

Change 231710 had a related patch set uploaded (by Bartosz Dziewoński):
Introduce mediawiki.ForeignApi

https://gerrit.wikimedia.org/r/231710

Change 231711 had a related patch set uploaded (by Bartosz Dziewoński):
Implement a mediawiki.ForeignApi extension

https://gerrit.wikimedia.org/r/231711

Change 231710 merged by jenkins-bot:
Introduce mediawiki.ForeignApi

https://gerrit.wikimedia.org/r/231710

Change 231711 merged by jenkins-bot:
Implement a mediawiki.ForeignApi extension

https://gerrit.wikimedia.org/r/231711

Jdforrester-WMF closed this task as Resolved.Aug 24 2015, 6:24 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Woo.

Jdlrobson reopened this task as Open.Aug 24 2015, 6:40 PM

Not quite resolved. We'll need to remove the code in MobileFrontend :) I'll put that on my to do!

Change 233631 had a related patch set uploaded (by Jdlrobson):
ForeignApi module should target mobile

https://gerrit.wikimedia.org/r/233631

Change 233631 merged by jenkins-bot:
mediawiki.ForeignApi: Module should target mobile

https://gerrit.wikimedia.org/r/233631

matmarex added a project: User-notice.EditedAug 27 2015, 10:42 PM

I have written/expanded https://www.mediawiki.org/wiki/Manual:CORS#Using_mediawiki.ForeignApi to document the new feature and linked it in a few places on mw.org.

I think this should be included in Tech News. Proposed wording: Gadget writers can now use [[Manual:CORS#Using_mediawiki.ForeignApi|mediawiki.ForeignApi]] to easily communicate between different Wikimedia wikis. (This task is still open, but this part is implemented and can be announced anytime.)

Johan added a subscriber: Johan.Aug 28 2015, 10:47 AM

It's now included in the upcoming issue of Tech News.

matmarex closed this task as Resolved.Aug 29 2015, 6:54 PM

Not quite resolved. We'll need to remove the code in MobileFrontend :) I'll put that on my to do!

It seems that we're handling this as T110102 (patch pending), so I'll mark this one as closed again.

@Johan A question or maybe I am asking for an elucidation of the subject name here and the text that appeared in the Tech News

Gadget writers can now use mediawiki.ForeignApi to communicate between different Wikimedia wikis.

To me the ticket talks about login details and interconnectivity of a login. For the tech news it reads more about the broader interaction/interoperability between the wikis, eg. crosswiki transclusion. Of course, it may be that ForeignAPI has a jargon that is very tight that represents something to coders than to the broader public. The clarification would be useful. Thanks.

Better late reply than never:

@Johan A question or maybe I am asking for an elucidation of the subject name here and the text that appeared in the Tech News

Gadget writers can now use mediawiki.ForeignApi to communicate between different Wikimedia wikis.

To me the ticket talks about login details and interconnectivity of a login. For the tech news it reads more about the broader interaction/interoperability between the wikis, eg. crosswiki transclusion. Of course, it may be that ForeignAPI has a jargon that is very tight that represents something to coders than to the broader public. The clarification would be useful. Thanks.

This is only a JavaScriot interface, it does not allow for cross-wiki transclusion or anything. But it does allow you to write a gadget to, say, update the description page of a file on Commons with a new translation directly from a Wikipedia article; or to write a gadget to update all references to a file on all Wikipedias after it is moved on Commons; or to upload a file to Commons directly from the editor (something we're working on at Multimedia); or to synchronise your user preferences from the central wiki to all other ones; and so on. (This was possible before, if you were determined; now it is easy and hopefully people will create such things.)