Unable to contact flickr and retrieve the pictures (try to use cURL when drupal_http_request returns a 403, forbidden)

That is most likely the new SSL Required error. You must use version 7.x-1.5 or higher. I don't know from when your 7.x-1.x-dev is. Currently it is identical to 7.x-1.6. Using that version is the best way to go for.

Let me know. Thanks.

Can you send me your API credentials by private message?

Just a sum up of the situation so far:

I used the same setup, configuration and photos as on the working sandbox demo on http://lolandese.altervista.org/?q=node/1#. This confirms the issue being present on the host altervista.org, but not on another host. We get a 403 (displayed as Forbidden) error. Subsequent page loads just omit the photos without displaying the error message, as the page is cached, avoiding to make a Flickr API request on every page load.

Looking into the used core function to make the request drupal_http_request, it uses port 443 for SSL protocols instead of port 80 for HTTP requests. See http://en.wikipedia.org/wiki/HTTP_Secure#Difference_from_HTTP.

The specific request to make to a web host should probably be:

Request to allow outgoing HTTPS requests using port 443 and/or to check if it is set up right.

P.S.: Take this just as a suggestion. I might be wrong.

EDIT: A 403 Forbidden HTTP status code in response to a request indicates the server can be reached and understood the request, but refuses to take any further action.

This indicates the cause is more likely to be that the request is denied by Flickr on AlterVista.org IP addresses. But then again, the test script as found on https://www.flickr.com/services/api/response.php.html does work (using a valid API key). See http://lolandese.altervista.org/?q=node/2. Also all was working fine before the SSL requirement of 27 June when the REST endpoints used where also already set to HTTPS.

The web host AlterVista.org seems to only allow outgoing connections through cURL. See http://forum.it.altervista.org/problemi-tecnici-account/214679-connessio.... It might also be they disallowed some PHP functions that are used by drupal_http_request(), like stream_socket_client.

The solution for now:

• Enable https://www.drupal.org/project/chr.
• At admin/config/services/chr select Override Drupal HTTP Request. Set all HTTP requests to use cURL instead. Requires Drupal 7.21 or higher.
• Clear cache at admin/config/development/performance.
• Visit you nodes with Flickr content to check.
• You might want to read #11 if you still get errors.

We leave this issue active:

• to be found better by others having similar problems with their host
• as a feature request to make this work without depending on the module cURL HTTP Request:
  Try to use cURL when drupal_http_request returns a 403, forbidden.

If this will ever be done has to be seen as a solution is already given. It depends mainly on the number of times others run into this problem on their host. Usually hosts should accept connections made through drupal_http_request(). If not it would invoke problems with all other Drupal modules that use it.

I hope your web host will make that drupal_http_request() can be used. Considering it is a free host with php and mysql support, they offer a surprising good hosting service and apparently also nice support. I am impressed by the clean and easy dashboard. They certainly do their best to offer Drupal as one of the working CMS solutions, which helps to make Drupal known among the large public.

Awesome.

"As its developer has suggested, to solve this I've changed in the file chr.module."
Good additional info.

Thanks again for reporting.

I have the same problem, but since I am using Drupal 6.31 the cURL workaround doesn't work for me.

Any suggestions how I could fix this? Thanks!

• Download end enable the D6-1.5 version of https://www.drupal.org/project/chr
• In sites/all/modules/flickr folder modify the file flickr.inc. Change the line that says:
• $result = drupal_http_request($url);
• to
• $result = curl_http_request($url);
• Clear cache at admin/settings/performance.
• If you have some initial errors, follow the instruction of #11. Probably you see:
  Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION cannot be activated when safe_mode is enabled or an open_basedir is set in _chr_curl_set_defaults() (line 336 of /sites/all/modules/chr/chr.module).
• Check your posts with Flickr photos.
• Let us know if this works for D6. Thanks.

Thank you for your fast help @lolandese.

I have set up the chr module as described, but now I see this error message and I still don't see my Flickr photos:
Missing argument 2 for variable_get(), called in /home/www/website/modules/chr/chr.module on line 78 and defined - /home/www/website/includes/bootstrap.inc - 587. line.

Missing argument 2 for variable_get(), called in /home/www/website/modules/chr/chr.module on line 79 and defined - /home/www/website/includes/bootstrap.inc - 587. line.

I have managed to get rid of the CURLOPT_FOLLOWLOCATION warning by setting this line:
CURLOPT_FOLLOWLOCATION => TRUE,

to this:
CURLOPT_FOLLOWLOCATION => FALSE,

That does seem to be an error related to the other module.

Have you tried leaving all as it was and change the url for Flickr to Https in the flickr.inc file
change
define('FLICKR_REST_ENDPOINT', 'http://api.flickr.com/services/rest/');
to
define('FLICKR_REST_ENDPOINT', 'https://api.flickr.com/services/rest/');

the api now requires comms over SSl. This change worked for me rather than the chr module which errored out on the http Proxy info.

Thanks
B

Changing "http" to "https" worked perfectly. Thanks Fogybear.

@fogybear's solution worked for me as well. Thanks!

This also fixes the same issue for the D6 module.

Eric

We can close this because:

• the issue is an uncommon hosting server issue that can be solved following the instructions in #8
• the committed patch in #2361813: Warning: getimagesize offers to use cURL as an alternative on the settings page, that is for the function getimagesize().

Reopen if you have problems that can not be solved by neither of the solutions mentioned above and you suspect could be solved by using cURL.

Changed my mind. The attached patch makes that we don't have dependencies by integrating part of the chr module code. I was hesitating as it consists of approximately 500 lines of code. On the other hand the users of free hosting companies like Altervista are target users of the Flickr module. The module enhances the performance on especially these kind of servers, using the fast server of Flickr for the images and videos instead.

For convenience a zip file is added that provides a patched version of the latest dev and will work on Altervista without dependencies.

Attached patch additionally:

• adds an 'Advanced settings' section in the config page
• makes all settings field groups collapsible (otherwise it grew too big)
• wraps used links in the l() function as per code standards.

The new 'Advanced section' holds the checkboxes to optionally disable the module's CSS and to force use cURL to avoid fopen for 'getimagesize'.

TODO:

• Add a checkbox 'Enable Debug Output' (Display used Flickr photo and album arguments via Devel).
• Add a checkbox 'Use 'cURL' instead of 'stream_socket_client (drupal_http_request)' (Otherwise cURL will be only used as fallback when the usual method returns a 403 (forbidden)).
• Trim the function flickr_curl_http_request().

Furthermore we now only use cURL on a 403 (forbidden). We wonder if it would be useful also for other responses, like a 408 (Request Timeout). Feel free to fill us in on this one.

Thanks.

Attached patch additionally:

• Adds a checkbox 'Enable Debug Output' (Display used Flickr photo and album arguments via Devel).
• Adds a checkbox 'Use 'cURL' instead of 'stream_socket_client (drupal_http_request)' (Otherwise cURL will be only used as fallback when the usual method returns a 403 (forbidden) or 408 (Request Timeout)).
• Uses cURL also for a 408 (Request Timeout).

Attached patch additionally rearranges the configuration screen. More neat.

Now the Flickr module can be used out-of-the-box on hosts that only allow outgoing connections over cURL, e.g. the free hoster Altervista.org. Without any dependencies. We were keen to do this, because it is on this kind of hosts you get most advantage of using a third party image provider (performance wise).

Furthermore the configuration screen has been organized in collapsed fieldsets and an Error Control Operator has been added before the function imagecreatefromstring() to suppress a rare but possible recoverable error message (only in the commit, not in the last patch).

Hey guy install php curl and restart server, php restart ready!!