Right after enabling this module I started getting:

Warning: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 in _locale_parse_js_file() (line 1488 in includes/locale.inc

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Redcatalyst’s picture

I got the same problem.

stellarvisions’s picture

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

int_ua’s picture

It's definitely not the extlink problem, I've removed it long ago. But I'm not sure who to blame now.

int_ua’s picture

Project: External Links » Drupal core
Version: 7.x-1.12 » 7.16
Component: Code » locale.module
fuse’s picture

Any progress on this?

silkogelman’s picture

Version: 7.16 » 7.18
FileSize
55.06 KB

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.

jnettik’s picture

Status: Active » Needs review

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

sistematico’s picture

Version: 7.18 » 7.19
Assigned: Unassigned » sistematico

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

jnettik’s picture

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 (?).

sistematico’s picture

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

silkogelman’s picture

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

czigor’s picture

Assigned: sistematico » Unassigned
FileSize
702 bytes

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.

Status: Needs review » Needs work

The last submitted patch, locale_drupal_http_request-1814980-12.patch, failed testing.

czigor’s picture

Status: Needs work » Needs review
FileSize
1.32 KB

Status: Needs review » Needs work

The last submitted patch, locale_drupal_http_request-1814980-14.patch, failed testing.

czigor’s picture

Status: Needs work » Needs review
FileSize
877 bytes
czigor’s picture

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.

silkogelman’s picture

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.

candelas’s picture

Version: 7.19 » 7.22

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

Spark_man’s picture

I'm seeing it too (7.22).

czigor’s picture

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

Balbo’s picture

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

Bizio’s picture

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

Thanks :)

eFeS’s picture

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

czigor’s picture

Version: 7.22 » 7.x-dev
Issue summary: View changes
jnettik’s picture

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

jnettik’s picture

Status: Needs review » Reviewed & tested by the community
Raven_MacLean’s picture

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?

stefnes’s picture

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 "+"

Chrigou’s picture

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)

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 17: locale_drupal_http_request-1814980-17.patch, failed testing.

czigor’s picture

Status: Needs work » Needs review
lahode’s picture

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;  
egfrith’s picture

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

Status: Needs review » Needs work

The last submitted patch, 34: locale_drupal_http_request-1814980-34.patch, failed testing.

candelas’s picture

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

Berdir’s picture

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.

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 34: locale_drupal_http_request-1814980-34.patch, failed testing.

Balbo’s picture

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

  • Drupal version 7.41
  • PHP - 5.4.36
  • allow_url_fopen = off
Alan Oliveira’s picture

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.

gboddin’s picture

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.

gboddin’s picture

Priority: Normal » Major
gboddin’s picture

gboddin’s picture

Avoid warning and notices when scheme is not set

gboddin’s picture

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

gboddin’s picture

Title: Warning: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 » file_get_contents is used on remote URIs in locale.inc
David_Rothstein’s picture

Status: Needs work » Closed (duplicate)
Related issues: +#2385069: Locale JS alter breaks on remote JS files

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.

David_Rothstein’s picture

Priority: Major » Normal

Forgot to lower the priority :)

gboddin’s picture

@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.