Issue using IntraACL with Visual Editor MediaWiki Extension

[SamWMTaylor]

Hello,

We have installed IntraACL and it appears to be working fine except when we try to use Visual Editor on a page already protected by IntraACL.

As soon as we hit the 'Edit' button we get an error saying

"Error loading data from server: parsoidserver-http-bad-status: 404: Did not find page revisions for Systems/Photoshop. Would you like to retry?"

The issue goes away if I grant 'All Users' full access to the protected page we are trying to edit. This isn't ideal as a normal user will be able to view a protected page whilst it's being edited.

We also use a plugin called PwAuthPlugin which pulls down passwords/authentication directly from Active Directory.

Visual Editor relies on a server called Parsoid, this (and all the processes it governs like, nodejs, npm and pm2 etc) is governed by the root user on our Centos server.

I just wanted to find out if anyone else has experienced this issue before and has a fix. With all the different combinations of Extensions we have I'm not confident there's a fix for this and we'll have to use the workaround above.

Thanks

[vitalif]

Do you have 'forwardCookies' => true in $wgVirtualRestConfig['modules']['parsoid'] in your LocalSettings.php?

[vitalif]

from my point of view VE & parsoid is a rather perverted and useless thing ))) but of course I also tried it out )) it should work with forwardCookies

[SamWMTaylor]

Hello Vitaliy,

Thanks for getting back.

Yes it's already set to true:

$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;

I'm inclined to agree, Parsoid is a very difficult and unintuitive thing to set up.

Just for info, here's the rest of our LocalSettings.php options connected to Visual Editor and Parsoid:

require_once "$IP/extensions/VisualEditor/VisualEditor.php";

// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;

// Don't allow users to disable it
$wgHiddenPrefs[] = 'visualeditor-enable';

// OPTIONAL: Enable VisualEditor's experimental code features
$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

// URL to the Parsoid instance
// MUST NOT end in a slash due to Parsoid bug
// Use port 8142 if you use the Debian package
$wgVisualEditorParsoidURL = 'http://127.0.0.1:8000';

// Interwiki prefix to pass to the Parsoid instance
// Parsoid will be called as $url/$prefix/$pagename
$wgVisualEditorParsoidPrefix = 'cgiwiki';

See if we can get rid of the 'add a comment dialog'

$wgVisualEditorUseChangeTagging = false;

// This feature requires a non-locking session store. The default session store will not work and
// will cause deadlocks (connection timeouts from Parsoid) when trying to use this feature.
$wgSessionsInObjectCache = true;

// WARNING: ONLY enable this on private wikis and ONLY IF you understand the SECURITY IMPLICATIONS
// of sending Cookie headers to Parsoid over HTTP. For security reasons, it is strongly recommended
// that $wgVisualRestConfig['modules']['parsoid']['url'] be pointed to localhost if this setting is enabled.
$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;

If you have any other thoughts do let me know.

thanks again

[vitalif]

Hm... it seems parsoid does not forward user cookie back to MediaWiki when requesting revision content. So IntraACL of course denies access to anonymous user.

this could be fixed by removing (&& !User::isEveryoneAllowed('read')) condition at line 79 of ApiVisualEditor.php in VisualEditor extension, but when I remove it on my wiki, Parsoid is unable to do MW api requests. I tried to understand WHY it's unable, but in last 20 minutes I didn't succeed O_O the HTTP request from nodejs to MediaWiki (apache2 behind nginx) just hangs, it looks like nodejs closes the connection by itself before receiving the request!!! The same request done with browser or with netcat completes without problem.

The request is:

