Marc Chang's picture

I have sucessfully installed and running https://www.turnkeylinux.org/mediawiki

The server is running on a private address (192.168.x.y) with the Turnkey self-signed certificates. After adding the modifications below to make a private Wiki VisualEditor is not working. I get the error:

Error contacting the Parsoid/RESTBase server: http-request-error

I think it's because VisualEditor is doing a http request to itself and the self-signed SSL certificate is not accepted? Has anybody succesfully installed VisualEditor in a private wiki?

==

Made the following modifications in /var/www/mediawiki/LocalSettings.php

(inserted at the end of the file)

# Disable reading by anonymous users
$wgGroupPermissions['*']['read'] = false;
# But allow them to read e.g., these pages:
$wgWhitelistRead =  [ "Main Page", "Help:Contents" ];
# Allow Jobs to be run
$wgWhitelistRead = [ "Special:RunJobs" ];

# Requires that a user be registered before they can edit.
$wgGroupPermissions['*']['edit'] = false;

# Prevent new user registrations except by sysops
$wgGroupPermissions['*']['createaccount'] = false;

if ( !isset( $_SERVER['REMOTE_ADDR'] ) OR
     in_array($_SERVER['REMOTE_ADDR'],
       [
         $_SERVER['SERVER_ADDR'],
         $_SERVER['HTTP_X_FORWARDED_FOR'], # if MediaWiki behind reverse proxy
         '127.0.0.1',
         'localhost',
       ]
     ) 
   ) {
  $wgGroupPermissions['*']['read'] = true;
  $wgGroupPermissions['*']['edit'] = true;
  $wgGroupPermissions['*']['writeapi'] = true;
}

 

Forum: 
Jeremy Davis's picture

I suspect that you are right that the issue is the self signed cert!

So the "proper fix" is to get an SSL cert. If your server is using a registered domain name and is publicly available, that is pretty easy to get a free cert via the Confconsole Let's Encrypt plugin.

If that's not an option, then the next best thing would probably to just use plain http (i.e. no SSL at all). To do that, you'll need to remove the http -> https redirect. Here is what the default Apache config (/etc/apache2/sites-available/mediawiki.conf) looks like (yours may be slightly different but should be close). Note that the redirect is within the '<VirtualHost *:80>' section (which is for plain http).

To remove the redirect, you just need to comment out the relevant lines. I.e. put a '#' in front of the line (it can go right at the start of the line if you like, but I prefer to indent it so it looks nicer). E.g.:

    #RewriteEngine On
    #RewriteCond %{HTTPS} !=on
    #RewriteRule ^/(.*) https://localhost/$1 [R,L]

Then you'll also need to add a DocumentRoot directive to the http config section (because there was a redirect, it wasn't required previously; now there is no redirect, you'll need it). I.e. just copy the line from the '<VirtualHost *:443>' (https) section into the '<VirtualHost *:80>' (http) section.

    DocumentRoot /var/www/mediawiki/

So the final product should look something like this:

ServerName localhost

<VirtualHost *:80>
    UseCanonicalName Off
    ServerAdmin  webmaster@localhost
    #RewriteEngine On
    #RewriteCond %{HTTPS} !=on
    #RewriteRule ^/(.*) https://localhost/$1 [R,L]
    DocumentRoot /var/www/mediawiki/
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on
    ServerAdmin  webmaster@localhost
    DocumentRoot /var/www/mediawiki/
    # Mediawiki itself redirects to domain
</VirtualHost>

<Directory /var/www/mediawiki/>
    Options +FollowSymLinks -Indexes
    AllowOverride All
    Require all granted
</Directory>

Finaly, you need to restart Apache to apply the new config:

systemctl restart apache2

Hopefully that fixes it. If not, please let me know and we can go from there...

Marc Chang's picture

After you have changed the Apache configuration, don't forget to set $wgServer.

It could be

$wgServer = "http://<IP ADDRESS>";

or

$wgServer = "https://<IP ADDRESS>";

 

depending on if you use http or https.

Marc Chang's picture

Jeremy,

indeed the wiki is running over http. I can use this as a "fix".

Questions:

  1. Is it possible to have the applicance trust it's own self-signed certificate?
  2. Where can I fing the public/private key of the apliance?
  3. How to I add the appliance's key details to the list od trusted certificates?
Jeremy Davis's picture

Great to hear that works.

In answer to your questions:

  1. Yes it is. I've never done it and aren't 100% clear on exactly what steps are required, but by my understanding, you essentially need to create your own certificate authority, then sign your SSL cert with your CA key. You also need to configure the system to trust your CA. I'll have a bit of a look and post back if I find anything that seems particularly relevant.
  2. The public cert and private keys are in /etc/ssl/private/, both the public cert and private key (and Diffe-Hellman parameters) are contained within the cert.pem file and the private key is also within the cert.key file (we format them like that so all the services can use the same certificate).
  3. See #1.
Charlie C's picture

Jeremy, I am also having the same issue, except I have a wildcard certificate for my domain and while it is installed so that my browser sees my wiki as secure, it still gives me the same error that Marc was having when I try to use the Visual Editor.   Have you been able to find out what is needed to make this work with HTTPS?
Jeremy Davis's picture

A quick google turned up a couple of mediawiki threads with other's having the same issue:

So it seems likely to be a config issue, or perhaps it's related to javascript blocking in your web browser (if relevant - AFAIK the communication between the site and the visual editor likely happens via javascript within your browser).

FWIW (as you'll likely read in those threads), the error is related to the fact that the visual editor communicates via a separate URL, and as an anonymous user.

My guess is that if you open the web browser developer tools (all modern browsers should have something equivalent - if not, both Chrome & Firefox do) while trying to use the visual editor, you should see some more details. Likely explicit javascript errors related to the issue. My guess is that you'll see either a 404 (not found) if it can't connect for some reason; or a 403 (forbidden) if there is some permissions issue (my quick reading of those suggests the default visual editor config should "just work" for a public site that allows non-logged in users editing access).

Jeremy Davis's picture

Sorry this response is a little slow. I actually wrote it soon after my previous response, but only just realised that I hadn't published it.


As It seems that there are a myriad of potential issues related to the visual editor; which all seem to have very similar error messages (e.g 'http-request-error', 'http-bad-status', etc) it's probably a good idea to be really explicit about what is going on for you.

The fact that you have a proper cert makes it seem likely that (whilst the result is similar) your actual issue is completely different to Marc's. So sharing as much info as possible (perhaps even in your own thread?! - you need to be registered and logged in to start a thread) would be good. Even if it's just to explicitly confirm (point by point) that your scenario matches Marc's.

I say that as in my experience, there can sometimes be a huge difference between one person's "exactly the same" and the next person's. The less experience a person has with this sort of stuff, the easier it is to gloss over details that may actually be important. FWIW, when reporting bugs/issues, there is almost never "too much information"! Even if you think it's irrelevant, it may not be. Any info that is irrelevant I can gloss over; but I can't consider things that haven't been mentioned! :)

Matt Pilz's picture

If you are experiencing this problem only on existing pages, but are able to create a new page and add a heading/paragraph and save it again, the problem may be a glitch in the wiki formatting itself.  In my case after switching from the basic code-only editor to VisualEditor, any page that included a preformatted textblock that itself also contained URLs seemed to throw this error. I removed the offending block(s) and replaced them with INSERT → MORE → CODE BLOCK and the problem went away. I did not have to alter any other permissions or options even with a private wiki, it was just an odd parsing/content issue with some preformatted blocks. I have nothing special in LocalSettings.php, the following works fine (for private):  
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
 

Add new comment