Closed (duplicate)
Project:
Feeds XPath Parser
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
2 Nov 2012 at 15:26 UTC
Updated:
16 Jul 2014 at 14:38 UTC
Jump to comment: Most recent
Comments
Comment #1
derEremit commentedit's an underlying curl problem, but this error also occurs if one specifies an http(not s) link.
Comment #2
mausolos commentedI have a D6 site that I'm migrating from, using views_data_export. I have a D7 site I'm migrating to, using feeds_xpathparser. I cannot find any setting to indicate whether I care if cURL ignores a questionable cert. I cannot find any setting where I can fill in a username and password that are appropriate for accessing the D6 feed.
Here's what I get when I attempt to connect via HTTPS:
HRCurlException: cURL error (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed for https://mydevsite.com/feeds/pages/all in http_request_get() (line 187 of ~/sites/all/modules/contrib/feeds/libraries/http_request.inc).
Here's what I get when I attempt to connect via HTTP:
Download of http://mydevsite.com/feeds/pages/all failed with code 403.
Any ideas what I might do, besides hacking the module? :)
Comment #3
ianthomas_ukThis is a cURL issue, see http://curl.haxx.se/docs/sslcerts.html. If you're on a shared host then you might need to ask your hosting company to see that URL.
This issue could be considered a feature request to add support for options 1 and/or 2 from that page, but really you should be doing option 5. (option 1 turns off the security, option 2 only works for one site, option 5 is the proper fix for all URLs).
I'll leave it to the module maintainer to decide what to do with this issue, but I'd recommend adding some documentation / error handling pointing people to the above URL and close this issue. Adding a checkbox to support option 1 would be dangerous, because people would check it without really understanding the implications.
Comment #4
pkosenko commentedI would say that this is a GENERAL feeds issue. It would be nice if Feeds included an option to ignore the certificate (as cURL) allows, or some way to point to the local copy of the certificate that one is supposed to import (but how?). If you want to hack the Feeds module, in http_request.inc at about line 182. This turns OFF Certificate verification.
// if ($accept_invalid_cert) { // This is always FALSE in Feeds module
curl_setopt($download, CURLOPT_SSL_VERIFYPEER, 0);
// }
Here is a Feeds topic on the issue: https://drupal.org/node/1062178
The topic includes patches.
Of course, we might want to request that the option allows verification to be turned off only for certain sites that we trust, so that it isn't across the board. And I suppose you could include that in your hack -- although not an elegant approach. But it doesn't look to me like Feeds plans to implement this anytime soon.
Comment #5
kurtismccartney commentedWhich file would this solution go into:
// if ($accept_invalid_cert) { // This is always FALSE in Feeds module
curl_setopt($download, CURLOPT_SSL_VERIFYPEER, 0);
// }
I've been getting cURL error 28 on a feed import from two URLs on the same server. Godaddy suggested:
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT ,0);
curl_setopt($ch, CURLOPT_TIMEOUT, 400); //timeout in seconds
set_time_limit(0);// to infinity for example
And I'm unclear on where this goes without crunking up the importers for other feeds that do work..
Comment #6
twistor commented#1062178: Add configuration option to allow invalid/unverified or (self certified) SSL certificates
Feeds XPath Parser doesn't have any say about downloading URLs.