Looks like switching the API URL to secure causes Flickr to return secure URLs for the images, which then breaks our proxy downloading. (The Wikimedia proxy server currently can't handle HTTPS requests.)

Fixed in https://gerrit.wikimedia.org/r/#/c/35339/.

Issue with proxy server should be filed as a separate bug.

sumanah wrote:

Can this fix be backported so that I can test the Flickr upload on test & test2, and see whether the proxy server issue is still reproducible?

Change https://gerrit.wikimedia.org/r/#/c/35339/ from comment #2 has been reverted because it got merged but has not been deployed. The revert is https://gerrit.wikimedia.org/r/#/c/35359/

Reopening bug.

sumanah wrote:

Error is still reproducible on test2, which is predictable because the fix needs to be backported to the branch that's deployed right now (1.21wmf5).

sumanah wrote:

Ryan, can you re-deploy your fix? This is a blocker for tomorrow's 1.21wmf5 deployment to Commons. Thanks!

(In reply to comment #6)

Ryan, can you re-deploy your fix? This is a blocker for tomorrow's 1.21wmf5
deployment to Commons. Thanks!

Not really, the feature isn't enabled on Commons

'wgAllowCopyUploads' => array(
'default' => false,
'testwiki' => true,
'test2wiki' => true,
'commonswiki' => true, disabled until flickr interface is ready --kaldari
),

sumanah wrote:

Sorry for misunderstanding. Removing deployment blocker bug.

Fixed, deployed, and verified on test.wiki.

On my local wiki I still get the same error on the master branch. My config file has
'flickrApiUrl' => 'http://api.flickr.com/services/rest/?',

Not sure if this should open this bug, please test.

sumanah wrote:

Still happening on test.wikipedia.org. Marking as blocking deployment (to Commons) since https://gerrit.wikimedia.org/r/#/c/37353/1/wmf-config/InitialiseSettings.php has been merged and thus this feature would go live to Commons on Wednesday.

I cannot reproduce this bug using the steps from comment #1. Are you still seeing it using those exact steps?

Looks like this error is caused by the 'HTTPS everywhere' Firefox add-on. There are two ways this could be fixed:

1. Add HTTPS support to the WMF proxy server that pulls the images from Flickr
2. Change UploadWizard to use Flickr's secure API and add a hack to UploadWizard that rewrites all the secure image URLs returned from the API into non-secure URLs.

How hard would it be to do 1?
Doesn't the proxy accept connect? curl should be able to make a tls request on its own.

In the meantime, we should at least detect for the 'http-curl-error' and return a better error message. Something like "Error: Could not retrieve file from remote host. You may need to turn off the HTTPS Everywhere browser extension."

I'm using Firefox with HE on fedora 17. Sometimes a file out of a dozen fails and I've encountered a couple other bugs, but no http-curl-error anywhere.

Removing HE from summary: it never happened to me when using FF lately, but it happened just now with a "clean" Chromium.

Able to reproduce today. Some debugging info I could gather from mw.IframeTransport :

The response of the Api request made by the Iframe is

error: Object-?
0: "Operation timed out after 25007 milliseconds with 431627 out of 1937071 bytes received"
code: "http-curl-error"
info: "Error fetching file from remote source"

Apparently ui.showError doesn't identify this code and outputs the default message it should.

I tried to upload directly by using the Upload Api and got the same error but in more detail.

{"error":{"code":"http-curl-error","info":"Error fetching file from remote source","0":"SSL certificate problem, verify that the CA cert is OK. Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"}}

Shouldn't this be moved to core?

(In reply to comment #19)

{"error":{"code":"http-curl-error","info":"Error fetching file from remote
source","0":"SSL certificate problem, verify that the CA cert is OK.
Details:\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed"}}

Argh, is this bug 42441 striking again? Is $sslVerifyHost overridden somewhere else or what?
Last time I got this error, I wasn't even on https...

(In reply to comment #20)

Argh, is this bug 42441 striking again? Is $sslVerifyHost overridden
somewhere
else or what?
Last time I got this error, I wasn't even on https...

I don't think so, the problem is that curl is failing to verify the host.
Maybe UW uses https flickr links to upload via the Upload Api, thus you are not on https but still see the error.

Also we should show better error messages, currently we are showing the error code but we should show the info associated with it.
We might also want to catch errors from bad internet connectivity.I found two more possible errors (see below) with same code, here displaying the info on UW would be more helpful.

{"error":{"code":"http-curl-error","info":"Error fetching file from remote source","0":"couldn't connect to host"}}

{"error":{"code":"http-curl-error","info":"Error fetching file from remote source","0":"Could not resolve host: secure.flickr.com; Host not found"}}

I have made a change for the error message https://gerrit.wikimedia.org/r/#/c/47868/

(In reply to comment #21)

I don't think so, the problem is that curl is failing to verify the host.
Maybe UW uses https flickr links to upload via the Upload Api, thus you are
not
on https but still see the error.

Ahem, my bad: I probably pasted an https flickr URL in UW, as I copied it from Firefox.

Note to self: see if this got magically fixed or not. May need some ops love if not.

I didn't capture any specific error messages, but this seems to still fail. See https://commons.wikimedia.org/wiki/File:Stormy_sky,_Danarau_Marina,_Fiji for my attempt that did get meta data from flickr but no image.

So apparently my file did get uploaded: https://commons.wikimedia.org/wiki/File:Stormy_sky,_Danarau_Marina,_Fiji.jpg. Commons has both meta data and image content. This upload was done with the toolslab.org tool and not upload wizard however.

I tried to follow Sumana's original issue instructions and can't even get as far as she did. The initial javascript ajax call to https://api.flickr.com/services/rest/ seems to timeout in my browser. If I manually visit the api.flickr url it redirects to secure.flickr and returns a seemingly valid json blob.

• Bug 54468 has been marked as a duplicate of this bug. ***

I was able to import https://secure.flickr.com/photos/fabola/9743350532/ as https://test.wikipedia.org/wiki/File:Fabola-9743350532.jpg with no issues using Chrome 30.0.1599.69 on OS X. I did however need to switch to a profile that does not have the HTTPS Everywhere extension installed.

With HTTPS Everywhere installed/enabled I get an error in the local browser when an XHR request is made for https://api.flickr.com/services/rest/?&nojsoncallback=1&method=flickr.photos.licenses.getInfo&api_key=e9d8174a79c782745289969a45d350e8&format=json. This error seems to stop the entire Upload Wizard process.

I was also able to import multiple files to test2 using https://secure.flickr.com source URLs as long as HTTPS Everywere is not running. I'm going to reopen the bug more specifically about that issue and close this one.

The SSL root certificates currently used in the cluster are fine with Flickr's certificate.