Archívum - 2007
október 21
Apache Wicket Web Application Framework
MVC mintát megvalósító keretrendszer Java környezetben
■ File jogosultság problémák, biztonság
A következő a problémám:
szeretném elérni, hogy a tárhelyemen az adatbázis jelszavakat tartalmazó php file ne legyen böngészéssel elérhető. Ha pl. .inc kiterjesztésű lenne, akkor bárki aki véletlenül rátalál azonnal leolvashatná a MySQL hozzáférési adatokat.
Bizonyos ingyenes szolgáltatóknál tökéletesen működött, hogy a file jogosultságokat átállítottam, csak az owner -nek legyen read és execute joga, de ez az extra.hu-nál és a jelenlegi fizetős szolgáltatómnál nem működik! Végigpróbáltam szinte minden kombinációt, vagy a futó php alkalmazásom sem tudja végrehajtani és böngészőből sem végrehajtható a script (forbidden), vagy mindkét módon megnyitható. Azt szeretném elérni, hogy csak a szerveren futó script részeként lehessen futtatni a scriptet (include). Próbálkoztam FTP klienssel (Total Commander, Win alatt) és php Chmod-al (0 prefixel) egyaránt, sehogy sem működött a dolog.
Lenne még egy kérdésem: van arra mód, hogy rosszándékú valaki belenézzen egy eképpen számára elérhető php scriptbe, tehát ahelyett, hogy lefutna, megtekintse a tartalmát, vagy esetleg valahogyan hozzáférjen a tartalom részeihez, vagy pl a változók értékeihez? Azért kérdezem ezt mert olvastam, hogy pl. a MySQl jelszavakat biztonságosabb egy külön fileban, csökkentett file-jogosultságokkal tárolni. Ezek szerint publikus pl. index.php-nkból van mód változók adatainak kifejtésére?
■ szeretném elérni, hogy a tárhelyemen az adatbázis jelszavakat tartalmazó php file ne legyen böngészéssel elérhető. Ha pl. .inc kiterjesztésű lenne, akkor bárki aki véletlenül rátalál azonnal leolvashatná a MySQL hozzáférési adatokat.
Bizonyos ingyenes szolgáltatóknál tökéletesen működött, hogy a file jogosultságokat átállítottam, csak az owner -nek legyen read és execute joga, de ez az extra.hu-nál és a jelenlegi fizetős szolgáltatómnál nem működik! Végigpróbáltam szinte minden kombinációt, vagy a futó php alkalmazásom sem tudja végrehajtani és böngészőből sem végrehajtható a script (forbidden), vagy mindkét módon megnyitható. Azt szeretném elérni, hogy csak a szerveren futó script részeként lehessen futtatni a scriptet (include). Próbálkoztam FTP klienssel (Total Commander, Win alatt) és php Chmod-al (0 prefixel) egyaránt, sehogy sem működött a dolog.
Lenne még egy kérdésem: van arra mód, hogy rosszándékú valaki belenézzen egy eképpen számára elérhető php scriptbe, tehát ahelyett, hogy lefutna, megtekintse a tartalmát, vagy esetleg valahogyan hozzáférjen a tartalom részeihez, vagy pl a változók értékeihez? Azért kérdezem ezt mert olvastam, hogy pl. a MySQl jelszavakat biztonságosabb egy külön fileban, csökkentett file-jogosultságokkal tárolni. Ezek szerint publikus pl. index.php-nkból van mód változók adatainak kifejtésére?
október 20
kép betöltése div-be
Sziasztok!
Most kezdek ismerkedni a js-el programozás szinten. Csak van valami amivel elakadtam. Ez a kép belöltése egy divbe onclick() eseményre. Jquery-t használok. Ha valaki ki tudna segíteni ebből a problémából annak nagyon örülnék!
Előre is köszönöm!
T.
■ Most kezdek ismerkedni a js-el programozás szinten. Csak van valami amivel elakadtam. Ez a kép belöltése egy divbe onclick() eseményre. Jquery-t használok. Ha valaki ki tudna segíteni ebből a problémából annak nagyon örülnék!
Előre is köszönöm!
T.
Symfony - utf8 probéma
A Symfony-ban az alábbi problémába ütköztem: Mindenhol UTF-8-at használok, adatbázisban, fájlokban egyaránt. Formokhoz van egy "Fillin" szűrő, ami DomDocument osztály használatával "elemzi" a kimeneti stringet, mielőtt elküldené, a formban minden beviteli mezőnek beállítja az értékét, majd a $dom->saveHTML() fv-nyel kiírja a módosított tartalmat. De ezek után úgy jelenik meg az oldal, mintha UTF-8-as oldalt ISO-8859-1-gyel néznék meg. Minden ékezetes karakter helyén két karakternyi krix-krax :-/
A forrásbanszerepel, és megnéztem, utf-8-at kap a konstruktor fv, tehát az biztosan jó.
Ennek ellenére a kimenet "rossz", ha lefut ez a fv. Ha nem, akkor minden rendben. Mi lehet a probléma :?
■ A forrásban
$dom = new DomDocument('1.0', sfConfig::get('sf_charset', 'UTF-8'));Ennek ellenére a kimenet "rossz", ha lefut ez a fv. Ha nem, akkor minden rendben. Mi lehet a probléma :?
október 20
PHP frameworks, Part 2: Building the sample application
A PHP-s keretrendszereket bemutató/összehasonlító IBM cikksorozat 2. része
■ PHP4 -> PHP5 váltás
A problémám a következő lenne:
Itthon fejlesztésre eddig ezt, használtam:
apache: 1.3.33 | php 4.3.10 | mysql 4.1.9 | phpmyadmin 2.6.1 | EasyPHP 1.8
Viszont mysql 5re kellett váltanom igy próbáltam feltenni ezt a két csomagot:
apache: 2.2.3 | php 5.2.0 | mysql 5.0.27 | phpmyadmin 2.9.1.1 | EasyPHP 2.0
apache: 2.2.41 | php 5.2.4 | mysql 5.0.45 | phpmyadmin 2.11.0 | WAMP5
A gond annyi, hogy a 2 újabb szerver alatt megtekintve, az eddig hibátlanul működő weblapon php forrás kód jelenik meg vegyesen HTML elemekkel.
Kérdésem, hogy php4 -> php5 váltásnál van-e valami konverzió amit meg kell ejteni a meglévő forrás kódon.
pl:Eddig egy olyat találtam, hogy a funkcióknál referenciát kell átadniEzt ki is próbáltam viszont ugyan az maradt a hiba jelenség :(
Valakinek valami ötlet?
bye monghuz
■ Itthon fejlesztésre eddig ezt, használtam:
apache: 1.3.33 | php 4.3.10 | mysql 4.1.9 | phpmyadmin 2.6.1 | EasyPHP 1.8
Viszont mysql 5re kellett váltanom igy próbáltam feltenni ezt a két csomagot:
apache: 2.2.3 | php 5.2.0 | mysql 5.0.27 | phpmyadmin 2.9.1.1 | EasyPHP 2.0
apache: 2.2.41 | php 5.2.4 | mysql 5.0.45 | phpmyadmin 2.11.0 | WAMP5
A gond annyi, hogy a 2 újabb szerver alatt megtekintve, az eddig hibátlanul működő weblapon php forrás kód jelenik meg vegyesen HTML elemekkel.
Kérdésem, hogy php4 -> php5 váltásnál van-e valami konverzió amit meg kell ejteni a meglévő forrás kódon.
pl:
$foo = '<a href="valami.html"> link </a>';
/* helyett:*/
$foo = "<a href=\"valami.html\"> link </a>";
function valami($foo) {};
/* helyett: */
function valami(&$foo) {};Valakinek valami ötlet?
bye monghuz
javascript kép "fade-in" problémák
Sziasztok!
A http://clagnut.com/sandbox/imagefades/ link alatt bemutatott javascript alapú "fade in" teknikát akarnám alkalmazni kis módosítással.
A változtatás annyiból áll, hogy bélyegképre kattintva onclick cseréli az érintett nagy képet; a nagy kép (500x500 px) onload eseménye hívja meg az initImage() fv-t -> minden bélyegkép nagyobb megjelenítésénél a hozzá tartozó nagy képre lefut a fade-in, miután az betöltődött...
A megoldás tökéletesen működne (linux / firefox), azonban explorer (xp, 6.x) alól nézve a fade-in legalább 2x lassabban (értsd láthatatlantól a láthatóig eltelt idő) és darabosabban jön be (mintha a window.setTimeout nem jól kezelné az időt vagy a setOpacity lefutása megterhelné(?) a gépet).
A fura az, hogy ugyan az arról a gépről ugyan azt az iexpolrert használva az eredeti oldalon lévő fade-in normál sebességgel megy végbe. (?)
Mi lehet a különbség vagy mi foghatja meg az explorert?
■ A http://clagnut.com/sandbox/imagefades/ link alatt bemutatott javascript alapú "fade in" teknikát akarnám alkalmazni kis módosítással.
A változtatás annyiból áll, hogy bélyegképre kattintva onclick cseréli az érintett nagy képet; a nagy kép (500x500 px) onload eseménye hívja meg az initImage() fv-t -> minden bélyegkép nagyobb megjelenítésénél a hozzá tartozó nagy képre lefut a fade-in, miután az betöltődött...
A megoldás tökéletesen működne (linux / firefox), azonban explorer (xp, 6.x) alól nézve a fade-in legalább 2x lassabban (értsd láthatatlantól a láthatóig eltelt idő) és darabosabban jön be (mintha a window.setTimeout nem jól kezelné az időt vagy a setOpacity lefutása megterhelné(?) a gépet).
A fura az, hogy ugyan az arról a gépről ugyan azt az iexpolrert használva az eredeti oldalon lévő fade-in normál sebességgel megy végbe. (?)
Mi lehet a különbség vagy mi foghatja meg az explorert?
Az Apache és IIS 2008-ra azonos részesedésű lehet
A minap a Szabad Szoftver Esték első rendezvényén hívták fel a figyelmemet, hogy az Apache és az IIS webszerverek elterjedtségi mutatói a teljes internetre nézve egyre inkább közelednek egymáshoz, az Apache immár nem sok előnnyel rendelkezik az IIS-hez képest. Bevallom némi szkepticizmussal fogadtam az információt, hiszen régóta nem néztem meg ezeket az adatokat.
A Netcraft jelentései szerint viszont az utóbbi időben ezek a nagyobb változások olyan eseményeknek voltak betudhatóak, mint, hogy nagy domain parkoló webhelyen szűnt meg egy milliónyi Apache-on futó weboldal, a Blogger Apache-ról a Google GFE kódnevű szerverére váltott és folymatosan növekszik felhasználóinak (aldomainjeinek) száma, míg a MySpace és a Live Spaces felhasználói (aldomain) számának egy hónap alatt milliós növekedése az IIS elterjedési számát növeli. Így az IIS webszervereken futó domainek abszolút száma és százaléka is növekszik. A Netcraft becslései szerint ha a trend így folytatódik, 2008-ban az Apache és az IIS közel azonos elterjedtséget mutat majd.
■ A Netcraft jelentései szerint viszont az utóbbi időben ezek a nagyobb változások olyan eseményeknek voltak betudhatóak, mint, hogy nagy domain parkoló webhelyen szűnt meg egy milliónyi Apache-on futó weboldal, a Blogger Apache-ról a Google GFE kódnevű szerverére váltott és folymatosan növekszik felhasználóinak (aldomainjeinek) száma, míg a MySpace és a Live Spaces felhasználói (aldomain) számának egy hónap alatt milliós növekedése az IIS elterjedési számát növeli. Így az IIS webszervereken futó domainek abszolút száma és százaléka is növekszik. A Netcraft becslései szerint ha a trend így folytatódik, 2008-ban az Apache és az IIS közel azonos elterjedtséget mutat majd.
OFF: Helyesírási jelenség a weblaboron
Nem provokatív szándékkal nyitom ezt a témát, de (mint a témában végzettnek is) feltűnt egy ideje, hogy a Weblaboron konzekvensen nagybetűvel írja mindenki a második személyű személyes névmást, minden ragozott alakban (Te, Általad, Neked stb.).
Gondoltam, nem baj, ha közlöm, hogy ez helyesírási hiba, pontosabban valószínűleg egyfajta nyelvközösségi hiperkorrekció. Az AkH. (akadémiai helyesírás) ezt a gyakorlatot nem ajánlja ilyen mindennapi diskurzusban, a hétköznapi tiszteletadás funkciójára. A személyes névmások nem tulajdonnevek, ezért a nagybetűs írásuk kivételes esetnek minősül, mikor a megszólított félnek megkülönböztetett tiszteletet akar az író adni.
Volt egy ilyen félig-meddig városi legenda is, hogy "a megszólítás nagybetűvel írandó", lehet, hogy ez is belejátszik.
Nem akarom megszólni az itteni írott nyelvhasználatot, de talán tényleg nem árt, ha ezt leírom. Én ezt még sehol máshol nem tapasztaltam (azért is írom ide, különben nem a weblaborra tartozna); ennél formálisabb körökben sem. Még az alanyeseteken el lehet vitatkozni ("Ön"-ön inkább, "Te"-n már kevésbé), de az ilyen Általad, Benned, Neked, Hozzád-ok, azt hiszem, végképp tévedésen alapulhatnak (s kicsit komikusan is hatnak).
Offoltam, nem szakmai téma, nem akartam érzékenységet sérteni, ha problémás a topik, vágjátok ki. Csak tényleg már régóta szemet szúr.
■ Gondoltam, nem baj, ha közlöm, hogy ez helyesírási hiba, pontosabban valószínűleg egyfajta nyelvközösségi hiperkorrekció. Az AkH. (akadémiai helyesírás) ezt a gyakorlatot nem ajánlja ilyen mindennapi diskurzusban, a hétköznapi tiszteletadás funkciójára. A személyes névmások nem tulajdonnevek, ezért a nagybetűs írásuk kivételes esetnek minősül, mikor a megszólított félnek megkülönböztetett tiszteletet akar az író adni.
Volt egy ilyen félig-meddig városi legenda is, hogy "a megszólítás nagybetűvel írandó", lehet, hogy ez is belejátszik.
Nem akarom megszólni az itteni írott nyelvhasználatot, de talán tényleg nem árt, ha ezt leírom. Én ezt még sehol máshol nem tapasztaltam (azért is írom ide, különben nem a weblaborra tartozna); ennél formálisabb körökben sem. Még az alanyeseteken el lehet vitatkozni ("Ön"-ön inkább, "Te"-n már kevésbé), de az ilyen Általad, Benned, Neked, Hozzád-ok, azt hiszem, végképp tévedésen alapulhatnak (s kicsit komikusan is hatnak).
Offoltam, nem szakmai téma, nem akartam érzékenységet sérteni, ha problémás a topik, vágjátok ki. Csak tényleg már régóta szemet szúr.
