Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#46 | patch-locale-for-remote-loading.patch | 640 bytes | gboddin |
#45 | locale_drupal_http_request-warning-fix.patch | 1.13 KB | gboddin |
#34 | locale_drupal_http_request-1814980-34.patch | 1.1 KB | egfrith |
#17 | locale_drupal_http_request-1814980-17.patch | 1.23 KB | czigor |
#16 | locale_drupal_http_request-1814980-16.patch | 877 bytes | czigor |
Comments
Comment #1
Redcatalyst CreditAttribution: Redcatalyst commentedI got the same problem.
Comment #2
stellarvisions CreditAttribution: stellarvisions commentedI am also getting this. I don't have external module installed (just searched for this error).
Comment #3
int_ua CreditAttribution: int_ua commentedIt's definitely not the extlink problem, I've removed it long ago. But I'm not sure who to blame now.
Comment #4
int_ua CreditAttribution: int_ua commentedComment #5
fuse CreditAttribution: fuse commentedAny progress on this?
Comment #6
silkogelman CreditAttribution: silkogelman commentedHad 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.
Comment #7
jnettikI'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
Comment #8
sistematico CreditAttribution: sistematico commentedSame here, ini_set('allow_url_fopen', 1); do not solve for me.
Comment #9
jnettikI'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 (?).
Comment #10
sistematico CreditAttribution: sistematico commentedSame issue with allow_url_fopen enabled on server.
http://web535.kinghost.net/info.php
Comment #11
silkogelman CreditAttribution: silkogelman commenteddrupal_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
Comment #12
czigor CreditAttribution: czigor commentedThe 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.
Comment #14
czigor CreditAttribution: czigor commentedComment #16
czigor CreditAttribution: czigor commentedComment #17
czigor CreditAttribution: czigor commenteddrupal_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.
Comment #18
silkogelman CreditAttribution: silkogelman commentedA 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.
Comment #19
candelas CreditAttribution: candelas commentedhas this patch been committed? i get the same error in 7.22
Comment #20
Spark_man CreditAttribution: Spark_man commentedI'm seeing it too (7.22).
Comment #21
czigor CreditAttribution: czigor commentedNo, it still needs review. If it had been commited the status would be either 'fixed' or 'closed (fixed)'.
Comment #22
Balbo CreditAttribution: Balbo commented@s1l (#18): link broken.
Any news on this issue?
I'm experiencing the problem.
Comment #23
Bizio CreditAttribution: Bizio commented#17 works fine for me with CKeditor 3.6.6.1, Imce 1.7 and Drupal core 7.23
Thanks :)
Comment #24
eFeS CreditAttribution: eFeS commentedThanks for the patch!
#17 works fine for me too with Drupal core 7.23
Comment #25
czigor CreditAttribution: czigor commentedComment #26
jnettikI was getting this error on 7.26. Applied patch in #17 and it worked for me. I'mg going to mark this as RTBC
Comment #27
jnettikComment #28
Raven_MacLean CreditAttribution: Raven_MacLean commentedwhere 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?
Comment #29
stefnes CreditAttribution: stefnes commentedHi, 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 "+"
Comment #30
Chrigou CreditAttribution: Chrigou commentedFor 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)
Comment #32
czigor CreditAttribution: czigor commented17: locale_drupal_http_request-1814980-17.patch queued for re-testing.
Comment #33
lahode CreditAttribution: lahode commentedHi,
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 :
Comment #34
egfrith CreditAttribution: egfrith commentedThe code in comment #33 seems to work for me; I'm attaching it as a patch for testing.
Comment #36
candelas CreditAttribution: candelas commented@egfrith could you review your patch, please? It looks as a good solution.
Comment #37
BerdirI 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.
Comment #40
Balbo CreditAttribution: Balbo as a volunteer commentedViewing this Warning in /admin/structure/nivo-slider/options with:
Comment #41
Alan Oliveira CreditAttribution: Alan Oliveira commentedi 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.
Comment #42
gboddin CreditAttribution: gboddin at European Commission and European Union Institutions, Agencies and Bodies commentedHi,
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.
Comment #43
gboddin CreditAttribution: gboddin at European Commission and European Union Institutions, Agencies and Bodies commentedComment #44
gboddin CreditAttribution: gboddin at European Commission and European Union Institutions, Agencies and Bodies commentedWe're currently using this patch : https://www.drupal.org/files/locale_drupal_http_request-1814980-17.patch
Comment #45
gboddin CreditAttribution: gboddin at European Commission and European Union Institutions, Agencies and Bodies commentedAvoid warning and notices when scheme is not set
Comment #46
gboddin CreditAttribution: gboddin at European Commission and European Union Institutions, Agencies and Bodies commentedAnd for the sake of it , a much strip down and to the point version of the patch
Comment #47
gboddin CreditAttribution: gboddin at European Commission and European Union Institutions, Agencies and Bodies commentedComment #48
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI 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.
Comment #49
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedForgot to lower the priority :)
Comment #50
gboddin CreditAttribution: gboddin at European Commission and European Union Institutions, Agencies and Bodies commented@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.