There is a similar feature for forwarding cookies, to be used when MediaWiki's authentication is required view pages: https://www.mediawiki.org/wiki/Extension:VisualEditor#Forwarding_cookies_to_Parsoid.

I'm not really familiar with how that works, but probably something similar can be done for the HTTP basic auth headers.

Alternatively, maybe it's already possible to do this if you hard-code the HTTP username and password into the URL configured in $wgVirtualRestConfig['modules']['parsoid']['url']?

In T269508#6674241, @matmarex wrote:

Alternatively, maybe it's already possible to do this if you hard-code the HTTP username and password into the URL configured in $wgVirtualRestConfig['modules']['parsoid']['url']?

Yeah, probably. And if that doesn't work, it could probably be made to work.

In T269508#6674691, @cscott wrote:

In T269508#6674241, @matmarex wrote:

Alternatively, maybe it's already possible to do this if you hard-code the HTTP username and password into the URL configured in $wgVirtualRestConfig['modules']['parsoid']['url']?

Yeah, probably. And if that doesn't work, it could probably be made to work.

Except if your basic auth is linked to the account editing the wiki, which is the case in one of our wikis. The wiki runs on a subdomain devoted to internal tools that all use the basic auth header for username/account identification. That means we're using https://www.mediawiki.org/wiki/Extension:Auth_remoteuser . If we would configure a specific Parsoid login, then I would expect history would all be attributed to that user, which is of course not acceptable.

If we would configure a specific Parsoid login, then I would expect history would all be attributed to that user, which is of course not acceptable.

For what it's worth, we only use this URL for reading (and for some data transformations without side-effects), but not for saving, so this specific issue would not occur.

If you have users with different access rights, then that'd be a problem, as this might allow them to view pages they're not supposed to. Otherwise I think it would work.

I configured an SSL client certificate on nginx in front of MediaWiki 1.37, it mostly works except the VisualEditor due to this issue, and at the contrary of basic auth it’s absolutely impossible to forward authentication tokens for this configuration.

I used a workaround to make it working: define the wiki itself as 127.0.0.1 in /etc/hosts and allowlisting 127.0.0.1 in nginx configuration (see this stackoverflow question), but it’s quite hacky.

It would be great if internal parsoid requests could be routed internally (within PHP) instead of routed externally through the webserver, at least for small-medium-size wikis with a specific configuration parameter – I understand Wikimedia want to keep its current infrastructure to dedicate specific workers for REST/Parsoid.

This shouldn't be an issue in MW 1.39, which doesn't require a separate REST request for zeroconf VE: T305108: Zero Config Install of VE + Parsoid for MW 1.39

Indeed, I tried it out, it works fine! That's great news. Would this task still be relevant for setups where Parsoid is hosted separately (I have no clue about how such setups are used in practice), or can it be closed?

I also tried on MW 1.39 behind an SSL client authentication, it works great! Thanks @cscott!

I find this task can be closed: it is fixed in 1.39+. I guess that, nowadays, setups where Parsoid is hosted separately are big setups like Wikimedia’s and there is no need to transmit the frontend authentication (HTTP auth, SSL client cert, etc.) to backend servers.

Here is a solution for Apache users.

In T269508#8254212, @Kghbln wrote:

Here is a solution for Apache users.

As mentioned above, these kinds of workarounds will no longer be necessary as from MediaWiki 1.39. There will no longer be an internal request that can hit onto any auth restrictions.

Thanks for the info. Good to know that MW 1.39 will work out of the box. Currently, I am on 1.35, thus I need the preliminary solution.