GET /wiki/api.php?format=json&action=query&meta=siteinfo&siprop=namespaces%7Cnamespacealiases%7Cmagicwords%7Cfunctionhooks%7Cextensiontags%7Cgeneral%7Cinterwikimap%7Clanguages%7Cprotocols%7Cspecialpagealiases&rawcontinue=1 HTTP/1.1
X-Request-ID: null
User-Agent: Parsoid/0.4.1+git
Connection: close
Cookie: wikiEditor-0-toolbar-section=advanced; mediawikiUserID=2; mediawikiUserName=VitaliyFilippov; mediawikiToken=...........; mediawiki_session=............
host: yourcmc.ru

[anshum17]

So is there any way by which we can use Visualeditor with IntraACL?
I am facing "error loading data from server: 500 parsoidserver-http"

[belonesox]

Yes, we have to patch one line in Visual Editor. I just preparing to publish deployement scripts of MediaWiki4Intranet by Vagrant+Ansible, where IntraACL and VisualEditor works together.
https://github.com/belonesox/mediawiki4intranet-vagrant-ansible

[anshum17]

"I just preparing to publish deployement scripts of MediaWiki4Intranet by
Vagrant+Ansible"

Did not understand this.

Also I have 1 more query. There is one "File List" page. This page is not
protected and anybody can see the media files. Ideally files on protected
page should also be protected, but it is not happening.

So am I missing something here or is it a developing feature?

Thanks,
Anshum

On Sat, Sep 10, 2016 at 2:03 AM, Stas Fomin [email protected]
wrote:

Yes, we have to patch one line in Visual Editor. I just preparing to
publish deployement scripts of MediaWiki4Intranet by Vagrant+Ansible, where
IntraACL and VisualEditor works together.
https://github.com/belonesox/mediawiki4intranet-vagrant-ansible

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#53 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIVGELSu0ON52vI6gA8XyIZCGLealEvJks5qocKygaJpZM4InZrL
.

[vitalif]

"I just preparing to publish deployement scripts of MediaWiki4Intranet by Vagrant+Ansible"

That was slightly offtopic.

Stas should push his fix to https://github.com/mediawiki4intranet/mediawiki-extensions-VisualEditor/commits/master and then switch the repository in configs/mediawiki4intranet.ini

Afaik it's the same fix as in my above comment:

removing (&& !User::isEveryoneAllowed('read')) condition at line 79 of ApiVisualEditor.php

This looked like the proper fix from the beginning, but it didn't work when I checked it previous time. I'll recheck if it works with newer versions of VE.

This page is not protected and anybody can see the media files.

First of all, are you saying the page is NOT protected? :) obviously anyone can read it if it's not protected :)

Secondly, files in MediaWiki aren't "attachments to pages", they are globally named and independent entities. So if you want to protect files with IntraACL, you should create ACLs for File: namespace, files themselves or place them into a protected category.

[anshum17]

Hi,

