file_get_contents is used on remote URIs in locale.inc

I got the same problem.

I am also getting this. I don't have external module installed (just searched for this error).

Any progress on this?

Had this in 7.18 WITHOUT having Locale enabled.

It appeared only 1 time after updating ckeditor library for WYSIWYG module.

Screenshot of the on-screen error is attached.

I'm gettting the same issues in #6. Don't have local module and my errors are exactly the same. Seems like a misconfiguration on the server. I was able to get around this by adding the following to my settings.php.

ini_set('allow_url_fopen', 1);

You could also override this in a php.ini in the root of your drupal site if your server allows for that:

allow_url_fopen 1

Same here, ini_set('allow_url_fopen', 1); do not solve for me.

I'm not really a system admin so I might be wrong but I think it depends on the server. The allow_url_fopen is a setting in your server's php.ini. Your server needs to be configured to allow that to be updated that or a php.ini file in your site (?).

Same issue with allow_url_fopen enabled on server.
http://web535.kinghost.net/info.php

drupal_http_request seems to be preferred over file_get_contents
http://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_h...

Other issue about applying drupal_http_request() instead of file_get_contents()
http://drupal.org/node/1587598

The attached patch replaces file_get_contents() with drupal_http_request(). drupal_http_request() needs a stream wrapper to function. If there's none, the patch prepends the filepath with the $base_url.

drupal_http_request only allows http, https and proxy. Does anyone know whether using it is still feasable? That is: is there a chance for _locale_parse_js_file() ever getting called with an e.g. public:// filepath?

If no stream wrapper is given, the patch still uses $base_url.

A bit of extra info for people that want to know about why and how to replace file_get_contents() vs drupal_http_request():
http://www.norio.be/blog/2008/06/filegetcontents-vs-drupalhttprequest
For security reasons some servers have 'allow_url_fopen' disabled.

has this patch been committed? i get the same error in 7.22

I'm seeing it too (7.22).

No, it still needs review. If it had been commited the status would be either 'fixed' or 'closed (fixed)'.

@s1l (#18): link broken.
Any news on this issue?
I'm experiencing the problem.

#17 works fine for me with CKeditor 3.6.6.1, Imce 1.7 and Drupal core 7.23

Thanks :)

Thanks for the patch!
#17 works fine for me too with Drupal core 7.23

I was getting this error on 7.26. Applied patch in #17 and it worked for me. I'mg going to mark this as RTBC

where exactly are we supposed to place this string within this code? there are no clear instructions about where we are supposed to place this patch exactly within this .inc file. this file has thousands of lined of code here. sifting through it line by line will take a year. lol. can someone give precise location instructions for someone like me who doesn't understand code?

where exactly are we supposed to place this string within this code? there are no clear instructions about where we are supposed to place this patch exactly within this .inc file. this file has thousands of lined of code here. sifting through it line by line will take a year. lol. can someone give precise location instructions for someone like me who doesn't understand code?

