Page MenuHomePhabricator

Add a search API configuration override
Closed, ResolvedPublic

Description

$wgMFNearbyEndpoint and $wgMFPhotoUploadEndpoint are useful configurations for development however they come at the cost of shipping code to production. They also do not apply to all API requests. A notable omission is a search API endpoint override. What should that look like? The seam is currently in the skin, MinervaNeue, but the the other configs reside in MobileFrontend. We can do something like api.defaults.ajax.url = 'https://en.m.wikipedia.org/w/api.php' but do we want to?

Ex: https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/445203/

Acceptance criteria

  • Search can be configured to arbitrary URLs. For example, it should be possible to search production enwiki pages from a local instance with no pages.
  • Reduce the amount of development-code shipped to production

Event Timeline

Restricted Application changed the subtype of this task from "Deadline" to "Task". · View Herald TranscriptDec 21 2018, 5:36 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Jdlrobson lowered the priority of this task from Normal to Low.Dec 21 2018, 6:44 PM
Jdlrobson added a subscriber: Jdlrobson.

The issue here is CORS. Nearby uses JSONP to get around the CORs issue. $wgMFPhotoUploadEndpoint is actually used in production not development, to access commons from Wikipedia.

I'd be in favor of a single development URI to replace $wgMFNearbyEndpoint and set api.defaults.ajax.url but we'd need to solve the CORs issue first. For that I've not had any ideas (hence why the status quo)

Change 482233 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Modernise api proxying in MobileFrontend

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

Change 482234 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Introduce queryProps helper

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

Jdlrobson raised the priority of this task from Low to Normal.EditedJan 8 2019, 2:40 AM
Jdlrobson removed a project: Spike.

I had a tinker with this last week as I needed to test the LanguageOverlay. I'm quite happy with the suggested solution I've come up with - it throws away code, DRYs some things up and most importantly allows us to test more workflows locally!

Change 482233 merged by Jdlrobson:
[mediawiki/extensions/MobileFrontend@master] Modernise api proxying in MobileFrontend

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

Hi, For the ExternalGuidance project, we have a usecase where when a content is presented in external context such as Google translate, the search feature in mobile frontend should work. Currently when our content is presented in a foreign domain, sometimes under an iframe like google translate, the search feature in mobile frontend fails because of CORS. See T212314: Review additional elements exposed by external services that may not work

So, it is not only the case for a developer's localhost get the search working with production content and APIs.

Currently this is what happening: When searched, the progress indicator is shown and nothing else happens. There is CORS error in console.

If this task can help to unbeak this usecase, it would be great.

Jdlrobson added a comment.EditedJan 10 2019, 4:31 PM

If this task can help to unbeak this usecase, it would be great.

This task is purely for development and not intended for public consumption so won't help this particular issue (to be clear the issue you are talking about has security concerns). The CORS issue with Google is actually a lot easier to address. It would require adding translate.google.com to the trusted domains inside $wgCrossSiteAJAXdomains - easy to do technically, but might prove a little trickier socially!

Change 482234 merged by Jdlrobson:
[mediawiki/extensions/MobileFrontend@master] Generalise api proxying - Introduce actionParams helper

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

Jdlrobson closed this task as Resolved.Jan 15 2019, 11:44 PM

I don't think there's anything more to do here. Given T122721 and authentication needs it seems unlikely we can support write API requests.