Extension talk:Push

Previous page history was archived for backup purposes at Extension talk:Push/LQT Archive 1 on 2015-07-10.

any ideas what this error means? The two wikis are on the same server.

Reported in https://phabricator.wikimedia.org/T267641.

Hi,

I have this configured with the correct credentials in LocalSettings.php. When I push to the remote wiki, it says the pushed completed. However, I can not find the page on the target wiki. What am I doing wrong?

Also, for remote sites using https, the authentiation fails.

I think this has been broken for a while. It worked on one site I have, not another. And monkeying with the configs in every way I could think of, didn't seem to fix it. Which is a shame, as anyone doing a normal staging->final type config would find this incredibly useful.

My work-around (annoying as it is), is to keep a list of every file I touch, then manually do an export/import, instead of an "as I go" workflow.

Authentication at http://[ip:port]/wiki_name/api.php failed is the error I am encountering every time. The $egPushLoginUsers['Server MW 1.18'] and $egPushLoginPasswords['Server MW 1.18'] values are correct and that user has rights to create page on Target Wiki. Also, have installed the extension on target wiki and given all rights to the user. Am I missing something here ? Or is this a firewall / network issue and not an authentication one ?

I've found that I get that error when trying to do https

Hmm.... I resolved the issue by making the other wiki receptive for the images and content. Also, check the username given, if you have copied it then there might be a whitespace which gets passed leading to error while authentication.

Pdr3112: Been a while since you posted this: What did you mean by receptive for the images and content? I am stuck with the same error, permissions look right as do the credentials.

@Darthwonka Did you ever get this figured out?

I am running into this same error. I verfied the login and password for the target wiki. The wiki i'm pushing to and the wiki I'm pushing from both have an https root. @Pdr3112, can you please explain what you meant by making the wiki "receptive to images and content"?

@Steadyclimb Did you ever find a solution?

http://ip:port OR http://username:password@ip:port

Its a very nice and useful extension and we use it inside a wiki farm.

but helpful would be a information about pushed articles, like a push log history. a log file would be enough for the first steps.

Interesting idea. Where would the push log be stored, and what info would each entry in the log contain?

In any case, can you fund the development of such a feature?

TCDOAI-9: Push completed

TCDOAI-8: Push failed: Authentication at http://mydomain.com/mediawiki/api.php failed.

TCDOAI-7: Push completed

TCDOAI-6: Push completed

TCDOAI-5: Push failed: Authentication at http://mydomain/mediawiki/api.php failed.

TCDOAI-4: Push completed

TCDOAI-3: Push failed: Authentication at http://mydomain/mediawiki/api.php failed.

TCDOAI-2: Push completed

TCDOAI-1: Push completed

TCDOAllDMI-14: Push failed: Authentication at http://mydomain/mediawiki/api.php failed.

TCDOAllDMI-13: Push completed

TCDOAllDMI-12: Push completed

TCDOAllDMI-11: Push failed: Authentication at http://mydomain/mediawiki/api.php failed.

TCDOAllDMI-10: Push failed: Authentication at http://mydomain/mediawiki/api.php failed.

TCDOAllDMI-9: Push completed

TCDOAllDMI-8: Push failed: Authentication at http://mydomain/mediawiki/api.php failed.

TCDOAllDMI-7: Push completed

TCDOAllDMI-6: Push failed: Authentication at http://mydomain/mediawiki/api.php failed.

TCDOAllDMI-5: Push completed

TCDOAllDMI-4: Push completed

TCDOAllDMI-3: Push failed: Authentication at http://mydomain/mediawiki/api.php failed.

TCDOAllDMI-2: Push completed

TCDOAllDMI-1: Push completed

Push completed

Any idea why some pages randomly error with the authentication failed error? When pushing the failed pages individually, they successfully transfer over to the destination wiki. There are no API limits set. The only thing I can think of would be some kind of authentication limits that may be being hit randomly. The authentication is done via LDAP to a push user account created in Active Directory.

Also, for bulk pushing, is there no way to have it authenticate just once instead of having to authenticate for every single page?

I set up Push and successfully transfer pages that only contain text, but pages that contain embedded PDFs or images, even though I check the box to include images (which are shown next to the check box), are stripped. Any idea what is happening? Is there a setting somewhere that I need to change. I made sure the PHP.INI file allows for uploads.

I have the same problem and had hoped

$egPushDirectFileUploads=true;

for the source wiki would fix the problem but I get

Dateitransfer fehlgeschlagen: File upload param file is not a file upload; be sure to use multipart/form-data for your POST and include a filename in the Content-Disposition header.

I get this, no matter what I do.

File push failed: File upload param file is not a file upload; be sure to use multipart/form-data for your POST and include a filename in the Content-Disposition header.

Sounds like there's a bug in push, but I have no idea why, or how to fix it.

I got the same problem too. Hope the author fix the bugs soonly.

I try to run the extension with MediaWiki 1.27.1 (target and source). Unfortunately, the authentication fails with error "NeedToken". I think there is a problem with the new session infrastructure of version 1.27.x (e.g. cookie handling is broken). Is there a solution?

Also getting this. Did you find a workaround @Feragfh6?

What user does the push into the target wiki? The user that pushes the button or the one setted with $egPushLoginUsers ? I want that the target wiki has the info about each user that pushes pages. Is it possible with this extension?

The error:

Dateitransfer fehlgeschlagen: Authentifizierung auf https://<site>/api.php ist fehlgeschlagen. 

shows up when configured for a 1.24.1 wiki. I know that the MediaWikiApi for 1.24.1 has been changed in an unfortunate incompatible way. Since this extension is from 2011 I am wondering whether

• SSL is the problem
• 1.24.1 is the problem

or something else. How would I debug this situation?

@Jeroen De Dauw

with my new debugging capabilities I found out that status.errors has "SSL certificate problem:unable to get local issuer certificate".

It would be good if such errors would (may be optionally) be propagated to the push-err-authentication message

https://github.com/BITPlan/Push/commit/cf393a32423bd8ae07af50a5587f847f20cfb9b9

has a commit with a few extra lines for error handling. The resulting message is:

Authentication at .../mediawiki/api.php(http-curl-error:SSL certificate problem: unable to get local issuer certificate) failed.

This is a major improvement in handling such situations

I am close to getting things fixed but unfortunately its a little messy.

So the natural attempt to add:

1. ini_set("openssl.cafile","BITPlanValidCerts.pem")
2. ini-set("curl.cainfo","BITPlanValidCerts.pem")

didn't work - you have to set these in the php.ini file. A curl https:// test then works

Mediawiki is different.

see also https://doc.wikimedia.org/mediawiki-core/master/php/HttpFunctions_8php_source.html getCertOptions() and

https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/

so

3. putenv("SSL_CERT_PATH=BITPlanValidCerts.pem");

looked promising - but doesn't seem to work on my PHP 5.6. environment. Even changing the PHP 5.6 version check in HttpFunctions didn't make a difference.

So a bit more debugging and I'll get back here.

https://github.com/BITPlan/Push/commit/3f68dd36a65ff6ad8c68df807c2c32311073dae4

fixes the issue by adding the curl.cainfo php ini setting to the curl options

Hurray!

See also http://stackoverflow.com/questions/34683050/how-can-i-push-a-page-from-one-mediawiki-to-another-ssl-based-wiki-with-self-sig

https://github.com/BITPlan/Push/pull/1 has the pull Request for this fix

Is it possible to use the Push extension through a webproxy? My setup is on an internal server that cannot access the internet directly. However, I can access it through <webproxy address>:80.

Apparently you can specify $wgHTTPProxy for this.