Topic on Extension talk:VisualEditor

The key here is the message in your Firefox console: "Blocked loading mixed active content." You are running MediaWiki through SSL, but the server is making an unsecured RESTBase request to http://localhost:7231/... It looks as if you already run stunnel because you are serving Parsoid through SSL port 8143, so run RESTBase via stunnel through SSL port 7232. Of course, change all the references to port :7231 to port :7232.

Many thanks for this remark, I had a test wiki on HTTPS and got the error "Error loading data from server: Could not connect to the server" when switching WT -> VE. After severe doubts in my configuration given the sparse documentation, I thought it was because Restbase was only accessible on IPv6 in my installation, but indeed the issue was the mixed-content HTTPS (I thought Firefox would emit an alert but it (almost) silently refuse the connection, there is only this message in the console).

If the MediaWiki is just accessed locally, then SSL is of no use, so instead of configuring RESTBase with SSL, you might want to just use plain HTTP for all other services.

If you, however, want to remotely access MediaWiki, then

>> $wgVisualEditorRestbaseURL = "http://localhost:7231/localhost/v1/page/html/";

needs to be modified; it defines the URL used by the client (e.g., Firefox) to access the RESTBase server directly, and "localhost" needs to be changed to a remotely accessible FQDN / IP address to make it work.

The comment by John p new would still apply.

(At least this is how I understood it — someone correct me if I am wrong.)

Aaaand you have run into the same CORS roadblock that I have (same error messages, same result). I was hoping you wouldn't run into it and I could get some advice from you. :-)

Now that someone else has the same issue, I'm going to head over to the wikitech-l mailing list and ask some questions (I've gotten a couple of answers so far that have helped me solve at least part of the VE/Parsoid/RESTBase setup puzzle).

When I get an answer from that list, I will come back here and report, hopefully with a solution.

One step further: I installed nginx-extras and added these lines to my nginx-config: to the server-part:

        more_set_headers 'Access-Control-Allow-Origin: * always';
        more_set_headers 'Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE, HEAD';
        more_set_headers 'Access-Control-Allow-Credentials: true';
        more_set_headers 'Access-Control-Allow-Headers: Origin,Content-Type,Accept,Authorization';

and to the 'location / {' part:

     if ($request_method = 'OPTIONS') {
        more_set_headers 'Access-Control-Allow-Origin: * always';
        more_set_headers 'Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE, HEAD';
        more_set_headers 'Access-Control-Max-Age: 1728000';
        more_set_headers 'Access-Control-Allow-Credentials: true';
        more_set_headers 'Access-Control-Allow-Headers: Origin,Content-Type,Accept,Authorization';
        more_set_headers 'Content-Type: text/plain; charset=UTF-8';
        more_set_headers 'Content-Length: 0';
        return 204;
        }

and now VE is working ok for existing pages i.e. I am able to switch back and forth without saving.

But creating new pages, still show the CORS error ....

I am optimistic we will find a solution, an I know I am not the only one fighting :=)

BTW: I also did a 'npm install cors', but not sure if need and/or helpful TieMichael (talk) 09:00, 4 March 2017 (UTC)

>> Aaaand you have run into the same CORS roadblock

One way is to have the content served from the RESTBase server coming from the same domain:port as your MediaWiki content — this way, you won't have any cross origin issues.

I think this is the same way MediaWiki.org does it. I looked at the requests being sent when switching between editors, and they all go to mediawiki.org:80, so their RESTBase server gets accessed through the same domain:port (i.e., mediawiki:80).

To have the MediaWiki content and the RESTBase content both being served on the same domain:port, you have to configure a reverse proxy on your Web server (e.g., Apache or NGINX) to proxy all requests matching the URL-path of requests destined to the RESTBase server.

For example, if your RESTBase server URL is configured in your MediaWiki's LocalSettings.php as

>> $wgVisualEditorRestbaseURL = "https://wiki.mypage.com:7232/localhost/v1/page/html/";

where "localhost" is the domain on which MediaWiki is being served (it should actually be a remotely accessible domain, such as "wiki.mypage.com", since you want to give remote access to your MediaWiki), then you need to set up a reverse proxy handling all requests with a URL-path of "/localhost/" (or if you want remote access, "/wiki.mypage.com/").

You can exactly determine the URL-path by checking your MediaWiki's LocalSettings.php file and taking the value you specified as "domain" (remember, the "domain" value is an arbitrarily chosen string, but it must match across all configurations [MediaWiki, Parsoid, and RESTBase]).

I know that you are using NGINX, but I am using Apache, and my configuration looks like this:

   <VirtualHost *:80>
          ProxyPreserveHost On
   
          # Use a trailing slash to match everything starting with /wiki.mypage.com/...
          # See: https://httpd.apache.org/docs/2.2/en/mod/core.html#location
          <Location "/wiki.mypage.com/">
             ProxyPass http://restbase:7231/wiki.mypage.com/
             ProxyPassReverse http://restbase:7231/wiki.mypage.com/
          </Location>
   
          # MediaWiki is located here:
          DocumentRoot /var/www/html
   
    </VirtualHost>

Note that "/wiki.mypage.com/" in the <Location> directive above refers to the value you have specified as "domain" in your MediaWiki, Parsoid, and RESTBase configuration files (again, it is an arbitrarily chosen string).

In the context above, "restbase" is a hostname which resolves to your RESTBase server's IP address, so in your setup, it could just be "localhost", since you said you have all 3 services (MediaWiki, Parsoid, and RESTBase) running on the same machine.

The problem, at least in my case, is that my MediaWiki content is served from a shared host. Because of that, I can't run Node.js/Parsoid/RESTBase on that host, so I set up a home server and pointed MediaWiki to it.

Since I also don't have access to the web server configuration, can a reverse proxy be set up using the .htaccess file?

If I can't solve the CORS issue, I have considered transferring my MediaWiki server to my home server, which would avoid this issue. If I do this, I will definitely try your Apache configuration.

Another solution would be to set everything up on a VPS where you have root access, but of course with more control comes more cost.

I got a VPS for ~3 USD per month, so no real costs there.

>> Since I also don't have access to the web server configuration, can a reverse proxy be set up using the .htaccess file?

I don't know.

Hello,

46.166.190.204 from above here.

@ElucTheG33K, you have to specify your web server's SSL certificate in your php.ini. Find the section below in php.ini, and modify the path to the SSL certificate to match your environment.

[curl]
; A default value for the CURLOPT_CAINFO option. This is required to be an
; absolute path.
curl.cainfo = "/usr/local/etc/php/ssl/mywiki.crt"

You can manually provoke the cURL error 60 by trying to access your web server from the server handling the PHP requests (possibly the same server).

bash-4.3# curl https://wiki.mypage.lcl
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Now, the same, but with the web server's certificate specified.

bash-4.3# curl https://wiki.mypage.lcl --cacert /etc/nginx/ssl/mywiki.crt
<successful request>

This only indirectly relates to the original error stated, but because this page is at the top of Google's search results, and it can solve another problem related to SSL / TSL, Visual Editor, VisualEditor, Mediawiki, error 60 about peer certificate, and stunnel, I'm posting it here to hopefully save someone a lot of work.

I'm working with CentOS 7.6, Mediawiki 1.33, and other, as of 9.2019, up to date services like parsoid, etc. I'm not including all of the details to set up Visual Editor to work with SSL, just the solution for the issue I ran into.

I could not get VisualEditor, Parsoid, and Mediawiki to work with a self signed certificate, even when setting the strictSSL: false setting in the config.yaml file.

I also couldn't get a certificate obtained from GoDaddy to work until I found the solution.

Inexpensive SSL / TSL certificates usually come with and require an intermediate certificate. To get it to work I got a key tip from this posting: https://serverfault.com/questions/254795/how-do-i-ensure-that-stunnel-sends-all-intermediate-ca-certs

Solution: Configure the STUNNEL configuration files cert line to point to a single file that contain the server certificate and intermediate certificate.

Example line for STUNNEL configuration file:

cert = /WhatEverPathName/CertificateFile (can be a .crt or .pem file), where CertificateFile contains the signed server certificate and intermediate certificate in that order (IE intermediate at the end of the file).

I was too getting same issue but i have resolved in my wiki1.31

These are the wiki config:

$wgMathFullRestbaseURL= 'https://mywikiurl.com/gd_endpoint/localhost/'; #Restbase Server

$wgVirtualRestConfig['modules']['restbase'] = array(

         'url' => 'https://mywikiurl.com/gd_endpoint/',

        'domain' => 'localhost',

);

---

---

---

These are the Proxy(Apache) setting:

#setting proxy start here

        SSLProxyEngine on

        <Location /gd_endpoint/>

                ProxyPass http://ashsd95054.becpsn.com:7231/

                ProxyPassReverse https://ashsd95054.becpsn.com:7231

                Order deny,allow

                Deny from all

                Allow from all

        </Location>

        #setting proxy end here

<VirtualHost *:443>

        DocumentRoot /var/www/html

        #ServerName www.yourdomain.com

        SSLEngine on

        #setting proxy start here

        SSLProxyEngine on

        <Location /gd_endpoint/>

                ProxyPass http://your restbase server .com:7231/

                ProxyPassReverse https://your restbase server .com:7231

                Order deny,allow

                Deny from all

                Allow from all

        </Location>

        #setting proxy end here

        SSLCertificateFile /etc/httpd/ssl/www.cer

        SSLCertificateKeyFile /etc/httpd/ssl/dev.key

        SSLCertificateChainFile /etc/httpd/ssl/crt.cer

</VirtualHost>