- Samsung Galaxy S23 Ultra - non plus ultra
- Google Pixel topik
- Xiaomi 14T Pro - teljes a család?
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Okosóra és okoskiegészítő topik
- Yettel topik
- Fotók, videók mobillal
- Samsung Galaxy A56 - megbízható középszerűség
- Apple iPhone 17 Pro Max – fennsík
- Íme, a One UI 8.5 újításai
Új hozzászólás Aktív témák
-
#8669
Tele von Zsinór
őstag
Speeedfire
#8668
Tele von Zsinór
őstag
válasz
Speeedfire
#8668
üzenetére
Mert így a leveleid küldése teljesen független bármi klienstől.
-
#8666
Tele von Zsinór
őstag
Speeedfire
#8662
Tele von Zsinór
őstag
válasz
Speeedfire
#8662
üzenetére
De jobban jársz, ha írsz egy mailküldő scriptet, amit crontabbal ütemezel.
-
#8657
Tele von Zsinór
őstag
cAby
#8655
Tele von Zsinór
őstag
history.length - The length property of the history object returns the number of elements in the history list.
An example to understand the length property of history object:
<script type="text/javascript">
var numberofvisited = history.length;
document.write("The number of pages visited
in this window is" +numberofvisited+ " pages.");
</script> -
#8620
Tele von Zsinór
őstag
spammer
#8609
Tele von Zsinór
őstag
válasz
spammer
#8609
üzenetére
Egyszerűbb, ha csinálsz neki egy adminfelületet, terméklistázással és -szerkesztéssel. Az xls olvasása sem túl bonyolult, de jóval több benne a buktató.
Lacces: ez a kód, amit mutattál, működik. A hiba másutt van.
-
#8560
Tele von Zsinór
őstag
CSorBA
#8559
Tele von Zsinór
őstag
Sajnos ez a valóság, 20% körül van az 5.3 használata: [link]
Nekem is a hetekben kellett birkózni egy 5.3-as szerverért - elkészült a rendszer, minden működött rajta, és deploy során derült ki, hogy a megrendelő szerverén 5.2 van. Jó idő kellett meggyőzni a rendszergazdát, hogy oldja meg.
-
#8557
Tele von Zsinór
őstag
Peter Kiss
#8556
Tele von Zsinór
őstag
válasz
Peter Kiss
#8556
üzenetére
Tegnapra volt tervezve a végleges, de komoly hibát találtak benne, ezért jött mégegy RC. Ugyanezt már eljátszották február másodikán is
Linux alatt játszottam már vele, még nem futottam komoly problémába.Szerk. 5.4-et olvastam
4.4, atyaég, ennyire régi kódot használnak még, hogy az kell neki? -
#8551
Tele von Zsinór
őstag
j0k3r!
#8547
Tele von Zsinór
őstag
A kódod nagyjából követi a PSR-0 néven ismert elnevezési szabályt, érdemes volna utánaolvasnod. Ennek vannak kész, nagyon jó autoloader megoldásai, például a Symfony2 ClassLoader komponense.
-
#8504
Tele von Zsinór
őstag
Lacces
#8503
Tele von Zsinór
őstag
Én nagyjából az előbbit szoktam használni - jobban szeretem, ha egy tömbbe kerülnek bele a rekordok, és akkor teljesen egyértelmű, hogy ez sima változó, amaz meg adatbázisból jön (mert jóval később, amikor már a template résznél jársz, nem szokott egyértelmű lenni).
Az alternatív vezérlési szintaktikának nézz utána, mert a { ?> nagyon ronda. Így képzeld el:
<?php foreach ($izek as $valami): ?>
ide jön a html
<?php endforeach ?> -
#8420
Tele von Zsinór
őstag
Speeedfire
#8418
Tele von Zsinór
őstag
válasz
Speeedfire
#8418
üzenetére
Leginkább olyan helyre rakd, ami nem elérhető kívülről. Ha ez nem megoldható, vizsgáld a php_sapi_name() fv. visszatérési értéke "cli"-e.
-
#8368
Tele von Zsinór
őstag
Siriusb
#8367
Tele von Zsinór
őstag
válasz
Siriusb
#8367
üzenetére
Én szeretem az OpenID-t, mostanra elég elterjedt. A google-t szoktam használni authentikátornak (azaz az ott levő identitásommal lépek be, nem saját szerverrel). De például okáért a facebook is openid-szolgáltató, az meg elég ismert
FF10, és működnek.
-
#8364
Tele von Zsinór
őstag
Siriusb
#8363
Tele von Zsinór
őstag
válasz
Siriusb
#8363
üzenetére
Regisztrációhoz és bejelentkezéshez kötöd. Vagy mondjuk OpenID-val google fiókhoz, ezt elég egyszerű megoldani. Gitorious csúnyán le van most halva, később nézz rá, a lényeg: lightopenid class + ~25 sor kód és kész a guglis openid-belépés.
-
#8327
Tele von Zsinór
őstag
mobal
#8326
Tele von Zsinór
őstag
Ezt keresed esetleg?
foreach ($data[0] as $k => $v) {
View::bind_global($k, $v);
}Tipp: legközelebb ne var_dump(), hanem var_export() kimenetét másold, az valid php kódot generál, azaz más csak copypasteli és rögtön kísérletezhet.
És egy cseppet meglepődtem, mikor a pastebin mysql syntax errorral fogadott
Aposztróf van a user-agentemben, ezek meg escapelés nélkül rakták querybe. -
#8318
Tele von Zsinór
őstag
Speeedfire
#8317
Tele von Zsinór
őstag
válasz
Speeedfire
#8317
üzenetére
A git viszonylag egyszerűen összerakható és használható, a legalapabb dolgokat egy óra kísérletezéssel simán megtanulod annyira, hogy ne legyen probléma később. És áldás tud lenni egy verziókövető, egyszemélyes projekteknél is.
-
#8301
Tele von Zsinór
őstag
sonar
#8300
Tele von Zsinór
őstag
Számíthat, de itt nem emiatt kaptad a fehér oldalt.
Létezik === operátor.
-
#8299
Tele von Zsinór
őstag
sonar
#8298
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).
-
#8294
Tele von Zsinór
őstag
Lacces
#8292
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
-
#8288
Tele von Zsinór
őstag
CSorBA
#8286
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.
-
#8284
Tele von Zsinór
őstag
Sk8erPeter
#8283
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.
-
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/.
-
#8268
Tele von Zsinór
őstag
fazr
#8260
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.
-
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.
-
Tele von Zsinór
őstag
válasz
Brown ügynök
#8248
üzenetére
Azért ez így nem igaz. A sessionid megtartására két taktika van: a sütis és a transitive ID, amikor az url-be teszi bele a php (iniben beállítható módon). Az ordító biztonsági veszélye miatt az utóbbit gyakran kikapcsolják szerveroldalon, azaz ha a kedves user megöli a cookie-jait, általában máris nem megy a session.
Lacces: a legfontosabb különbséget már írták: az egyik szerver-, a másik kliensoldalon tárolódik.
Session esetében a kliens egy speciális azonosítót kap, ez az ő session ID-je. Ha a kódodban elindítod a sessiont, akkor a $_SESSION tömb tartalma megmarad hívások közt, és ez egy megbízható tár, azaz a felhasználó nem tud belenyúlni.
A cookie-t elküldöd a kliensnek. Van rá méret- és darabszám-korlát, szóval csak korlátozott adatot tudsz így elrakni - ráadásul nagyon könnyen manipulálni tudja a felhasználó.
A session_destroy() a teljes tartalmát törli. A süti ott marad a kliensnél, amíg be nem zárja a böngészőt, de ez minket nem zavar - mindegy, hogy új látogató vagy törlés utáni, a rendszer szempontjából mindkettőnek üres a sessionje.
Utánaolvasásra érdemes kulcsszó: session fixation.
-
#8170
Tele von Zsinór
őstag
Bencom ™
#8166
Tele von Zsinór
őstag
válasz
Bencom ™
#8166
üzenetére
Csak erre az egyre válaszolnék, a többit kb. kimerítettük, és csak önmagunk ismételjük:
Nem akarom több szerverre szétosztani a játékot, úgy értem, ez nem ilyen "szigetek mindenütt, aztán harcolj az xy szerveren" dolog lenne
Az, hogy te egynek látod, nem jelenti, hogy valóban egy szerver, lásd google, facebook, avagy bármi komolyabb oldal. Kulcsszavak: replikáció, load balancing.
-
#8152
Tele von Zsinór
őstag
Louloudaki
#8145
Tele von Zsinór
őstag
válasz
Louloudaki
#8145
üzenetére
Mielőtt túllihegnéd: ne feledd, hogy mikor végez a scripted, úgyis felszabadul mind. Ráadásul sima webscripteknél nem a memóriaigény szokott a szűk keresztmetszet lenni.
-
#8143
Tele von Zsinór
őstag
Louloudaki
#8134
Tele von Zsinór
őstag
válasz
Louloudaki
#8134
üzenetére
Valahol 100 és 1.000 között, a pontos szám sokmindentől függ, többek közt: szerver hardvere, annak beállításai, opcode cache, mysql indexek - messzi nem teljes a lista.
Érezhető haszna egy script esetén nincs, a ritka kivételektől (nagy objektumok, amikre ez volt az egyetlen referencia) eltekintve, még ott sem biztos a dolog. Hacsak nem hosszú ideig fut a scripted (mert mondjuk valami háttérfeldolgozó cronból indítva) ne foglalkozz ilyennel.
-
#8132
Tele von Zsinór
őstag
Bencom ™
#8119
Tele von Zsinór
őstag
válasz
Bencom ™
#8119
üzenetére
Többszázezer felhasználó rengeteg. Már a százas-ezres határon mozgó szimultán felhasználószámnál problémáid lesznek és el kell kezdened beállítani több szervert, de ekkora számnál még ez sem lesz elég.
Ennyi felhasználónál nem ideális választás a php. Példaként hozom a facebookot: semmi realtime nincs benne, és a becslések szerint 30.000 szerverük van (HipHop előtti adat). Egész egyszerűen a php egy ilyen feladathoz lassú.
Jobb megoldás, amit többen felvetettek már, javaban / c++ban / bármi nem scriptnyelvben megírni a szerveroldali részét.
Semmiképpen nem egyemberes feladat egy ilyent összerakni, különösen nem, ha kezdő vagy. Mögöttem van már pár év tapasztalat, de nem állnék neki legalább 4-5 szakember nélkül.
-
#8117
Tele von Zsinór
őstag
Sk8erPeter
#8115
Tele von Zsinór
őstag
válasz
Sk8erPeter
#8115
üzenetére
David Soria Parra, core php fejlesztő (mármint nem php-ben, hanem a php-t), 5.4-esnek a release managere (és talán az 5.3-é is, ebben nem vagyok biztos).
Mellesleg ő a felelős a teljes php projekt kódjának svn-ről git-re portolásáért. -
#8085
Tele von Zsinór
őstag
Lacces
#8080
Tele von Zsinór
őstag
Kezdetnek Yii vagy Kohana - ezeket relatív egyszerű megtanulni, széleskörűen használtak, megfelelően dokumentáltak, és guglival is sok problémádra megoldást találsz.
Később, ha továbbra is webfejlesztőként tervezel előre, érdemes lehet legalább utánaolvasás szintjén megnézni az összetettebb rendszereket, gondolok itt a Symfony2-re és a Zend2-re (utóbbi még csak a béta-fázisnál tart).
Egyébként szabadidődben érdemes néha olvasgatni a választott rendszer kódját, problémamegoldáskor is jó, remek tanulási lehetőség, és szokod, hogy más által írt dolgot kell megértened.
-
#8029
Tele von Zsinór
őstag
wolandino
#8027
Tele von Zsinór
őstag
válasz
wolandino
#8027
üzenetére
Az, hogy az html, js és css fileokat érdemes különválasztani, nem kérdés.
Template-nyelv tekintetében nagyon megoszlanak a vélemények, az egyik oldal (jogosan) arra hivatkozik, hogy tkp. a php maga is egy template-motor, a másik oldal viszont nagyon okos kibővítéseket tud, és valóban nagyon tudja egyszerűsíteni a templateket (na meg a designernek sem kell megtanulni php-ul).
Kipróbáltam a smartyt (és nem többesszám, mint nálad), nem győzött meg.
Nagyon sokáig tiszta php-t használtam a templateimben, kis odafigyeléssel: nem nyúlok már adatbázishoz (ami kell, azt megkaptam a controller rétegtől), illetve vezérlési szerkezetekben az alternatív szintaktikát használtam.
Mostanában fedezem fel magamnak a twiget, nagyon tetszik, még meglátjuk, hosszútávon beválik-e. Persze sokat segít, hogy beépített támogatása van az általam használt keretrendszerben.
-
#8016
Tele von Zsinór
őstag
Lacces
#8015
Tele von Zsinór
őstag
-
#8011
Tele von Zsinór
őstag
mobal
#8009
Tele von Zsinór
őstag
Igen. Olvasd el például ezt a cikket: Using SSL Client Certificates with PHP
-
#8007
Tele von Zsinór
őstag
Lacces
#8005
Tele von Zsinór
őstag
Egyrészt amit a kollega mondott az error_reporting beállításáról (meg a notice-ok irtásáról), másrészt mégegy csomagtipp: php5-xdebug. Felrakod, apache-t újraindítod, más dolgod nincs is (azért phpinfo()-ban ellenőrizheted
).Az xdebug egy borzasztóan jó eszköz fejlesztés közben. Az egyik legalapabb dolog, hogy az el nem kapott exceptionök nem egy egysoros valamik lesznek, hanem egy szép, valamennyire formázott táblázat, amiben ott a stack trace is. Másrészt a var_dump kimenete is sokkal olvashatóbb lesz. De a kedvencem a debugger - én netbeans-zel használom, és működik, amit más (c++, delphi, c#, akármi) nyelvek IDE-jében megszokhattál: step-by-step debug, watch-ek és egyéb finomságok.
-
#7989
Tele von Zsinór
őstag
Lacces
#7987
Tele von Zsinór
őstag
phpmyadmin: http://localhost/phpmyadmin
Ennek működnie kell, ha nem teszi, valamit elrontottál. Ennek a csomagnak a telepítésekor rákérdez, akarod-e, hogy konfiguráljon webszervert, ott kiválasztottad, hogy igen, az apache-ot?
-
#7954
Tele von Zsinór
őstag
dodopek
#7953
Tele von Zsinór
őstag
válasz
dodopek
#7953
üzenetére
Az ereg_* függvények 5.3 óta elavultak (deprecated), erre kapsz figyelmeztetést. A vendégkönyved utolsó frissítése 2007-es, szóval ezt biztosan nem veszi figyelembe.
Ha komolyabb turkálás nélkül akarod megoldani, ezt add a vendégkönyv file tetejére:
error_reporting(error_reporting() & ~E_DEPRECATED);
ez kikapcsolja az ezekre vonatkozó figyelmeztetést. Egy ideig még megúszod így - a php motoron belül is van ereg függés, szóval legalább 5.5-ig marad még ez az ext.
-
#7934
Tele von Zsinór
őstag
Peter Kiss
#7926
Tele von Zsinór
őstag
válasz
Peter Kiss
#7926
üzenetére
Ami így kapásból eszembejut, az az új array syntax, a függvény visszatérési értékének kapásból tömbindexelése, vagy a lambda function-ök objecthez bindelése, osztály tagok példányosítás utáni azonnali elérése, beépített webszerver.
Nem feltétlen egy-egy cikkre gondoltam, hisz a többség apróság, pár példával elmagyarázható.
-
#7923
Tele von Zsinór
őstag
Peter Kiss
#7922
Tele von Zsinór
őstag
válasz
Peter Kiss
#7922
üzenetére
Korrekt leírás az 5.4 egyik legfontosabb újdonságáról, szép munka. A többiről is várható ilyen?
-
#7896
Tele von Zsinór
őstag
Louloudaki
#7895
Tele von Zsinór
őstag
válasz
Louloudaki
#7895
üzenetére
Igen. A protokolloknak az a lényege, hogy mindegy, miben készül a két oldal, együtt tudnak működni, amíg ugyanazt a nyelvet beszélik - jelen esetben a http-t.
-
#7878
Tele von Zsinór
őstag
wolandino
#7874
Tele von Zsinór
őstag
válasz
wolandino
#7874
üzenetére
Felhasználóbarát táblázatokhoz ezt szoktam használni: datatables.
Ez egy jquery plugin, táblázatot okosít rendezéssel, kereséssel, elég jól testreszabhatóan. Tudja azt is, hogy megkap minden rekordot és kliensoldalon lapoz/rendez/szűkít, illetve azt is, hogy ajax-szal ugyanezt a szerverre bízza.
-
#7846
Tele von Zsinór
őstag
dany27
#7843
Tele von Zsinór
őstag
Ha a $_GET tömbben nincs "del" index, akkor egy nemlétező változót próbálsz olvasni, ezért szól. Egyébként ez nem hiba, hanem csak egy E_NOTICE - arról megoszlanak a vélemények, hogy ezekre érdemes-e figyelni fejlesztés közben. Én azt vallom, hogy igen - elgépelt változónevek felderítésében például rengeteget segítenek.
Elkerülni így tudod:
if (isset($_GET["del"]) && $_GET["del"] == "yes") {}
ahol az isset() nem függvény, hanem egy speciális nyelvi konstrukció - így nem kapsz notice-t sem, mert a php lusta kiértékelést használ (logikai és-ek esetén megáll az első hamisnál).
-
#7801
Tele von Zsinór
őstag
Sk8erPeter
#7800
Tele von Zsinór
őstag
válasz
Sk8erPeter
#7800
üzenetére
Nem tartozik szorosan a témához, de kikívánkozik: igen, 2011-et írunk, a javascript alapkövetelmény egy modern oldalhoz. De! Nagyon sokan vannak (én is), akik biztonsági megfontolásból NoScriptet vagy hasonlót használnak, azaz whitelist alapján engedélyezik a js fileok futtatását - és a te domained valószínűleg nem lesz benne az első látogatáskor.
Az alapfunkcióknak menniük kell javascript nélkül is, a nagy kedvenceim az olyanok, ahol a less-ből css-be fordítást is kliensoldalon intézik, ergo nincs stíluslapja az oldalnak, amíg nem engedélyezem a javascriptet.
Szintén alap, hogy használjuk a noscript taget a felhasználó figyelmeztetésére, hogy ez-az nem fog működni. Még jobb, ha js nélkül nem is látja annak a funkciónak a kezelőszerveit (mert monjuk a tartalmazó divet is js-el állítjuk láthatóvá).
-
Tele von Zsinór
őstag
válasz
Brown ügynök
#7574
üzenetére
Részben igen, részben pedig mert ezek fejlesztői gépre kitalált csomagok, ennek megfelelő biztonsági beállításokkal. Persze ezt is meg lehet masszírozni, hogy jó legyen, de nekem eddig egyszerűbb volt kézzel összerakni a dolgokat.
-
#7572
Tele von Zsinór
őstag
Sk8erPeter
#7571
Tele von Zsinór
őstag
válasz
Sk8erPeter
#7571
üzenetére
Ahogy nézem, ez mind csak mysql-t tud, ő pedig mssql-t szeretne - ergo azzal mindenképp szívnia kell, amivel most.
Az pedig más kérdés, hogy éles szerverre ilyen előre összerakott csomagot én biztos nem raknék.
-
#7568
Tele von Zsinór
őstag
D@ni88
#7565
Tele von Zsinór
őstag
Kezdetnek kapcsold be a hibák kijelzését, és akkor nem üres fehér oldal lesz, hanem hibaüzenet. Alternatívaként nézd az error logot.
PHP5 óta a konstruktor nem az osztály nevével egyező nevű függvény, hanem a __construct függvény.
Nem szép az a $_GET ott (ahogy már megjegyezte egy kollega), helyette használj inkább paraméterátadást - a konstruktor is csak egy függvény.
-
#7326
Tele von Zsinór
őstag
mobal
#7323
Tele von Zsinór
őstag
Úgy tervezed, hogy csak a te gépeden fog működni az oldal? Bár ez a link akkor sem jó, hiányzik az elejéről a protokoll, jelen esetben a file://, és még egy harmadik /, hogy a gyökértől induljunk.
Ellenben ha úgy tervezed, hogy más gépen (pláne más szerverről) is működjön helyesen, akkor az aktuális helyhez relatív útvonallal jársz legjobban, alternatíva a szerver documentrootjától egy abszolút elérés.
-
#7190
Tele von Zsinór
őstag
mobal
#7188
Tele von Zsinór
őstag
Nem kell megadni a teljes útvonalat, relatívval is remekül működik.
Alternatíva lehet egy autoloader használata, lásd a slp_autoload_register() függvényt.
-
Tele von Zsinór
őstag
válasz
Brown ügynök
#7163
üzenetére
Próbáld meg abszolút úttal: dirname(__FILE__) . "/../data".
Ha így sem, akkor amit fentebb mondtak, open_basedir vagy safe_mode lehet bekapcsolva.
-
Tele von Zsinór
őstag
válasz
Brown ügynök
#7160
üzenetére
A következőre gondoltam: tegyük fel, hogy a webrootod a /var/www/example.com/public_html mappa. Ekkor berakod a pdf-et mondjuk a /var/www/example.com/data mappába (amit ugye nem lehet elérni kívülről), majd amikor meghívják a scripted, ellenőrzöd a jogosultságot, és ha minden stimmel, akkor:
1. ha a fileok alapvetően kicsik (legfeljebb pár MB), akkor readfile, fpassthru vagy valami hasonlóval átadod a felhasználónak
2. ha a fileok alapvetően nagyok (pár MB felett), akkor a mod_xsend-del küldöd el
-
Tele von Zsinór
őstag
válasz
Brown ügynök
#7157
üzenetére
Tedd ki a wwwroot-on kívülre, hogy csak a te scripteden keresztül lehessen hozzáférni.
-
#7152
Tele von Zsinór
őstag
Vesztor87
#7149
Tele von Zsinór
őstag
válasz
Vesztor87
#7149
üzenetére
Arról nem is beszélve, hogy a forráskódban (amit meg tud nézni a user) ott a jelszó. Szóval a javascriptes (kliensoldali) védelem egy egységsugarúnál picivel okosabb userrel szemben semmit nem ér.
Vannak jó leírások a .htaccess-.htpasswd duóval való védelemre, ilyet keress. Bár nem ismerem a chellohoz adott tárhelyet, ezt a legtöbb helyen lehet használni (és szerveroldali programozáshoz sem kell hozzá érteni).
-
#7084
Tele von Zsinór
őstag
Speeedfire
#7083
Tele von Zsinór
őstag
válasz
Speeedfire
#7083
üzenetére
Adatbázisban tábla.
-
Tele von Zsinór
őstag
válasz
Brown ügynök
#6948
üzenetére
A user-agentnek és a sessionid-nek is egyezni kéne hozzá, ez esélytelen
-
Tele von Zsinór
őstag
válasz
Brown ügynök
#6946
üzenetére
Felesleges ennyi mindent vizsgálni, és a jelszót miért mented?
Én bejelentkezéskor beállítom az is_authenticated kulcsot, később ezt vizsgálom, kijelentkezéskor pedig unsetelem.
Az ip-t vizsgálva problémákba ütközhetsz, amikor több user van egy ip mögött, és változik az ip requestről requestre (koli, céges környezet, ilyesmik). Vizsgáld inkább a user-agent értéket az első kéréskor kapotthoz, ennek nem kéne változni egy session alatt.
-
Tele von Zsinór
őstag
válasz
Brown ügynök
#6852
üzenetére
Tűzfaladra nézz rá, engedi-e az apache-nak a 8080-on hallgatást.
-
#6823
Tele von Zsinór
őstag
Speeedfire
#6822
Tele von Zsinór
őstag
válasz
Speeedfire
#6822
üzenetére
Próbáld meg a parancsikonban a working directoryt átírni, régebben ez segített, most meg nem tudom tesztelni.
-
#6821
Tele von Zsinór
őstag
Speeedfire
#6815
Tele von Zsinór
őstag
válasz
Speeedfire
#6815
üzenetére
Mire gondolsz? 7.0-át használok, a projekt mappa pedig egy nbprojekt n. mappa az adott meló helyén.
-
#6744
Tele von Zsinór
őstag
Sk8erPeter
#6743
Tele von Zsinór
őstag
válasz
Sk8erPeter
#6743
üzenetére
Nézd meg ezt is: phpThumb
Kb. egy éve használtam egy projekten, átméretezésre és vízjelezésre, tette a dolgát szívás nélkül. Cachelni is tud. -
#6739
Tele von Zsinór
őstag
Inv1sus
#6738
Tele von Zsinór
őstag
válasz
Inv1sus
#6738
üzenetére
Nem olyan bonyolult az. Ajánlott megnézni a FireXPath ff. kiegészítőt (vagy más böngészőre alternatíváját), gyorsabban össze lehet vele rakni egy queryt, mint ha php-ban próbálkozol.
A submitolásra: nézd meg, az oldalon a form mit, milyen néven és hová küld. Ha nincs benne olyan hidden input, ami valamilyen csrf-védelmet lát el, probléma nélkül tudsz postolni a php kódodból is - csak le kell másolni azt, ahogy a form küldené az adatokat. Ha van token, akkor +1 kérés, és a session cookie-ra is oda kell figyelmed, de nagy valószínűséggel így is megúszod csak szerveroldalon.
-
#6728
Tele von Zsinór
őstag
Alukard
#6727
-
#6723
Tele von Zsinór
őstag
D@ni88
#6722
Tele von Zsinór
őstag
Azt tudod, hogy ezt a kliens adja, és könnyű hamisítani, illetve azonos filetípusra is potenciálisan mást kapsz?
Másrészt egyszerűbb lenne a logikád, ha lenne egy tömböt az elfogadott típusokkal, és in_array() függvénnyel nézdnéd, a kapott file típusa benne van-e ebben. Egyszerűbb karbantartani, mint egy hatalmas ifet.
-
Tele von Zsinór
őstag
válasz
fordfairlane
#6706
üzenetére
Csak az sf1-el van tapasztalatom, de szerintem simán megoldható a fokozatos átállás - bár ez függ a régi oldal felépítésétől is. A default redirect rule-ok úgy vannak összerakva, hogy ha amúgy nem létező filet kérsz, akkor megy a front controllernek a kérés, amúgy kiszolgálja amazt (lásd például a képeket, css-eket).
Ha a régi oldalad úgy működött, hogy minden file egy-egy belépési pont volt, akkor elkezded átírni fokozatosan, a régi fileokat törlöd, és máris a sf kapja meg a kérést és tudja feldolgozni. Ha elég perverz vagy, úgy rakod össze a route-jaid, hogy pontosan ugyanaz legyen az új url, mint a régi
-
#6702
Tele von Zsinór
őstag
D@ni88
#6701
-
#6698
Tele von Zsinór
őstag
Alukard
#6697
-
#6677
Tele von Zsinór
őstag
D@ni88
#6676
Tele von Zsinór
őstag
-
Tele von Zsinór
őstag
válasz
fordfairlane
#6623
üzenetére
A notice az egyetlen dolog, ami jelzi: elgépeltél egy változónevet, tömbindexet, stb. Igenis legyen E_ALL|E_STRICT, csak prod környezetben nem kiiratva, hanem logolva és fejlesztőnek automatikusan küldve.
Inkább írok issetet n+1 alkalommal, mint egyszer kelljen keresnem egy ilyen elgépelést.
-
#6578
Tele von Zsinór
őstag
klinnsy
#6575
Tele von Zsinór
őstag
válasz
klinnsy
#6575
üzenetére
Első ránézésre mondom, hogy ez régi és rosszul megírt kód. A $HTTP_{GET,POST}_VARS változók még a nagyon régi időkben működtek, kompatibilitási okokból 5.2-ben még lehetett engedélyezni a létrehozásuk, 5.3-ban nem tudom, léteznek-e egyáltalán. Ezek extractolása csak súlyosbítja a dolgot. A file írás-olvasás miatt meg csúnya deadlockba futhat a kód, vagy az egyik process felülírhatja a másik változtatásait.
Ahogy fentebb a kollega úr mondja, az a minimum, hogy formázott kódot postolsz ide, de ekkorát már inkább külső oldalra (mondjuk pastebin.com) és linkeld - ott még syntax highlight is van.
Gyorssegítségként a hosszú változók engedélyezése esetleg megoldja a gondod, de jobban jársz, ha újraírod.
4.4, atyaég, ennyire régi kódot használnak még, hogy az kell neki?
Új hozzászólás Aktív témák
- Azonnali alaplapos kérdések órája
- Elektromos autók - motorok
- Házimozi haladó szinten
- PlayStation 5
- Tőzsde és gazdaság
- Call of Duty: Black Ops 7
- Jövőre jósolják a memóriahiányt, ami egy évtizedig is fennmaradhat?
- BestBuy topik
- Wise (ex-TransferWise)
- Samsung Galaxy S23 Ultra - non plus ultra
- További aktív témák...
- HIBÁTLAN iPhone 15 Pro Max 256GB Black Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3004
- 18 éve! Billentyűzet magyarítás magyarosítás. Festés vagy lézerezés és egyebek! 3 lehetőség is van.
- Dell Latitude 5410 i5 10310U, 16GB RAM, SSD, jó akku, EU bill., számla, 6 hó gar
- AKCIÓ! Dell Latitude 5550 notebook - Intel Ultra 7 165U 16GB DDR5 RAM 1TB SSD Intel Graphics WIN11
- DELL WD19S dokkoló + 130W töltő
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest