Jó estét DruPál-osok!
Bemásolom a hibaüzenet elejét.
De valaki csak tudja miért van ez.
Valami elérési út probléma ez.
A fájlrendszerben az ideiglenes fájlok könyvtára /home/httpd/www/horgaszcsonak.com/html/csaliking/tmp
nyilvános fájlok útvonala sites/default/files
Drupal 7.36 Commerce Kickstart (commerce_kickstart-7.x-2.22+9-dev)
Warning: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 _locale_parse_js_file() függvényben (/home/httpd/www/horgaszcsonak.com/html/csaliking/includes/locale.inc 1488 sor).
Warning: file_get_contents(http://www.csaliking.hu/misc/ui/jquery.ui.core.min.js): failed to open stream: no suitable wrapper could be found _locale_parse_js_file() függvényben (/home/httpd/www/horgaszcsonak.com/html/csaliking/includes/locale.inc 1488 sor).
"http:// wrapper is disabled
"http:// wrapper is disabled in the server configuration by allow_url_fopen=0"
itt a hiba, beszélj a szolgáltatóval.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
jQuery Update frissítés
Szervusz István!
A jQuery Update modult ha bekapcsolom ott be lehet állítani, hogy ne a tárhelyszolgáltató által tiltott nem biztonságos módon akarjon frissíteni. A beállítások amikkel nincs hibaüzenet:
Version options
Alapértelmezett jQuery verzió 1.10
Alternate jQuery version for administrative pages Default Drupal
jQuery és jQuery UI CDN : jQuery
Sajnos korán örültem:
Warning: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 _locale_parse_js_file() függvényben (/home/httpd/www/horgaszcsonak.com/html/csaliking/includes/locale.inc 1488 sor).
Warning: file_get_contents(http://www.googletagservices.com/tag/js/gpt.js): failed to open stream: no suitable wrapper could be found _locale_parse_js_file() függvényben (/home/httpd/www/horgaszcsonak.com/html/csaliking/includes/locale.inc 1488 sor).
Az alapértelmezett verziót is drupal alapra állítottam most megint jó.
Aztán megint nem jó.
Kész vagyok. A baj az, hogy a frissítést úgy akarja leszedni amit a szerver védelme érdekében nem enged meg a szolgáltató.
tamoca
Kedves István, válaszolt a szolgáltató, megnéznéd?wrapper...
idézem az alábbiakban.
Szia!
Warning: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 _locale_parse_js_file() függvényben (/home/httpd/www/horgaszcsonak.com/html/csaliking/includes/locale.inc 1488 sor).
Warning: file_get_contents(http://www.csaliking.hu/misc/ui/jquery.ui.core.min.js): failed to open stream: no suitable wrapper could be found _locale_parse_js_file() függvényben (/home/httpd/www/horgaszcsonak.com/html/csaliking/includes/locale.inc 1488 sor).
Ez a hibaüzenet azért van , mert a
/includes/locale.inc 1488 sorában a következő utasítás található:
$file = file_get_contents($filepath);
Ha a $filepath változóban egy url van akkor külső idegen szerverről próbál meg kódot letölteni a file_get_contents függvénnyel ami a mi szervereinken, és sok más szolgálatónál tiltva van biztonsági okból.
Természetesen igény esetén tudjuk engedélyezni ezt a funkciót, mert csak annak az egy tárhelynek a biztonságát érinti ez, a többi szerveren található tárhely biztonságára nincs hatással.
Annak kellene utána nézni még , hogy miért akarja annak ellenére, hogy az adminban beállítod hogy ne onnan töltse le mégis valamiért http:-keresztül elérni a fájt.
Ez vagy az admin felület program hibája, esetleg valami cache-elési hiba szerintem.
Ha mindenképpen idegen szerverről alkar kódot letölteni akkor a php curl() függvényét kellene használni, ezt szinte sehol nem tiltják, mert nem jelent akkora biztonsági kockázatot az oldalra nézve.
Itt egy curl-os minta példa a következő oldalról:
http://snipplr.com/view/4084
function file_get_contents_curl($url) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); //Set curl to return the data instead of printing it to the browser.
curl_setopt($ch, CURLOPT_URL, $url);
$data = curl_exec($ch);
curl_close($ch);
return $data;
}
Jancsi
tamoca
nincs itt semmi hiba
úgy állítottad be a jquery update modult, hogy CDN -ről töltse be a jqueryt. ez teljesen jó így, csak a szolgáltatód tiltja urlek megnyitását file_get_contents fgvel. erre a megoldás az, hogy megkéred, hogy ne tiltsa.
-
clear: both;
Tegyünk tisztába pár dolgot.
Tegyünk tisztába pár dolgot.
Miért van hiba.
A hiba abból adódik, hogy a _locale_parse_js_file() függvény megpróbálja kiszedni a js-ből a Drupal.t() és Drupal.formatPlural() hívásokat, hogy betegye a fordítható szövegek közé. Mivel a szerveren ki van kapcsolva az allow_url_fopen, ezért ez hibát dob. Ha helyi fájlokról lenne szó, és http:// kereszül éri el a fájlt, akkor is dobna hibát, mert a stream amit megpróbál megnyitni, nem helyi.
Szóval bármit is állítasz be a hiba jelentkezni fog. (lásd korábban a ga.js-re dobott hibát)
A biztonságról.
Régen, tényleg régen, de nagyon régen, volt egy potenciális sebezhetőség a php-ban, hogy ha valaki mindenféle vizsgálat nélkül include()-olt egy fájlt, akkor távolról lehetett mindenféle kódot futtatni a szerveren.
A lényeg, hogy ehhez kellett olyan gáz kód, ami include-olt mindenféle ismeretlen forrásból jövő adatot.
Régen, tényleg régen, a PHP nem tett különbséget sima fájlműveletek és az include között, ezért ezt a sebezhetőséget csak úgy lehetett védeni, hogy mindent tiltottak.
Ma már (2006 november 2. óta, szóval rég óta, de tényleg rég óta: http://php.net/ChangeLog-5.php#5.2.0) van még egy kapcsoló a allow_url_include ami lehetővé teszi, hogy bekapcsolt allow_url_fopen mellett a fenti sebezhetőséget kivédd. (ez az alapbeállítás is http://php.net/manual/en/filesystem.configuration.php)
Szóval azon a sok szerveren, ahol ezt tiltják nem hallottak még erről a "vadi új" dologról.
A "CURL-meg biztonságos" rész egy vicc ugye. Mert ha ez igaz lenne, akkor ha fogod magad és csinálsz egy stream_wrappert ami a CURL-t használja és a http helyet beregisztrálod azt, a STREAM_IS_URL flag nélkül(teszteltem megy. :) ), akkor az biztonságos kéne, hogy legyen, holott pont a régi (fent említett) sebezhetőséget tudod visszahozni vele.
Szóval én visszaállítanám a szolgáltatód helyében az alapbeállítást, és nem fárasztanám magamat és az ügyfeleimet ezekkel a felesleges körökkel.
pp
allow_url_fopen 2000 december 19.-én került bele a PHP-ba, 15 éve
allow_url_include 2006 november 2.-án került bele a PHP-ba, 9 éve
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Üzemeltetőként (bár nem a
Üzemeltetőként (bár nem a fent említett szolgáltató üzemeltetőjeként) hadd szóljak bele ebbe a témába egy kissé.
Az, amit pp írt, az lényegében igaz, attól eltekintve, hogy a szolgáltatók miért nem tekintik biztonságosnak még mindig az allow_url_fopen beállítást.
Bár a pp által említett sebezhetőség valóban javításra került a PHP-ban, az allow_url_fopen-nek van még egy vetülete, amivel a PHP fejlesztők (jó esetben) nem, vagy ritkán szembesülnek, ez pedig a mindenféle script kiddie-k által írkált támadó kódok. Ezeket a kódokat jellemzően nem képzett PHP fejlesztők írják, vagy nem mernek támaszkodni a PHP-ban egyébként kikapcsolható cURL funkcionalitásra, és az allow_url_fopen beállítást engedélyezettnek véve töltik le a privilégiumszint-emelésre szolgáló, jellemzően Perl-ben vagy C-ben írt kódjaikat. Az üzemeltetők egy része ezért tiltja az allow_url_fopen globális PHP beállítást, hogy ezeket a támadó kódokat ellehetetlenítse, mert komolyabb biztonsági rendszerek híján (melyek bevezetése pénzbe és/vagy időbe kerül), mint pl. a CloudLinux vagy a ModSecurity, ez a legolcsóbb és legkézenfekvőbb megoldás a probléma megoldására. Ha nyilván van tartva, hogy kinél van engedélyezve ez a beállítás, akkor egy esetleges támadás esetén jelentősen leszűkíthető azon oldalak köre, amely irányból a támadás érkezhetett, adott esetben egy-két oldalra.
Szóval, én nem feltétlen ítélném el a szolgáltatót, csak azért, mert tiltja az allow_url_fopen használatát.
Amit jelen esetben tenni tudsz, az egyfelől valóban az, hogy a szolgáltatóval egyeztetve engedélyezteted az allow_url_fopen használatát, másfelől pedig egyeztetni kellene a modul írójával, hogy talán rugalmasabb is lehetne a dolog, ha a modul képes lenne cURL segítségével is betölteni az erőforrásokat ha és amennyiben a normál file_get_contents esetleg sikertelenül futna le.
--
()=() Ki oda vagyik, ('Y') hol szall a galamb C . C elszalasztja a ()_() kincset itt alant.Tudsz írni egy konkrét példát
Tudsz írni egy konkrét példát? Mert ebből én nem látom, hogy miért megoldás az allow_url_fopen tiltása.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu