Last modified: 2013-12-26 18:27:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T57369, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 55369 - Parsoid cannot connect to https-only host?
Parsoid cannot connect to https-only host?
Status: UNCONFIRMED
Product: Parsoid
Classification: Unclassified
General (Other open bugs)
unspecified
All All
: Normal enhancement
: ---
Assigned To: James Forrester
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-06 15:32 UTC by Mc128k
Modified: 2013-12-26 18:27 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mc128k 2013-10-06 15:32:30 UTC
Hi
When I run parsoid linked to a wiki which is https only, it doesn't work. This can be reproduced in any installation.

I set port 80 to be a redirect to port 443, and the parsoid URL is https://wiki.name/api.php in localsettings.js
Comment 1 Andre Klapper 2013-10-06 20:41:22 UTC
Hmm, shouldn't this be filed under product "Parsoid"? :)
Which Parsoid version and which MediaWiki version is this about?
Comment 2 Mc128k 2013-10-06 20:43:40 UTC
I'm sorry, I thought Parsoid was part of VisualEditor. Corrected. Thanks.
Latest git versions, of parsoid, mediawiki, visualeditor.
Comment 3 Gabriel Wicke 2013-12-04 00:58:16 UTC
I just tested this with 'enwiki' and

parsoidConfig.setInterwiki( 'enwiki', 'https://en.wikipedia.org/w/api.php' );

We don't set the port explicitly and use the API uri as-is, so in theory https-only APIs should work. Do you have a public https-only API URI we can test with?
Comment 4 Mc128k 2013-12-04 08:22:24 UTC
Debug log from parsoid:
 - worker(23680) ready
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 4 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 3 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 2 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 1 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 0 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
ERROR in localhost:Main_Page:
Page Fetch failure for null
Stack trace: DoesNotExistError: Page Fetch failure for null
worker 23671 died (1), restarting.
 - worker(23690) loading...
 - worker(23690) ready


I don't know if the API works from the external network, this is a protected wiki, I hope login won't be necessary.

https://wiki.mc128k.info
Comment 5 Chris Koerner 2013-12-05 18:45:24 UTC
I am experincing the same bug.

Attempting to evoke VisualEditor to edit any pages where we have redirected all traffic to https results in the error.


In the browser:
Error loading data from server:parsoidserver-hhtp-curl-error:
Empty reply from server. Would you like to retry?


Parsoid displays the following upon each attempt to edit a page (in this case Main Page):

ERROR in localhost:Main_Page
Stack trace: DoesNotExistError: Page Fetch failure for null
worker 20040 died, restarting.


MediaWiki logs show the following for the request:

Start request POST /w/api.php
HTTP HEADERS:
HOST: my.wiki.com
CONNECTION: keep-alive
CONTENT-LENGTH: 60
ACCEPT: application/json, text/javascript, */*; q=0.01
ORIGIN: https://my.wiki.com
X-REQUESTED-WITH: XMLHttpRequest
USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
CONTENT-TYPE: application/x-www-form-urlencoded; charset=UTF-8
REFERER: https://my.wiki.com/wiki/Main_Page?veaction=edit
ACCEPT-ENCODING: gzip,deflate,sdch
ACCEPT-LANGUAGE: en-US,en;q=0.8
COOKIE: __utma=198203634.575160840.1386267474.1386267474.1386267474.1; __utmb=198203634.2.10.1386267474; __utmc=198203634; __utmz=198203634.1386267474.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); infoUserID=378; infoUserName=Clkoerne; info_session=7200a1cbfcef48ded410afb07850a6fc
CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
[cookie] session_set_cookie_params: "0", "/", "", "1", "1"
LocalisationCache: using store LCStoreDB
Unstubbing $sfgFormPrinter on call of $sfgFormPrinter::setInputTypeHook from SFSelect_formSetup
Unstubbing $wgParser on call of $wgParser::setHook from ExtDynamicPageList::setupDPL
Parser: using preprocessor: Preprocessor_DOM
Connected to database 0 at lnxvmipdbt01
Class UniversalLanguageSelectorHooks not found; skipped loading
Fully initialised
User: got user 378 from cache
User: loading options for user 378 from override cache.
User: logged in from session
ApiMain::setCacheMode: setting cache mode private
IP: 10.9.191.150
Comment 6 Chris Koerner 2013-12-05 18:58:29 UTC
Addition:
Changing $wgVisualEditorParsoidURL to 'https://my.wiki.com:8000'; results in a different error.

Error loading data from server: parsoidserver-http-curl-error: SSL connect error. Would you like to retry?


Headers below:

Start request POST /w/api.php
HTTP HEADERS:
HOST: my.wiki.com
CONNECTION: keep-alive
CONTENT-LENGTH: 60
AUTHORIZATION: Basic bWVtY2FjadGU6cGFzc3dvcmQ=
ACCEPT: application/json, text/javascript, */*; q=0.01
ORIGIN: https://my.wiki.com
X-REQUESTED-WITH: XMLHttpRequest
USER-AGENT: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
CONTENT-TYPE: application/x-www-form-urlencoded; charset=UTF-8
REFERER: https://my.wiki.com/w/index.php?title=Main_Page&veaction=edit
ACCEPT-ENCODING: gzip,deflate,sdch
ACCEPT-LANGUAGE: en-US,en;q=0.8
COOKIE: infoLoggedOut=1386191878; __utma=198203634.1203293077.1386191715.1386191715.1386191715.1; __utmc=198203634; __utmz=198203634.1386191715.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); infoUserID=378; infoUserName=Clkoerne; info_session=4f15c368d4244cc2b9e72e06f65adc12; wikiEditor-0-booklet-characters-page=latin; wikiEditor-0-toolbar-section=advanced; vector-nav-p-Repository=true; vector-nav-p-tb=true
CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
[cookie] session_set_cookie_params: "0", "/", "", "1", "1"
LocalisationCache: using store LCStoreDB
Unstubbing $sfgFormPrinter on call of $sfgFormPrinter::setInputTypeHook from SFSelect_formSetup
Unstubbing $wgParser on call of $wgParser::setHook from ExtDynamicPageList::setupDPL
Parser: using preprocessor: Preprocessor_DOM
Connected to database 0 at lnxvmiptdbt01
Class UniversalLanguageSelectorHooks not found; skipped loading
Fully initialised
User: got user 378 from cache
User: loading options for user 378 from override cache.
User: logged in from session
ApiMain::setCacheMode: setting cache mode private
IP: 10.29.122.24
Comment 7 Gabriel Wicke 2013-12-05 19:05:37 UTC
Parsoid is only using HTTP, so trying to connect to it via HTTPS is going to fail. It can connect to MediaWiki using HTTPS though when configured to do so in localsetting.js. Please check the steps in https://www.mediawiki.org/wiki/Parsoid/Troubleshooting to make sure Parsoid is working.

> https://wiki.mc128k.info

Your SSL cert does not seem to be signed by a trusted CA, which likely explains your issue. Try with a signed SSL cert.
Comment 8 Mc128k 2013-12-05 19:55:47 UTC
I am sorry, I can't pay for a real certificate. Is there a way to add my root certificate to Parsoid? Does it use the system certificates?

Or as a workaround, is there a way to permit self-signed authorities?

Thanks.
Comment 9 Gabriel Wicke 2013-12-05 21:10:52 UTC
(In reply to comment #8)
> I am sorry, I can't pay for a real certificate. Is there a way to add my root
> certificate to Parsoid? Does it use the system certificates?
> 
> Or as a workaround, is there a way to permit self-signed authorities?

Your wiki actually works by setting the API URL to http://wiki.mc128k.info/api.php.

Nodejs uses openssl, so I'm guessing that you can install additional CA certs in /etc/ssl/certs/ (assuming you are using Debian).
Comment 10 Mc128k 2013-12-05 21:15:43 UTC
I know it works, it's a workaround. I am hosting the site in a CentOS server, but despite the research I have done some time ago I couldn't install the certificate in the system root, so neither PHP and node.js see the certificate. 

I will try again now. Is there any documentation you know about this? (sorry if it's off-topic)
Comment 11 Chris Koerner 2013-12-16 17:09:32 UTC
I've followed the troubleshooting guide and I'm still having issues connecting to a https-only host.

From the server I can run the following with success:

curl http://my.site.com:81/w/api.php

I opened port 81 to allow for http access to the api endpoint.

However I cannot seem to connect to Parsoid, the app in question. 

curl http://my.site.com:8000 returns the human-readable landing page for the Parsoid web service.

curl http://my.site.com:8000/localhost/Introduction

returns no message via the command line.

I can start Parsoid via node server.js

I can launch VisualEditor and edit a page normally, everything works.

server.js spits out the following:

starting parsing of localhost:Introduction
completed parsing of localhost:Introduction in 1660 ms

As soon as I go to save an edit, a small note appears under the Summary box.

Error: Unknown error.

server.js reports nothing


While Parsoid is running (node server.js) and I attempt the following

curl http://my.site.com:8000/localhost/Introduction

I see the message:

starting parsing of localhost:Introduction
redirected localhost:Introduction to revision 62067
Comment 12 Chris Koerner 2013-12-26 18:27:01 UTC
I wanted to update this bug with my findings. I now have 1.23wmf7 and the latest builds of Parsoid and VisualEditor working happily with SSL as the default (and forced) connection method for users.

In my LocalSettings.php I have the following:

//Hook it up to Parsoid
$wgVisualEditorParsoidURL = 'http://my.site.com:8000';
 
$wgVisualEditorParsoidPrefix = 'localhost';


In localsettings.js I have:

parsoidConfig.setInterwiki('localhost' , 'http://my.site.com:81/w/api.php');

You can see that we're directing traffic over port 81 to allow Parsoid access.

The issue I was experiencing related to saving a page was due to having an older version (pre 1.9) of Semantic MediaWiki installed with 1.23.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links