Hi, Raven_MacLean,
you should find in the /includes/locale.inc file, the line 1480 where begin the function :
function _locale_parse_js_file($filepath) {
some line after you should find this line :
$file = file_get_contents($filepath);

then you should comment the line(s) preceded by a"-"
and insert the lines preceded by a "+"

For me, this fix #17 give the following error:
Notice: Undefined property: stdClass::$data in _locale_parse_js_file() (line 1510 of /.../includes/locale.inc).
And it's impossible to add new contents...
(Drupal core 7.26)

17: locale_drupal_http_request-1814980-17.patch queued for re-testing.

Hi,

With your patch, I got the following problem.

Here is a watchdog of the uri I receive:

Array ( [scheme] => public [host] => js [path] => /wysiwyg/wysiwyg_tinymce_C-Q3E8chAs6luQ5sNldsHWIVDRwp8ExKVvwNV6jcy5Y.js )

Unfortunately, the following message appears: "Unsupported js file stream wrapper.", because your patch doesn't handle the case when scheme = 'public', 'private', 'temporary', or any other custom scheme.

Shouldn't it be, something like :

  $uri = @parse_url($filepath);
  if ($uri == FALSE) {
    drupal_set_message(t('Unable to parse js url.'), 'error');
    return;
  }

  if (in_array($uri['scheme'], array('http', 'https', 'proxy'))) {
    // drupal_http_request() supports only these three stream wrappers.
    $streamed_filepath = $filepath;
  }
  else {
    global $base_url;
    $streamed_filepath = $base_url . '/' . $filepath;
  }
  // Prefering drupal_http_request() to file_get_contents().
  // drupal_http_request() needs a fully qualified uri. In the locales_source
  // table, however, we store $filepath.
  $file = drupal_http_request($streamed_filepath)->data;  

The code in comment #33 seems to work for me; I'm attaching it as a patch for testing.

@egfrith could you review your patch, please? It looks as a good solution.

I think trying to translate external files is just wrong and should never be attempted. I have a patch in #2385069: Locale JS alter breaks on remote JS files that prevents that in 8.x, a similar solution should be possible in 7.x as well.

Viewing this Warning in /admin/structure/nivo-slider/options with:

• Drupal version 7.41
• PHP - 5.4.36
• allow_url_fopen = off

i got this problem after updating the module today

Warning: include_once(/var/www/html/clinicadoenriquecer.com.br/web/sites/all/modules/views_isotope/views_isotope.theme.inc) [function.include-once]: failed to open stream: No such file or directory em _theme_process_registry() (linha 565 de /var/www/html/clinicadoenriquecer.com.br/web/includes/theme.inc).
Warning: include_once() [function.include]: Failed opening '/var/www/html/clinicadoenriquecer.com.br/web/sites/all/modules/views_isotope/views_isotope.theme.inc' for inclusion (include_path='.:/usr/share/pear') em _theme_process_registry() (linha 565 de /var/www/html/clinicadoenriquecer.com.br/web/includes/theme.inc).
Warning: include_once(/var/www/html/clinicadoenriquecer.com.br/web/sites/all/modules/views_isotope/views_isotope.theme.inc) [function.include-once]: failed to open stream: No such file or directory em _theme_process_registry() (linha 565 de /var/www/html/clinicadoenriquecer.com.br/web/includes/theme.inc).
Warning: include_once() [function.include]: Failed opening '/var/www/html/clinicadoenriquecer.com.br/web/sites/all/modules/views_isotope/views_isotope.theme.inc' for inclusion (include_path='.:/usr/share/pear') em _theme_process_registry() (linha 565 de /var/www/html/clinicadoenriquecer.com.br/web/includes/theme.inc).
Warning: include_once(/var/www/html/clinicadoenriquecer.com.br/web/sites/all/modules/views_isotope/views_isotope.theme.inc) [function.include-once]: failed to open stream: No such file or directory em _theme_process_registry() (linha 565 de /var/www/html/clinicadoenriquecer.com.br/web/includes/theme.inc).
Warning: include_once() [function.include]: Failed opening '/var/www/html/clinicadoenriquecer.com.br/web/sites/all/modules/views_isotope/views_isotope.theme.inc' for inclusion (include_path='.:/usr/share/pear') em _theme_process_registry() (linha 565 de /var/www/html/clinicadoenriquecer.com.br/web/includes/theme.inc).
Updates were attempted. If you see no failures below, you may proceed happily back to your site. Otherwise, you may need to update your database manually. All errors have been logged.

Hi,

This is a big issue when you are using proxies and your main webserver doesn't have outside access without it.

This bug actually skips the whole drupal HTTP/HTTPS proxy logic.

We got websites stuck loading pages because of it.

I would say this is rather high priority as it could involve indirect private network resources accesses (developer/admin guy adding https://192.168.1.1/reboot-router.asp for fun ?) and coud be considered as a security risk.

We're currently using this patch : https://www.drupal.org/files/locale_drupal_http_request-1814980-17.patch

Avoid warning and notices when scheme is not set

And for the sake of it , a much strip down and to the point version of the patch

I agree with Berdir in #37 - external files shouldn't be fetched by this code at all. Let's mark this as a duplicate of the issue mentioned in that comment (although this one is older, the patch in the other issue looks farther along and has tests, etc).

Also lowering priority - I don't see any security risk here. This only fetches files that were going to be included on the page as JavaScript anyway.

Forgot to lower the priority :)

@David_Rothstein

The security issue is :

Imagine a user has a role in the backend and is able to feed javascript file to add_js trough wathever module.

He can just request resources that wouldn't be touchable otherwise because it bypass the proxy.

I agree it requires some pre-configuration that might not be common to all users, but it's still possible to :

- Either get content from network resources that you shouldn't
- Trigger actions on a network resource that you shouldn't

Even if tiny, this is a risk, people usually use proxies in their app to avoid it using direct connections to external AND internal resources

Regards.