After making suggested changes i.e. removing code from line 79. I am still
facing the same issue. :(

On browser I am getting 'error loading data from
server:500:parsoidserver-http:HTTP 500'.

And in parsoid logs:
{"code":"rvaccessdenied","info":"The current user is not allowed to read
Scrapbooking"}
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.EventEmitter.emit (events.js:98:17)
at Request.
(/usr/lib/parsoid/node_modules/request/request.js:1063:14)
at Request.EventEmitter.emit (events.js:117:20)
at IncomingMessage.
(/usr/lib/parsoid/node_modules/request/request.js:1009:12)
at IncomingMessage.EventEmitter.emit (events.js:117:20)

On Wed, Sep 14, 2016 at 1:27 AM, Vitaliy Filippov [email protected]
wrote:

"I just preparing to publish deployement scripts of MediaWiki4Intranet by
Vagrant+Ansible"

That was slightly offtopic.

Stas should push his fix to https://github.com/
mediawiki4intranet/mediawiki-extensions-VisualEditor/commits/master and
then switch the repository in configs/mediawiki4intranet.ini

Afaik it's the same fix as I told above:

removing (&& !User::isEveryoneAllowed('read')) condition at line 79 of
ApiVisualEditor.php

This looked like the proper fix from the beginning, but it didn't work
when I checked it previous time. I'll recheck if it works with newer
versions of VE.

This page is not protected and anybody can see the media files.

First of all, are you saying the page is NOT protected? :) obviously
anyone can read it if it's not protected :)

Secondly, files in MediaWiki aren't "attachments to pages", they are
globally named and independent entities. So if you want to protect files
with IntraACL, you should create ACLs for File: namespace, files themselves
or place them into a protected category.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#53 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIVGEMMVSTCNTKW8pjq_VymKn6f8ThHUks5qpwAQgaJpZM4InZrL
.

[vitalif]

Oh shit! I've found the problem with "hanging" nodejs mediawiki API requests with VisualEditor fix applied.
The problem is PHP's session lock mechanism! When someone calls session_start() PHP locks it exclusively and unlocks only on session_write_close() or when the request ends. The lock itself isn't bad - the session data is overwritten every time so you'll definitely end up with race conditions if you don't lock it. The bad point is that PHP programmers (and MediaWiki authors are no exception) usually don't bother about clever session handling and just keep it open for the whole request. This basically means such PHP setups can't handle more than 1 request for 1 user in parallel. And look what happens when you use parsoid?

• browser sends an API request to MediaWiki (PHP)
• PHP sends a request to Parsoid and always forwards user cookies with the above fix (!)
• Parsoid (while processing PHP's request) sends another request back to PHP as it needs some info from it and it includes the forwarded cookies...
• ...so PHP gets another request from the same user while the previous is still active and the session is still locked.

Bang, a deadlock. PHP and nodejs are waiting for each other.
And it's not very simple to fix because we need to improve MediaWiki's session handling to fix it (i.e. patch mediawiki core). I'll of course make this patch and include it in our bundle (https://github.com/mediawiki4intranet/core) but I'm not giving any promises about getting it merged to upstream.

[belonesox]

«Did not understand this.»
I meant «IntraACL+VisualEditor» looks working in this installation
https://github.com/mediawiki4intranet/mediawiki4intranet-vagrant-ansible

[vitalif]

OK, I've committed the session lock fix into mediawiki4intranet bundle. I.e. you can use repo.php to install it from https://github.com/mediawiki4intranet/configs (check readme)

If you want to install the fix manually (without mediawiki4intranet bundle) you need this patch to mediawiki core: mediawiki4intranet/core@7233161 (this one is for 1.26), and also patches for ConfirmEdit and OpenID extensions if you have them installed (or they'll be broken): mediawiki4intranet/ConfirmEdit@be1cc8b and mediawiki4intranet/OpenID@5425b2a and this patch for VisualEditor: mediawiki4intranet/mediawiki-extensions-VisualEditor@cfa7274 (or just install it from here: https://github.com/mediawiki4intranet/mediawiki-extensions-VisualEditor/commits/REL1_26_INTRAACL)

P.S: I've also made a repository with docker images for mediawiki4intranet. There are 2 versions - with and without VE. You can also try it out: https://github.com/mediawiki4intranet/docker (it's really the simplest way to install mediawiki4intranet)

[centaure]

I saw your detailed comment on how to debug/fix this. Thx!

[Mayzie]

@vitalif

Is this still relevant for 1.27? I noticed there were several deprecation hints in the functions you were patching (and they were radically different).

[vitalif]

I'm pretty sure yes. Functions may be different, but I don't think something changed in MW session handling... In fact, the problem is funny: everyone uses PHP and nobody usually cares about session locks :)

[Mayzie]

Seems like, at least for 1.27 and onwards, they are in the process of overhauling their session management system, so a lot of those patches mentioned in your comment are irrelevant :-( Which is a shame as I am still experiencing deadlocks within PHP when using Visual Editor + IntraACL.

[Mayzie]

@vitalif

It appears those patches are no longer necessary for MediaWiki >= 1.27. The bug I was experiencing was completely unrelated. :-)