Page MenuHomePhabricator

Lingo and VisualEditor compatibility: HTTP 401 errors
Closed, ResolvedPublic

Description

I run a private wiki running Mediawiki 1.26.2. Visual Editor is stable and works well (I am using NetworkAuth to allow communication between Parsoid and MW), however enabling Lingo breaks Visual Editor returning HTTP 401 errors.

With the Lingo extension disabled it works perfectly well.

All that is changing is the line in LocalSettings.php

wfLoadExtension('Lingo');

I installed within the mediawiki folder using:

php composer.phar require mediawiki/semantic-media-wiki "~2.0"

which returned no errors.

Happy to provide any useful debugging information, LocalSettings.php etc. etc.

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptMay 17 2016, 8:03 PM
Aklapper renamed this task from Visual Editor compatibility to Lingo and VisualEditor compatibility: HTTP 401 errors.May 19 2016, 2:07 PM

Lingo changes the HTML code after it is produced by the MW parser. There have been problems in the past where some JavaScript code expected a certain structure of the HTML code and did not work after Lingo modified it. I don't know if this is the cause for the bug, but it may well be.

Hmmm where I mention "semantic-mediawiki" above, that would be "lingo" for installation via Composer. Doh!

Sometimes instead of HTTP 401 errors, I get HTTP 500 errors: "Error loading data from server: 500: parsoidserver-http: HTTP 500. Would you like to retry?". Infinite retrying doesn't seem to help.

Parsoid logs a "readapidenied". I am unsure why this is a problem as it only occurs if Lingo is enabled. See, for example:

[fatal/request][localhost/Earthing_policy] API response Error for TemplateRequest: request=; error={"code":"readapidenied","info":"You need read permission to use this module","*":"See https://test1.tpwiki.com/mediawiki/api.php for API usage"}
Error: API response Error for TemplateRequest: request=; error={"code":"readapidenied","info":"You need read permission to use this module","*":"See https://test1.tpwiki.com/mediawiki/api.php for API usage"}
    at TemplateRequest.ApiRequest._errorObj (/usr/lib/parsoid/src/lib/mw/ApiRequest.js:340:9)
    at TemplateRequest._handleJSON (/usr/lib/parsoid/src/lib/mw/ApiRequest.js:529:16)
    at TemplateRequest.ApiRequest._handleBody (/usr/lib/parsoid/src/lib/mw/ApiRequest.js:458:7)
    at TemplateRequest.ApiRequest._requestCB (/usr/lib/parsoid/src/lib/mw/ApiRequest.js:413:8)
    at Request.self.callback (/usr/lib/parsoid/node_modules/request/request.js:198:22)
    at Request.emit (events.js:98:17)
    at Request.<anonymous> (/usr/lib/parsoid/node_modules/request/request.js:1063:14)
    at Request.emit (events.js:117:20)
    at IncomingMessage.<anonymous> (/usr/lib/parsoid/node_modules/request/request.js:1009:12)
    at IncomingMessage.emit (events.js:117:20)

It appears that somehow Lingo forces Parsoid requests to go badly... Not quite sure how to diagnose further at this stage.

I've tested a little more.

If, in `LocalSettings.php```:

$wgGroupPermissions['*']['read'] = true;

Then Lingo functions nicely with VisualEditor. When clicking Edit, a page opens in VisualEditor without any difficulty. If:

$wgGroupPermissions['*']['read'] = false;

Then HTTP 500 or HTTP 401 errors occur when clicking Edit on a page and Parsoid logs ReadAPI errors like those above.

Is this a limitation on the presentation version of Lingo that when it carries out page requests it does not check or login using the API?

Foxtrott triaged this task as Medium priority.Oct 5 2016, 9:58 PM
Foxtrott moved this task from Backlog to Bugs-High Prio on the MediaWiki-extensions-Lingo board.

I can reproduce it, but I have absolutely no idea what the problem could be. :(

@Foxtrott

I have a little spare time later this week and would like to look at this issue. Do you have any hints on how I could diagnose it? I have modest skills and may very likely fail but I am interested :-)

Would be great if you could give it a stab.
I have no idea what's going on here. There is also T123968 which may be related.
First thing I would try to find out is if maybe Lingo at some point accesses or creates a generic User object that lacks permission to do something or other. Another approach might be to find out where exactly the 401 is triggered and go backwards from there.

I've done some testing:

  • With Mediawiki 1.26.2 and Lingo 2.0.1, as a private wiki, using NetworkAuth for Parsoid access. Visual Editor 'Edit' HTTP 401 and HTTP 500 errors still occur when I click on the 'edit' button.
  • Repeating the same test with Mediawiki 1.27.0 and Lingo 2.0.1, there are no errors and Lingo functions correctly with both the 'Edit' and 'Edit Source' options.
  • Repeating the same test with Mediawiki 1.27.1 and Lingo 2.0.1, there are no errors and Lingo functions correctly with both the 'Edit' and 'Edit Source' options.

In each case I have used identical configurations.

I presume there was an upstream issue in Mediawiki core or Visual Editor which is now resolved. Given that MW 1.27 is an LTS release probably the effort of finding exactly where or why this occurred with MW 1.26.2 (and possibly earlier) isn't worthwhile.

Can you confirm and if appropriate please close this issue?

Dan.mulholland closed this task as Resolved.Dec 10 2016, 8:12 AM

Closing to be nice and tidy.