Ü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.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
.htaccess és adatbázis előtagok
Egy csomó beállítás átmozgatható az index.php-be ini_set használatával, de sajnos nem minden (a .htaccessből). Ami az adatbázist illeti, a Drupal meg tudja osztani az adatbázisát más programokkal, beállíthatsz tábla előtagokat.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
regisztracio utani tajekoztato uzenet
Az új jelszó és a további teendők leírása nemsokára megérkezik emailben.
ebbol nem derul ki, hogy hova?
helyesen
Az új jelszót és a további teendőket elküldtük az e-mail címedre.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nekem nem a default kellene!
Az az én bajom, hogy a default oldalt adja be, az angol bongészőnek is.
Láttam már olyan drupalt, ami angol böngészőre, angol címlapot adott ..
Nekem is arra lenne szügségem.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Hát igen
Átolvastam az oldalt, és az lenne a kérdésem, hogy amit ő patch-ként mutat az kéne a megfelelő helyre beilleszteni? Vagy mit kell csinálni vele? Mert még nem találkoztam ilyennel!
Előre is köszön a segítséget!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
beállítási hiba
A Drupal általhasznált ideiglenes könyvtárat a webhely beállításoknál egy az open_basedir-en belüli könyvtárra kell állítani. Mivel /tmp/ benne van az open_basedir-ben, az is elég lehet, ha a /tmp helyett /tmp/ a beállítás.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
db_rewrite_sql()
db_rewrite_sql():
Lehet, hogy a hiányos angol tudásom az oka (vagy az SQL tudásom), de nem jöttem rá az APIból, hogy mire van v. miért használják a blog_block()-ban :$
Lippai Ádám
young element
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Drupal ebben nemt túl erős
Ebben az alap Drupal nem túl erős, hisz az összes fájlt egy könyvtárba nyomja be az upload modul.
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Legjobb tudásom szerint lesz,
Legjobb tudásom szerint lesz, ugyan is ez az egyik feltétele az Ipszilon előadásnak. Ha még sem lenne akkor az késöbb ismétlésre kerül kamerák elött.
Sőt ügye ez élőben is közvetítve van.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nem lett jobb...
Kipróbáltam a javaslatodat, sajnos nem lett jobb!
Végül is így, hogy már 30 találat jelenik meg, nagyjából elégedett vagyok. A tapasztalat szerint ettől többre úgy se kíváncsi senki, hamarabb elnavigál, vagy másik szóra keres rá, mert nincs türelme ennél több találaton végig rágni magát.
Ami az Artisteer-t illeti, nyilván igazatok van! De kellő programozói tudás nélkül nem tudok másképp egyedi kinézetet létrehozni, pl. belenyúlni egy hivatalosan kiadott sminkbe úgy, hogy megváltoztassam a hátterét, vagy a fejléc színét, az oldal szélességét, stb.
Eddig még mindig úgy jártam, hogy akárhány "gyári" sminket ajánlottam a megrendelőnek, mindig fitymálta, neki más, egyedibb kell, ezért maradtam jobb híján az Artisteer-nél, mert ott kedvemre állíthatom össze a smink kinézetét. Az más kérdés, hogy programozói szemmel nézve "ilyen ocsmány kódot összehozni már külön művészet".
Egyébként az az érdekes, hogy már a többtucadik Artisteer-es sminkkel működő honlapot adtam ki a kezemből, de a többinél ilyen problémával nem találkoztam (mással se nagyon). Valószínűleg csak ennek az egy konkrét smink példánynak van valami olyan baja, ami miatt összeakad ennél a konkrét környezetnél valamivel, mondjuk az egyik modullal. De kideríteni a konkrét okot talán hosszabb, mint csinálni egy új sminket, sajnos jobb híján megint az Artisteer-rel...
Most megpróbálom meggyőzni a megrendelőt, hogy változtatni kell egy kicsit a kinézeten, mondjuk marketinges, vagy egyéb szempontok miatt, és így alkalmam lesz a sminket lecserélni. A következő talán nem fog ilyen hibát (no meg másfélét se) produkálni, ahogy a korábbiak sem, csak pont ez az egy!
Közben megjelent az Artisteer új verziója, a 4-es. Még nem volt hozzá szerencsém, de remélhetőleg az már drupalbarátabb lesz!
Köszönöm még egyszer mindenkinek a javaslatait és segítőszándékát!
Veres László