- Ezek a OnePlus 12 és 12R európai árai
- Android alkalmazások - szoftver kibeszélő topik
- Mobil flották
- Redmi Note 13 Pro+ - a fejlődés íve
- Milyen okostelefont vegyek?
- Fotók, videók mobillal
- Samsung Galaxy S23 FE - nincsen sárkány
- Okosóra és okoskiegészítő topik
- Samsung Galaxy S23 Ultra - non plus ultra
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
úgy érted, ha van egy ilyen képed a http://oldalad.hu/adsasd/asdasd/index.php fájlban, hogy pl
<img src="blabla/akarmi.jpg" />
akkor a
http://oldalad.hu/adsasd/asdasd/blabla/akarmi.jpg elérési útvonalon fogja keresni?
Mert akkor az nem meglepő. Vagy lehet, hogy félreértettem, amit írtál.[ Szerkesztve ]
Sk8erPeter
-
Brown ügynök
senior tag
válasz Tele von Zsinór #8249 üzenetére
Ha én nem sütiben tárolom a session értékeket, de url-be sem teszem bele (nem meghatározott url -> 404) , attól még ugyanúgy támadható a session?
-
biker
nagyúr
válasz Sk8erPeter #8251 üzenetére
félre.
ha a www.valami.hu/kategoria/szam/nev át van iránytva és az valójában www.valami.hu/index.php?kat_ID=szam&kat_nev=nev verzióra, és az index.php-ben nem /kep.jpg van hanem csak kep.jpg
akkor www.valami.hu/kategoria/szam/nev/kep.jpg-t fog keresni nem www.valami.hu/kep.jpg-tElektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Tele von Zsinór
őstag
válasz Brown ügynök #8252 üzenetére
Hogy máshogy adod át az sid-t?
Igazából ez a támadás csak akkor működik, ha a szerveren engedélyezve van a session.use_trans_sid és a sütis megoldás is.
-
Brown ügynök
senior tag
válasz Tele von Zsinór #8254 üzenetére
Sütivel adom át, világos. Az kavart meg, hogy localhoston próbáltam, de a tmp-ből nem töröltem a cookie-t, így a session is fenn állt.
session.use_trans_sid pedig alapból nincs engedélyezve.
[ Szerkesztve ]
-
MODERÁTOR
Sziasztok!
Kis segítségre lenne szükségem! Codeigniter + Newhosting párossal van a bajom! Sajnos ha nem adom meg a routes -ban definiált controller nevet akkor egy 404 -et dob a newhosting. Localhoston megy. Csak lövésem nincsen már mi a gond.
GoDaddy féle beállításokkal vagyok jelenleg!
Remélem lakozik köztetek egy Codeigniter expret!
Köszi!
mobal,
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
fazr
senior tag
Sziasztok!
Lenne néhány kérdésem. Előre is bocs, ha valamelyik hülyeség, nem régóta kezdtem el foglalkozni php-val.
1, Ha Sessionnel csinálok beléptetést és azt akarom, hogy a böngésző újbóli megnyitásakor is bejelentkezve maradjon a felhasználó, akkor ezt gondolom cookieval kell megoldani.
A kérdés az lenne, hogy ilyenkor mit kell tárolni a cookieban? Hogy kell megoldani?2, Gondolom a fájl és a tartalom kódolásánál UTF-8 lenne a kézenfekvő, de mégsem jó.
Pl az strlen() az ékezetes karaktereket duplán számolja. ANSI fájlkódolással és Latin2 charsettel már tökéletes.
Utóbbival annyi bajom van csak, hogy ha esetleg nemzetközi oldalt csinálok, akkor lehet kevés a Latin2.Ezekkel összefügg a mysql karakterkészlete? Úgy értem, hogy amilyen kódolást használok a php fájloknál, ugyan azt kell használni az érintett tábláknál is?
3, Olvastam több helyen, hogy már nem ajánlott sima mysql_* parancsokat használni adatbázis kapcsolódásra és parancsok végrehajtására. Mit ajánlotok? Mysqli-t PDO-t, vagy mást?
4, Ha valamilyen mysql hiba lép fel, akkor érdemes az eredeti hibaüzenetet elnyomni és kiírni egy szűkszavú sajátot (azt ami a felhasználóra tartozik), vagy ez nem okoz sebezhetőséget és csak esztétikai szerepe van? Az eredetit persze én meg tudnám nézni (email/log, vagy valami ilyesmire gondoltam, vagy ha van jobb, akkor kiváncsian várom).
5, SQL injection ellen hogy lehet hatásosan védekezni? A metódus belseje "összetömörítve":
if( function_exists( "mysql_real_escape_string" ) ) {
if( get_magic_quotes_gpc() ) { $value = stripslashes( $value ); }
$value = mysql_real_escape_string( $value );
}
return $value;Ha valamivel ki kell egészíteni, akkor légyszíves írjátok le mivel és milyen módon.
Ugye minden esetben el kell ezt játszani (meghívni a metódust), amikor adatbázishoz nyúlok? Pl regisztáció, hozzászólás írás, bejelentkezés és egyéb űrlapok mellett még mikor kell?6, Regisztráció után aktiváló email kivitelezése így mennyire jó? Nagy vonalakban:
- Generálok egy kódot, amit mentek adatbázisba (ezt a felhasználók táblájába kell, vagy érdemes máshol kezelni?), valamint elküldöm az illetőnek emailben (pl link formájában)
- Csinálok egy feldolgozó php fájlt, ami get metódussal kapja meg az adatot az aktiváló linkre kattintva (itt /is/ gondolom védekezni kell sql injection ellen) és ha sikerült az aktiváció, akkor true-ra kell állítani a felhasználók táblában lévő activated mezőt.[ Szerkesztve ]
-
MODERÁTOR
1. Session -nal csinálod, akkor a session tömböt használd - [link]. Én úgy szoktam, hogy csinálok egy random valamit, amit eltárolok mind a session tömbben, mind az adatbázisban és ha létezik + megegyezik, akkor tovább dobom a usert, ellenkező esetben beléptetem újra.
2. Az utf8 -nak jónak kéne lenni, ott valami nem jó szerintem. Ha teheted utf8 -at használj, igen mindenhol.
3. PDO
4. Hát amíg fejlesztesz, szerintem mindent írass ki, utána pedig logolj.
5. a mysql_real_escape_string elvileg "elég".
6. Mondjuk kiküldesz neki egy random jelszót, amit első bejelentkezéskor kell megváltoztatni, és akkor állítod true -ra a változóját?
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
-
Sk8erPeter
nagyúr
Lenne még hozzáfűznivalóm:
igen, lehetőleg egyezzenek a karakterkódolásaid.
4. pontra: igen, sebezhetőséget jelent az, ha kiíratsz bármi "nyers" hibaüzenetet. Már eleve az egy sebezhetőség, hogy bármilyen információt árulsz el a rendszered belső működéséről. Akár mezőnevek, akár szintaktikai hibák adott lekérésben vagy máshol, akár elérési utak, vagy bármilyen, a külvilágra nem tartozó információ segíthet egy ártó szándékú látogatót a céljai elérésében. Ezt akkor hiszed majd el igazán, ha valaki gyakorlati példán mutatja be neked (mondjuk előadás keretében), hogy egy sebezhető rendszer adataihoz pl. kiírt hibaüzenetek alapján hogyan lehet még gyorsabban hozzájutni; akár bejuttatni saját, nem kívánt adatot a rendszerbe.
PDO tényleg jó, és ha ezt kezded el használni, könnyebben rá fog állni a kezed és agyad az ORM-ek használatára.
Most hirtelen még ennyi jutott eszembe.[ Szerkesztve ]
Sk8erPeter
-
Peter Kiss
őstag
-
fazr
senior tag
válasz Sk8erPeter #8264 üzenetére
Egy egyszerű példa:
akarmi.php utf-8 kódolású fájl:
<?php
// ha ez nincs itt akkor is rossz sima strlen()-nel
header("Content-Type: text/html; charset=utf-8");
$str = "é";
echo strlen($str) . "<br />"; // 2-t ad vissza
echo mb_strlen($str, "utf-8"); // 1-et ad vissza
?>(#8265) Athlon64+:
Prepared statementtel kapcsolatban kérdezném, hogy mellette kell használni a mysql_real_escape_string-et? Ha manualból jól értem, akkor kell.köszi mindkettőtöknek
[ Szerkesztve ]
-
Tele von Zsinór
őstag
1. erre az az általános megoldás, hogy bejelentkezéskor egy hosszú lejáratú sütit is adsz a felhasználónak valami véletlen értékkel, amit emellett egyaránt tárolsz adatbázisban. Legközelebb, ha olyan helyzet áll elő, hogy ilyet kapsz, de sessiont nem, akkor tudod ellenőrizni, van-e ilyen azonosítójú "hosszú session", és belépteted a megfelelő felhasználót.
Az alkalmazás megkövetelt biztonsági szintjétől függ, hogy pár nap vagy pár hét lejáratú a süti, illetve hogy milyen gyakran cseréled az így tárolt random értéket.2. az utf8 egyike a számos úgynevezett változó szélességű karakterkódolásnak - jelen esetben ez annyit tesz, hogy egy karaktert lehet, hogy egy byte kódol, de akár szükség lehet hatra is. A php-ban vannak erre szolgáló függvények, ezek neve mb_-vel kezdődik, itt az összefoglaló dokumentáció a multibyte stringfüggvényekről. Elsőre soknak tűnhet, de kellenek.
3. azokról valóban érdemes leszokni. A már meglevő kódjaid ne féltsd, még legalább évekik létezni és működni fognak azok a függvények is.
A vélemények megoszlanak, de a többség (én is) arra hajlik, hogy a PDO jobb. Hasznos lehet, ha menet közben esetleg váltanod kell másra (mysql helyett pgsql, például), magánvéleményem szerint az apija is kényelmesebb, nem túl rég írtam egy rövid bevezetőt a PDO-ba, ezt az aláírásomban szereplő .eu-s linken megtalálod).4. ha valami hiba történik, arról értelmezhető hibaüzenetet soha ne kapjon a felhasználó. Semmit nem ér vele, általános esetben legfeljebb összezavarja, rossz esetben megtud valami olyat a rendszer belső működéséről, amit támadási felületként használhat - ezt hívják információszivárgásnak. Bármi hiba történik, amit nem tudsz lekezelni normálisan, a felhasználó kapjon egy általános http500-as hibaoldalt. Ez nálam egy sima html oldal, php-ből include-olom és die(). Nyilván naplózás után.
5. olvass utána a prepared statement kifejezésnek. Röviden: átadsz a szervernek egy queryt, jelezve, hogy itt és itt és itt paraméterek lesznek. Ezt ő előkészíti, aztán mondod, hogy hajtsa végre azt, ezekkel a paraméterekkel. Legjobb tudomásom szerint tökéletes védelem az SQL injection ellen, felesleges körök nélkül.
A még mysql_ függvényeket használó kódjaidban elég a mysql_real_escape_string mindenre! alkalmazva, ami a felhasználótól jön. És nyugodtan feltételezheted, hogy a függvény létezik, nem kell külön ellenőrizni.6. ennyi. Esetleg hetente egyszer egy olyat csinálj, hogy törlöd azokat, akik legalább n napja regisztráltak, de még azóta sem aktiváltak.
-
fazr
senior tag
válasz Tele von Zsinór #8268 üzenetére
Köszi a részletes választ és a PDO-s írásodat is elolvasom hamarosan.
(#8267) Sk8erPeter Nem vettem észre, hogy törölted Mindegy.
-
Lacces
őstag
Tele von Zsinórés Brown Ügynök: Köszönöm. (Session, Cookie)
-
Brown ügynök
senior tag
válasz Tele von Zsinór #8268 üzenetére
Úgy látom, ha egy bizonyos fokú adatbázis függetlenséget szeretnék akkor PDO-t kell használjak. Gondolom, egy idő után csak PDO lesz.
[ Szerkesztve ]
-
Lacces
őstag
válasz Brown ügynök #8271 üzenetére
Igen . Jó bár én kezdő vagyok. De olvastam a Murach féle PHP-s könyvben, hogy a PDO-val lehet megvalósítani az adatbázis függetlenséget. (Ez az előnye)
Viszont cserébe nem tudod az összes MySQL feature-t elérni (vagy spec parancsok). (Ez a hátránya) -
Lacces
őstag
Sziasztok!
Egyik:
Azt szeretném elérni, hogy ha hiba keletkezik, a fájlok betöltésével (vagy bármilyen köztes php kód esetén hiba lépne fel), akkor a végén a szerver Ahelyett, hogy kiírná az oldalra a hibát, egy teljesen másik oldalra irányítson át.
Pl.: require ('./includes/title.inc.php'); - ben talál hibát, akkor írányítson át az error.php-ra.
De sajnos nem az teszi, hanem kiírja szépen az oldalra a szokásos hibaüzenetet... És ezt szeretném elkerülni (van egy statikus html oldal, amit be kéne hoznia helyette:error.php)
következő kód:
<?php
ob_start();
try{
require ('./includes/title.inc.php');
require ('./includes/random_image.inc.php');
?>
... HTML Kód részletek....
<?php
}catch(Exception $e){
ob_end_clean();
header('Location: http://'.$_SERVER['HTTP_HOST'].'/error.php');
}
ob_end_flush();
?>header('Location: http://'.$_SERVER['HTTP_HOST'].'/error.php'); lehet ez a rossz, de megpróbáltam, úgy hogy a közvetlen url címét adom meg...
Másik:
Ha ez a fájlom helye: http://localhost/PHP/error.php, akkor jó-e a rá ez?
header('Location: http://'.$_SERVER['HTTP_HOST'].'/error.php');
Vagy ki kell egészítenem még egy /PHP/ részlettel? -
Tele von Zsinór
őstag
válasz Brown ügynök #8271 üzenetére
Igen, ekkor a PDO a nyerő választás. Váltáskor viszont az összes queryd ellenőrizni kell, mert szerencsére DB-típusonként mások a field meg string delimiterek, az esetleges SQL-szintaktikai különbségekről nem is beszélve. Emiatt találták ki az ORM-eket, amik pont ezt a részét elfedik előled. Személyes kedvencem a doctrine.
Lacces: azért nem működik, mert a require errort dob, te meg az exceptionöket kapod el. Az error a régi megoldás, szépen lassan áll át maga a php motor is az exceptionök használatára, de ez még idő lesz. Addig talán úgy jársz a legjobban, ha a set_error_handler() függvénnyel beállítasz egy hibakezelőt, ott pedig az errort egy exceptionbe csomagolod és throw-olod. Ezt már el fogja kapni a catch(). Átirányítás helyett érdemesebb lenne ott include-olni az error.html-t. Célszerű egy egyszerű, elronthatatlan, statikus html oldalt használni erre. Persze nem mindig megoldható, de olyankor is törekedj a legegyszerűbb php kódok használatára.
Utolsó kérdésedre: kell a /PHP/.
-
Lacces
őstag
válasz Tele von Zsinór #8275 üzenetére
"Persze nem mindig megoldható, de olyankor is törekedj a legegyszerűbb php kódok használatára." - Kezdőként még nehéz rájönni, mi lenne az, én csak követem vakon amiket mások írnak könyvben/online.
De számítok rátok, hogy rám szóltok, mivel tudnám megkönnyíteni az életemet .Try / Catch-t ajánlom is, hogy hozzák be a PHP-ba.
A set_error_handler()-re tudnál nekem dobni egy konkrét példát?
Hmm... nézem a kommenteket valami dereng, de nem teljesen világos.
Hozzak létre egy osztályt is? (Amely az Exception-ből származik)
Mint ez:class CustomException extends Exception {
public function setLine($line) {
$this->line=$line;
}
public function setFile($file) {
$this->file=$file;
}
}
function exceptionsHandler($code, $string, $file, $line) {
$exception=new CustomException($string, $code);
$exception->setLine($line);
$exception->setFile($file);
throw $exception;
}
set_error_handler('exceptionsHandler', E_ALL);Ahogy néztem a PHP Manul-t (amit linkeltél), a kommenteket sok féle megoldással álltak elő és nah, nekem kicsit fura ez a szkript nyelv Még az elején...
És akkor az E_ALL helyett E_ERROR-t használjak?
Illetve a set_error_handler()-t hol helyezem el? A try ág végén? (dobom a kivételt, és a catch-el el kell kapnia) A sima catch(Exception) és elkapja amit létrehoztam igaz?
Ez nekem annyira új, hogy nézz ki komplexben.
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
"Viszont cserébe nem tudod az összes MySQL feature-t elérni (vagy spec parancsok). (Ez a hátránya)"
Mégpedig?(#8273) Lacces :
mivel még az elején vagy, még most felejtsd el az output bufferinget (ob_start(), stb.). Az esetek 95%-ában megoldható a problémád anélkül is. Vagy lehet, hogy mondhattam volna magasabb százalékarányt is.
Cserébe szebb lesz a kódod.(#8276) Lacces :
"Try / Catch-t ajánlom is, hogy hozzák be a PHP-ba."
Már "behozták", Te is használod."És akkor az E_ALL helyett E_ERROR-t használjak?"
Ezt Te döntheted el, de szerintem érdemes E_ALL | E_STRICT beállítást használni (6-os PHP-nál az E_STRICT már az E_ALL része lesz). Ez a legszigorúbb hibaellenőrzés. De mivel a hivatalos doksi szerint épp ez a default beállítás, legegyszerűbb, ha ezt a második paramétert meg sem adod, aztán megfelelő módon lekezeled a hibákat, persze ez már egyéni döntés kérdése.A set_error_handler-t valahol a "főfájlod" elején, egyfajta inicializálásként add meg. Kukkantsd meg a példákat rá.
Sk8erPeter
-
Brown ügynök
senior tag
válasz Tele von Zsinór #8275 üzenetére
Kezd derengeni az Abstraction Layer és az ORM fogalma.
A doctrine ismerős a Symfony2-ből. Végigvettem egy blogos tutorial-t ami ezzel készült és meg kell mondjam nagyon gyors. Valószínűleg az Abstraction Layer-nek és az orm-nek is köszönhető.
(#8277) Sk8erPeter Output buffering nélkül nehéz lenne részoldalakat összerakni.
-
Lacces
őstag
válasz Sk8erPeter #8277 üzenetére
Működik: Az set_exception_handler() is kellett neki Az első kommentelő a gyereknek a megoldása alapján, na meg Tele Von Zsinor kollégának az exception szava fogott meg.
set_error_handler('my_error_handler');
set_exception_handler('my_exception_handler');
function my_exception_handler($e) {
throw new ErrorException();
}
function my_error_handler($no,$str,$file,$line) {
$e = new ErrorException($str,$no,0,$file,$line);
my_exception_handler($e);
}Try/Catch-t meg úgy értem, hogy Java szinten (objektum szinten menjenek). (Sosem hittem volna, hogy ezt mondom, de hiányzik egy kicsit, hogy Java-ban programozak... XD Szerintem holnap folytatom azt is tovább)
output_buffering()... Háthogy jó És akkor mikor érdemes vagy kell használni? Csak, hogy kommentben meglegyen. Mert közben építem a PHP tudástáramat XD. Most hogy a könyveket elolvasva, azok példáját megcsinálva (és azok példakódjai alapján) építem a saját kis php weblapomat így már erősen felfogom a dolgokat, és módosítok magamtól is. Új feateröket hozzok létre (Bocs az angolért)
"Viszont cserébe nem tudod az összes MySQL feature-t elérni (vagy spec parancsok). (Ez a hátránya)"
Mégpedig?
Kikerestem neked:
Doesn't take advantage of some advanced features found in MySQL 4.1.3 and later, such as multiple satements.
Illetve még azt írta, hogy a 4-es az előtti PHP-val nem műxik a PDO. -
Sk8erPeter
nagyúr
válasz Brown ügynök #8278 üzenetére
Milyen részoldalakra gondolsz?
Példa is jöhetne, hogy érthető legyen.(#8279) Lacces :
ja igen, a multiple statements támogatása valóban nincs meg jelenleg a PDO-nál, igaz, én fejlesztés során nem is nagyon szoktam érezni a hiányát, persze nyilván van olyan alkalmazás, ahol ez jól jönne. De fejlődik a PDO is, esélyes, hogy későbbi verziókban meglesz erre is a támogatás, hogy mikor, és tényleg lesz-e, azt nem tudom.Output buffering: pl. a Te példádban tuti, hogy felesleges. Van olyan eset, ahol elő lehet venni, mert jól jöhet, de mint mondtam, az esetek többségében csak ocsmány módszer. Mégis sajnos sokan alkalmazzák pl. arra, hogy már bármilyen output kiíratása után akárhol is tudjanak headereket küldeni, de nem jó gyakorlat. Headereket az output előtt kell kiküldeni.
Sk8erPeter
-
Lacces
őstag
válasz Sk8erPeter #8280 üzenetére
Oks, értem
-
Brown ügynök
senior tag
válasz Sk8erPeter #8280 üzenetére
Ha van egy oldalam header, section, footer-rel akkor azt nem szeretném mindegyik oldalnál újra és újra megírni, elég ha egyszer elkészítem és az összes többi oldal tartalmát abba ágyazom bele.
-
Sk8erPeter
nagyúr
válasz Brown ügynök #8282 üzenetére
Igen, és ennek eléréséhez include-olod azok tartalmát mindenhol, ahol kell, így elég egy helyen megírni.
De ehhez határozottan NEM kell output buffering!
Ennek megfelelően nem is szokták ilyen esetben ezt alkalmazni.Sk8erPeter
-
Tele von Zsinór
őstag
válasz Sk8erPeter #8283 üzenetére
Ha a decorator patternt használod, akkor kell. Cserébe nincs az összes view-edben a header és footer include.
-
Brown ügynök
senior tag
válasz Sk8erPeter #8283 üzenetére
Talán Tele von Zsinórnak jobban hiszel mint nekem.
[ Szerkesztve ]
-
CSorBA
őstag
Valahogy ez kimaradt, de ha már így feléledt a topic, gondolom rákérdek.
Különböző országokban más dátumformátumok vannak, ugye Gregorian Little Endian, Gregorian Big Endian, Middle Endian ráadásul ezen belül is eltérnek a szeparátorok. Pl ha jól tudom oroszoknál: Nap/Hó/év van, Angliában: Nap.Hó.Év. nálunk: Év.Hó.Nap, Amerika Hó/Nap/Év. Van rá valami lehetőségem, hogy ez is a localeon alapuljon? Vagy pedig szépen nekem kell formasablonokat csinálnom? Esetleg vmi osztályról tud valaki?
-
Lacces
őstag
Sziasztok!
Sziasztok írtam egy kis algo-t amivel letudom kérdezni a gyökérkönyvtár közvetlen alkönyvtárainak a fájlait és azt, hogy melyik könyvtárban vannak.
Ezt egy $subDir tömbben tárolom. A kulcs a fájl neve, az érték meg a könyvtár.
Viszont azt nem tudom, hogy hova kéne behelyeznem asort() függvényt, ami rendezné a fájlok nevét vagy a $subDir kulcsait abc-s sorrendben.
for($i =0 ; $i<count($dir);$i++){
$dirPath= $dir[$i] . '/'; // megkapja a könyvtár heléyt
$dirIterator = new DirectoryIterator($dirPath); // könyvtár bejáró objektum
foreach ($dirIterator as $f){
if(!in_array($f, $noVisible)){ // Könyvtárak kiszűrése, melyekbe ne menjen bele
$temp = $f->getFilename(); // fájl nevének megszerzése
$subDir[$temp][] = $dir[$i]; // fájl elhelyzése, és a hozzá tartozó aktuális könyvtár helye
}
}
}Bár gondolkoztam azon, hogy esetleg szétszedem 2db foreach-re az egyikkel begyüjtöm a fájlok nevét a $temp tömbbe, azt rendezem, és egy másik foreach-el feltöltöm a $subDir-t
[ Szerkesztve ]
-
Tele von Zsinór
őstag
Ha elérhető a PECL Intl, akkor valószínűleg ezzel jársz legjobban: IntlDateFormatter.
Symfony2-ben ugyanennek a Locale komponens a fallbackje.
-
CSorBA
őstag
válasz Tele von Zsinór #8288 üzenetére
Pont most lettem kész egy kis sablonos helperrel. Bár az a gondom, nem tudom pl az orosz dátumok helyesírását Ránézek ezekre mindjárt, köszi szépen!
-
Lacces
őstag
A következő a probléma:
Képeket töltök fel, amelynek a neve magyar ékezeteket tartalmaz... És amikor feltöltöm a kép nevekere azt íjra ki, hogy érvénytelen kódolás... Látszik is hogy a fájl neve sok szimbólumot tartalmaz.
Ezt hogy lehet kiküszöbölni?
-
Lacces
őstag
válasz Tele von Zsinór #8291 üzenetére
PHP-nak van olyan metódusa ami ezt megcsinálja automatikusan? Vagy nekem kell egy reg kifejezést írni rá?
-
Tele von Zsinór
őstag
Mivel általában úgyis adatbázis-rekordhoz kötöd a képet, annak az id-je tökéletes lesz a file nevének is. Ha egy rekordhoz több tartozik, akkor meg valami suffix eldönti, melyik melyik (1_small.png, 1_large.png).
CSorBA: http://demo.icu-project.org/icu-bin/locexp?d_=en&_=ru_RU
[ Szerkesztve ]
-
CSorBA
őstag
válasz Tele von Zsinór #8294 üzenetére
Ezaz!! Remek, nagyon szépen köszönöm.
-
Zefír
őstag
Sziasztok!
Az lenne a kérdésem, hogy beraktam egy favicon-t az index.html-be, ott meg is jeleníti, de amikor belépek az oldalamra, a gindex.php-ban már nem,
Milyen kóddal kéne beírni a php-ba? próbáltam ezzel:<link rel="shortcut icon" href="images_/favicon.ico"/>
de nem látszik, csak a html-ben.
Mi lehet a baj? -
Sziasztok
MSSQL-hez szeretnék csatlakozni, de még hibát sem ad vissza, egyszerűen meg se jeleniti az oldalt vagy http:500-as errorral leáll a böngésző
<?php
// Connect to SQL Server and check for errors
// $conn = mssql_connect($db_host,$db_user,$db_password);
$db_host="ff_lnv_dbt.***.com";
$conn = mssql_connect($db_host,'f*****','f***') or die("System Maintenance!!!".myssl_error());
if ($conn==false)
{
echo '<p>Cannot connect to SQL Server Database. Please try again later.</p>';
exit;
}
?>mi lehet a baj? Esetleg apachnál kellene vmit még beállitani?
A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
Tele von Zsinór
őstag
Error log mit mond?
Ha ez fejlesztői gép, akkor kapcsold be a php.ini-ben a hibajelzést:
- display_errors legyen On
- error_reporting legyen E_ALL | E_STRICTA leírásod alapján legvalószínűbb ok a mssql kiterjesztés hiánya, ezt a php.ini-ben tudod engedélyezni (windowson általában csak ki kell venni a pontosvesszőt az ext=php_mssql.dll sor elől).
-
válasz Tele von Zsinór #8299 üzenetére
Köszi! Holnap megnézem mi lehet.
Az mennyire lehet probléma, hogy én if ($conn==false) írtam, míg a tutoriálban if ($conn===false) volt? Lehet egyáltalán 3 db = jel?A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
Új hozzászólás Aktív témák
- MSI GTX 1660 GAMING X 6gb újszerű
- Panasonic CF-20 ütésálló, ipari notebook & tablet számlával, garanciával
- Arctic P12, P14, Slim, Max, PWM, PST
- Lenovo ThinkPad E495 Ryzen 5 pro 3500U, 8GB RAM, 256GB SSD, jó akku, szép állapot, számla, garancia
- Lenovo ThinkPad X395 Ryzen 5 pro 3500U, 16GB RAM, 256GB SSD, jó akku, szép állapot, számla, garancia
Állásajánlatok
Cég: HC Pointer Kft.
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest