- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- sziku69: Szólánc.
- Flashback: Építsünk PC-t akciós alkatrészekből, lassan. upd: 05.28
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bambano: Bambanő háza tája
- Parci: Milyen mosógépet vegyek?
- Luck Dragon: Asszociációs játék. :)
- vrob: Az IBM PC és a játékok a 80-as években
- Gurulunk, WAZE?!
Új hozzászólás Aktív témák
-
#17023
supercow
őstag
tothjozsi96
#17022
supercow
őstag
válasz
tothjozsi96
#17022
üzenetére
külső time szerverről szedj időt, azt tárold el a helyi timstamp helyett pl ilyesmivel. A rendszergazda meg rakjon be cron-ba time frissítést..
-
#17016
Sk8erPeter
nagyúr
tothjozsi96
#17015
Sk8erPeter
nagyúr
válasz
tothjozsi96
#17015
üzenetére
Sejtettem, hogy ilyesmi lesz...
-
#17014
Sk8erPeter
nagyúr
tothjozsi96
#17013
Sk8erPeter
nagyúr
válasz
tothjozsi96
#17013
üzenetére
Ennek egészen biztos, hogy SEMMI köze nincs ahhoz, hogy miért kaptál eredményt mégis úgy, hogy állításod szerint üres volt az egész adatbázis (?? akkor milyen táblát kérdeztél volna le? Ha pedig a táblára gondoltál, hogy üres, akkor miért adott volna vissza találatot?!). Ezzel erőforrásokat szabadítasz fel, de a problémáid oka tuti nem ez volt, közben valami mást is babrálhattál.
-
#17011
Sk8erPeter
nagyúr
tothjozsi96
#17009
Sk8erPeter
nagyúr
válasz
tothjozsi96
#17009
üzenetére
Pedig akkor egészen biztos, hogy valami nem stimmel. Mutass komplett kódot, amivel csinálod.
(#17010) Flashback:
Első körben próbáld meg azt, hogy még a <!DOCTYPE elé rakd be az említett sort (igen, ott van a meta tagben, de nem biztos, hogy elég):
<?php header('Content-Type: text/html; charset=utf-8'); ?>
<!DOCTYPE ...
(nyilván az alsó sor nélkül, csak hogy egyértelmű legyen)
Egyébként mivel gyaníthatóan most alakítod ki az oldalt, lehetőleg ne XHTML 1.0 Strict legyen, hanem HTML5-ös, van jópár igen hasznos feature, amit így kihasználhatsz (az mellékes, hogy a böngésző sokszor engedékeny, és más doctype ellenére is esetleg használhatsz HTML5-től létező dolgokat, de legyen szabályos). Az meg csak annyiból áll, hogy a szokásos tagek elé a
<!DOCTYPE html>
deklarációt rakod, és máris HTML5-ös a doksid. (Az xmlns és xml:lang attribútum ennek megfelelően itt már nem szükséges, csak XHTML-nél.) -
#17008
fordfairlane
veterán
tothjozsi96
#17006
fordfairlane
veterán
válasz
tothjozsi96
#17006
üzenetére
Skacok, tegnap is volt itt egy olyan mélységű probléma, hogy egy if az else ágra futott, pedig nem arra kellett volna futnia, nahát. Nem ismeritek az alapvető debuggolási módszereket?
-
#17007
Sk8erPeter
nagyúr
tothjozsi96
#17006
Sk8erPeter
nagyúr
válasz
tothjozsi96
#17006
üzenetére
COUNT-tal könnyen tudod ellenőrizni, hány rekord van, ami a feltételeknek megfelel:
$stmt = $mysqli->prepare('SELECT COUNT(*) FROM users WHERE username = ? OR email = ?');
$stmt->bind_param('ss', $username, $email);
$stmt->execute();
// a $numberOfUsers változó fogja tárolni a prepared statement eredményét a fetch után
$stmt->bind_result($numberOfUsers);
$stmt->fetch();
if($numberOfUsers > 0) {
// para, van már ilyen felhasználó, tehát nem regisztrálhat ezekkel az adatokkal
// kivételdobás, stb.
}
// egyébként mehet tovább...Ja, még annyi, hogy a die() létezését inkább felejtsd el, dobj kivételt, kezeld is le valahol tisztességesen, stb.
-
#17004
Sk8erPeter
nagyúr
tothjozsi96
#17002
Sk8erPeter
nagyúr
válasz
tothjozsi96
#17002
üzenetére
Na ne. Ezek szerint amikor feltöltesz egy felhasználót, akkor UTÓLAG ellenőrzöd, hogy duplicate key hibára hivatkozik-e (mivel az az 1062-es), nem is ellenőrzöd még feltöltés ELŐTT, hogy van-e már olyan felhasználó? Még beszúrás előtt ellenőrizz minden szükséges adatot, ne a beszúrási kísérlet után...
Kb. így kéne kinéznie a folyamatnak: felhasználó elküldi az űrlapot » formvalidálás: egyáltalán jók a bevitt adatok, nem tartalmaznak nem elfogadott karaktert, ilyesmik? » van már ilyen felhasználó? » ha igen, hibaüzenetet mutatunk; ha nem, beszúrjuk, sikerre utaló üzenetet írunk ki.
Nem pedig úgy, hogy beszúrjuk, és az arra kapott esetleges hibaüzenetből derítjük ki, hogy volt már olyan felhasználó...Amúgy mysqli vagy PDO?
http://php.net/manual/en/mysqli.errno.php
http://php.net/manual/en/pdo.errorcode.php
http://php.net/manual/en/pdostatement.errorcode.php
PDO-t viszont egyszerűbb/szebb úgy beállítani, hogy dobjon exceptiont, ha probléma volt a lekérdezéssel. -
#16990
DNReNTi
őstag
tothjozsi96
#16984
DNReNTi
őstag
válasz
tothjozsi96
#16984
üzenetére
"nem tudom mi a problémád azzal ha .txt fájlban van számolva hogy mennyiszer töltötték le"
Teszem azt van 800.000 letölthető fájlod. Szép kis fájlrendszer lesz szövegfájlokban vezetve melyik hányszor lett töltve. Arról nem is beszélve: rendezd már növekvő/csökkenő sorba. Egy szóval tudnám a legjobban összefoglalni: adatbázis.
-
#16989
Sk8erPeter
nagyúr
tothjozsi96
#16982
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16982
üzenetére
"Lenne egy olyan kérdésem hogy adott egy letöltés számláló."
Igen. -
#16988
PumpkinSeed
addikt
tothjozsi96
#16987
PumpkinSeed
addikt
válasz
tothjozsi96
#16987
üzenetére
Igen, de lehet, hogy a magánember egy kollégiumban lakik.
-
#16986
PumpkinSeed
addikt
tothjozsi96
#16985
PumpkinSeed
addikt
válasz
tothjozsi96
#16985
üzenetére
Csak van, hogy egy IP címet egy intézmény használ és akkor máris elesel pár 100 letöltéstől.
-
#16985
tothjozsi96
addikt
tothjozsi96
#16984
tothjozsi96
addikt
válasz
tothjozsi96
#16984
üzenetére
Amúgy most eszembe jutott még egy dolog aminek lehet értelme.
Hogy 1 IP címről csak 1x számolja a letöltést és akkor elkerülhetők a félreértések. -
#16983
DNReNTi
őstag
tothjozsi96
#16982
DNReNTi
őstag
válasz
tothjozsi96
#16982
üzenetére
"A chrome-nál automatán elindul a letöltés."
Nem. Csak ha úgy van beállítva. Default, így van."Egy txt fájlban van mentve hogy eddig hányan töltötték le."
Ha már úgyis Karácsony: Jesus fuckin' Christ.Egyébként:
Szerver oldalon nem fogod tudni, hogy végül a fájlnak mi lett a sorsa. -
#16746
biker
nagyúr
tothjozsi96
#16744
biker
nagyúr
válasz
tothjozsi96
#16744
üzenetére
én payu-val csinálam ilyet, igen, ipn visszatérő üzenettel lehet igazolni hogy levonták a pénzt
-
#16745
Peter Kiss
őstag
tothjozsi96
#16744
Peter Kiss
őstag
válasz
tothjozsi96
#16744
üzenetére
Én nem, de szerintem Instant Payment Notification kell neked.
-
#16722
Speeedfire
félisten
tothjozsi96
#16718
Speeedfire
félisten
válasz
tothjozsi96
#16718
üzenetére
Én készítenék erre egy kapcsolótáblát, ami össze van kötve a user-ekkel és csak update utasítás lenne. Az update-ben pedig aggregálnád a felhasználókat egy ROW_NUMBER() függvénnyel (nem tudom mi a mysql megfelelője).
-
#16720
DNReNTi
őstag
tothjozsi96
#16718
DNReNTi
őstag
válasz
tothjozsi96
#16718
üzenetére
Szerintem ez ebben a formában mindenhogy dara.
Az én javaslatom inkább egy pontrendszer, ami alapján sorrendet állíthatsz fel a felhasználókból egyetlen lekérdezéssel: Magyarul lenne egy mező a felhasználók táblában, amely különböző interakciók hatására növekedne, esetleg csökkenne is. Regisztrációtól eltelt időt lehetne CRON-nal vezetni, a többi részletkérdés. Így megoszlana a "sorbarendezés" feladat. Amikor pedig arra vagy kíváncsi ki a top X db felhasználó, csak a pontok alapján rendezve lekérded a táblát. Ez így nem dara.
-
#16719
Peter Kiss
őstag
tothjozsi96
#16718
Peter Kiss
őstag
válasz
tothjozsi96
#16718
üzenetére
Készíts tárolt eljárást.
-
#16678
DNReNTi
őstag
tothjozsi96
#16677
DNReNTi
őstag
válasz
tothjozsi96
#16677
üzenetére
Dede, mindenki barátja tele van vele.
-
#16675
DNReNTi
őstag
tothjozsi96
#16674
DNReNTi
őstag
válasz
tothjozsi96
#16674
üzenetére
-
#16673
DNReNTi
őstag
tothjozsi96
#16672
DNReNTi
őstag
válasz
tothjozsi96
#16672
üzenetére
1. Miért követnél el ilyet?
2. Ez: $CURUSER["id"]; hogy?
3. Prepared Statements -
#16660
Sk8erPeter
nagyúr
tothjozsi96
#16649
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16649
üzenetére
"Én ezt ajánlom: [link]
Bocs, de engem rohadtul tud zavarni ha valaki nem használ ékezetet, vagy az hogy ilyeneket ír hogy "XD"."
Hú, hogy mennyire szívemből szóltál.
Ez az ikszdézés amúgy különösen rettentő retardált dolog, amikor ott vannak az előredefiniált smiley-k, ha nagyon akarja.![;]](//cdn.rios.hu/dl/s/v1.gif)
Mondjuk felőlem ikszdézhetne többet is, ha legalább tudna magyarul és értelmesen írni+fogalmazni.(#16657) tothjozsi96:
Igaz, hogy ez JavaScripthez kapcsolódik, de a különböző nyelvek (itt: HTML, CSS, JS) tényleges elválasztásáról szerintem egy nagyon jó link (amit még régen berakattam a JavaScript topic összefoglalójába is, hogy szem előtt legyen):
http://www.slideshare.net/fgalassi/refactoring-to-unobtrusive-javascript
Most nyilván egy PHP-kódot totálisan szétválasztani a generált HTML-kódtól igen nehéz lenne, és a template-ezéssel sincs szétválasztva, csak legalább kezelhetőbbé van téve a kód, nincs totális kutyulódás a kódban, így a logika elválik. A rétegezést nem véletlenül találták ki.(#16659) fordfairlane:
"Jó akkor úgy írom, hogy szétebbenválasztani. A nézetet széttebben szokták választani"
Azért ezek is szép magyar szavak.
-
#16659
fordfairlane
veterán
tothjozsi96
#16655
fordfairlane
veterán
válasz
tothjozsi96
#16655
üzenetére
Jó akkor úgy írom, hogy szétebbenválasztani. A nézetet széttebben szokták választani, neadjisten külön templatekbe teszik, hogy jól meg lehessen különböztetni az alkalmazás- vagy megjelenítási logika imperatív PHP kódrészét a megjelenítést szemantikusan deklaráló HTML résztől. És külön szokták rakni a stílusleíró CSS-t, az alkalmazás kliensoldali logikáját kezelő javascript kódot, stb, stb.. még akkor is, ha akár be is ágyazhatnák azt a HTML forrásba.
Alapvetően a különféle domain specifikus programnyelveket a fejlesztők általában igyekeznek egymástól elszeparálni.
-
#16658
DNReNTi
őstag
tothjozsi96
#16657
DNReNTi
őstag
válasz
tothjozsi96
#16657
üzenetére
fordfairlane leírta miért. Én meg írtam is egy halál egyszerű példát amiben tényleg külön van választva. Most lehet az én példám nem tűnik sokkal egyszerűbbnek a te példádnál, vagy attól amint PumpkinSeed írt de akkor képzeld el ezt a gyakorlatban, amikor mondjuk 600 sor HTML van a PHP darabkák között. Na azt olvassa ki valaki.
-
#16656
DNReNTi
őstag
tothjozsi96
#16655
DNReNTi
őstag
válasz
tothjozsi96
#16655
üzenetére
Magyarul: nem választja szét.
-
#16653
#81999360
törölt tag
tothjozsi96
#16649
#81999360
törölt tag
válasz
tothjozsi96
#16649
üzenetére
-
#16650
honda 1993
senior tag
tothjozsi96
#16649
honda 1993
senior tag
válasz
tothjozsi96
#16649
üzenetére
Most erre megis mit mondjak?
Mar tobben is b@szogattak amiatt hogy nem hasznalok ekezetet, es mondtam hogy ennek az az oka, hogy a billentyuzetem angol kiosztasu.
Ja, ez lemaradt : XD
-
#16623
CSorBA
őstag
tothjozsi96
#16612
CSorBA
őstag
válasz
tothjozsi96
#16612
üzenetére
Kezdjük ott megközelíteni a problémát, hogyha F5-öt nyomsz, akkor soha semmilyen tárolási (vagy törlési) műveletnek nem szabadna újra végrehajtódnia. Mondjuk legyen a kulcsszó: header location.
-
#16622
Sk8erPeter
nagyúr
tothjozsi96
#16619
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16619
üzenetére
"Nem szeretem a lekérdezéseket, az az igazság"
Akkor hagyd abba a webfejlesztés tanulását még most.(#16617) tothjozsi96:
EZ MI? (Szerk.: nehogy elkezdd magyarázni, tudom, mi ez a hibakód.)
Persze biztos ennél ocsmányabbul is megoldhattad volna, végül is jó úton jársz a spagettikód felé. Drukkolok, hátha lehet még rosszabb is. -
#16621
fordfairlane
veterán
tothjozsi96
#16614
fordfairlane
veterán
válasz
tothjozsi96
#16614
üzenetére
Értem, de nekem ez így elsőre eléggé furcsának tűnik.
Az is, de egyelőre fogadd el, hogy a sebesség miatt így van megoldva. (az átlapolódó konkurrens tranzakciókezelés gyorsítása miatt a memóriában tárolja az InnoDB az autoincrement számlálót, úgyseérted
).Először indíts egy tranzakciót, kérdezd le, hgy van-e olyan érték az adatbázisban, és ha nincs, akkor hajtsd végre az INSERT-et. Majd tranzakció kommit.
-
#16620
Zedz
addikt
tothjozsi96
#16619
Zedz
addikt
válasz
tothjozsi96
#16619
üzenetére
Pedig ha adatbázisokkal foglalkozol akkor meg kellene velük barátkoznod.
-
#16618
biker
nagyúr
tothjozsi96
#16617
biker
nagyúr
válasz
tothjozsi96
#16617
üzenetére
otthon is előbb lerugod az ajtót, megnézni, zárva van-e, utána veszed elő a kulcsot, gondolom
Mert ez egy kicsit ilyen -
#16616
Sk8erPeter
nagyúr
tothjozsi96
#16612
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16612
üzenetére
Miért nem ellenőrzöd először még beszúrási kísérlet előtt, hogy van-e már ilyen felhasználó?
Szerk.: ja, látom (#16615) PumpkinSeed ugyanezt írja. -
#16615
PumpkinSeed
addikt
tothjozsi96
#16612
PumpkinSeed
addikt
válasz
tothjozsi96
#16612
üzenetére
Én úgy csinálnám, hogy egy SELECT-el megnézem, hogy van-e ilyen, ha nincs azaz a lekérdezés eredménye egy nagy semmi akkor mehet, ha nem akkor error.
Mindezek után mikor már biztos vagyok benne, hogy nincs és nem is lehet azonos név akkor nyúlok csak az inserthez. -
#16613
Peter Kiss
őstag
tothjozsi96
#16612
Peter Kiss
őstag
válasz
tothjozsi96
#16612
üzenetére
Az autom increment így működik. Megpróbálja az INSERT-et, de elhal menet közben.
Képzeld el, hogy összevissza adná az SQL szerver az egyedi azonosítókat, előbb vagy utóbb ütközés lenne, így az egyszer lefoglalt azonosítót újra már nem adja ki.
---
Ehhez hasonlók a trading alkalmazások: mielőtt elindítasz egy akciót, kérsz egy sor azonosítót (pl. egy 100-as batch.et), amivel tudod magad, illetve az akcióidat azonosítani a trader felé. Ott mekkora kavar lenne?
-
#16601
DNReNTi
őstag
tothjozsi96
#16598
DNReNTi
őstag
válasz
tothjozsi96
#16598
üzenetére
Oszt mér' nem készítesz az oldal arculatával megegyező hibaoldal(aka)t? Szvsz elég prosztó megoldás a die()
-
#16599
Peter Kiss
őstag
tothjozsi96
#16598
Peter Kiss
őstag
válasz
tothjozsi96
#16598
üzenetére
Ez nem header, hanem egy HTML meta tag: <meta charset="utf-8">
Ha a feldolgozás előtt (még mielőtt bármi történne az alkalmazásban) meghívod ezt, akkor nem lesz gond:
header('Content-Type: text/html; charset=utf-8');Ezzel tényleg HTTP header-t küldesz ki.
-
#16596
DNReNTi
őstag
tothjozsi96
#16594
DNReNTi
őstag
válasz
tothjozsi96
#16594
üzenetére
Mint ahogy már előttem Zedz leírta, minden mezőt ellenőrizni kell szerver oldalon.
"Szerintem ez így célszerűbb, mert ha valaki inject-el, akkor itt már elbukik, vélemény?"
Mán úgy érted SQL Injection? Prepared Statements?(#16593) CSorBA
Remélem. Olyan jól fogalmaz. -
#16595
Zedz
addikt
tothjozsi96
#16594
Zedz
addikt
válasz
tothjozsi96
#16594
üzenetére
Minden beviteli mezőt védj le. Lehetőleg kliens oldalon is, a szerver szerintem kötelező.
-
#16562
Sk8erPeter
nagyúr
tothjozsi96
#16561
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16561
üzenetére
"Kiírattam a takelogin-ban és nyomtam egy CTRL+A-t, és beraktam egy Notepad++-ba ami kiírja hogy hány chars pontosan."
Atyaég... stringhossz-visszaadó függvényekről hallottál már?
-
#16560
Sk8erPeter
nagyúr
tothjozsi96
#16559
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16559
üzenetére
Jó, és mivel ellenőrizted, hogy valóban 63 karakter lett?
Mikor lett annyi, adatbázisba való feltöltés után, vagy még az alkalmazás "szintjén"? Az a baj, hogy csomószor harapófogóval kell kiszedni belőled az érdemi, nem mellébeszélő infókat, még sokszor így sem sikerül, és így az embernek csomószor elmegy a kedve a segítéstől. -
#16558
Sk8erPeter
nagyúr
tothjozsi96
#16556
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16556
üzenetére
"Így írtam bele.
echo password_hash($_POST["password"], PASSWORD_DEFAULT);
Alapból így van megadva amúgy:
$password = !empty($_POST["password"]) ? $_POST["password"] : '';
Azt hittem hogy valami baja lesz az empty-vel, de nem ..."
Már kapásból ennek a pár sorodnak sincs értelme. Ellenőrzöd a kulcs meglétét, átadod a tömbben ezalatt található értéket egy változónak, csak azt a változót ($password) nem használod fel a password_hash()-nél... ezért mondom, hogy ember legyen a talpán, aki érti a gondolatmenetedet. Egyébként meg nyilván ellenőrizni kell egy kulcs/változó meglétét, mielőtt felhasználod, nem tudom, mit kell csodálkozni az Undefined index-szel kapcsolatos Notice-on. -
#16555
Sk8erPeter
nagyúr
tothjozsi96
#16552
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16552
üzenetére
"Nem tudom mi folyik itt."
Igazából ebből a leírásodból ember legyen a talpán, aki megérti, miről beszélsz, hogyan is tesztelted, úgyhogy mi sem tudjuk, mi folyik nálad. 
==========================
(#16554) mrpiko :
Egy ilyen igénytelenül összeb@szott "álláshirdetésre" ne várd, hogy értelmes ember jelentkezzen. Nem túl jó ómen, ha még egy becsábító üzenet megfogalmazásába sem vagy hajlandó fektetni 30 másodpercnél többet, és még egy vesszőt sem vagy képes használni a tagmondataid elválasztásához. -
#16553
PumpkinSeed
addikt
tothjozsi96
#16552
PumpkinSeed
addikt
válasz
tothjozsi96
#16552
üzenetére
Simple Text a legbiztonságosabb.
-
#16551
PumpkinSeed
addikt
tothjozsi96
#16543
PumpkinSeed
addikt
válasz
tothjozsi96
#16543
üzenetére
Mintha itt találtam volna egy leírást arról, hogy nem nagyon szabad így megoldani. Viszont hash+besózás egy jó megoldás szerintem, vagy legalábbis amiket én eddig olvastam.
Majd a user által megadott jelszót is ugyanezzel a módszerrel és megnézed, hogy a user által megadott és a db-ben lévő változat egyezik-e, ha igen akkor kap egy kekszet a felhasználó.
-
#16547
Peter Kiss
őstag
tothjozsi96
#16545
Peter Kiss
őstag
válasz
tothjozsi96
#16545
üzenetére
Elmondom, hogy a dupla hash csak kárt okoz, erre megint ráküldene egy MD5-öt.
@biker
"password_hash() is simple crypt() wrapper" -
#16546
biker
nagyúr
tothjozsi96
#16545
biker
nagyúr
válasz
tothjozsi96
#16545
üzenetére
crypt() + salt, vagy password_hash() ?
-
#16544
Peter Kiss
őstag
tothjozsi96
#16543
Peter Kiss
őstag
válasz
tothjozsi96
#16543
üzenetére
Ez nem titkosítás, hanem hash-elés.
Azzal, hogy ráküldöd az sha1-re még az md5-öt, sikerült csökkentened a lehetséges jelszóvariánsok számát brute force esetén.
Megoldás: PHP Manual > Function Reference > Cryptography Extensions > Password Hashing
(password_compat, ha kellene)
-
#16542
Peter Kiss
őstag
tothjozsi96
#16541
Peter Kiss
őstag
válasz
tothjozsi96
#16541
üzenetére
Nem kell logolni semmit. In memory intéződik minden, tiltani meg tűzfalból kell hosszútávon.
-
#16537
Zedz
addikt
tothjozsi96
#16533
Zedz
addikt
válasz
tothjozsi96
#16533
üzenetére
De a végrehajtott fájlt is le kell kérni nem?
Tehát ott is a szerver válaszolgat... -
#16536
PumpkinSeed
addikt
tothjozsi96
#16528
PumpkinSeed
addikt
válasz
tothjozsi96
#16528
üzenetére
Én ezt talán úgy fogalmaznám át, hogy aki egyszer próbálkozott az kap egy ID-t session-ben vagy cookie-ban tárolva és az bizonyos ideig nem csinálhat semmit. Értem ezalatt a regisztrációt. Adsz neki 3 próbálkozási lehetőséget majd ha annyira béna, hogy ezután se tud regelni akkor lehet robot lesz, és ekkor megkínálod 2 perc tiltással, mely minden sikertelen cselekedet után hatványozódik.
-
#16535
wis
tag
tothjozsi96
#16533
wis
tag
válasz
tothjozsi96
#16533
üzenetére
Egy robot mindenre képes lehet amire egy böngésző is
-
#16532
DNReNTi
őstag
tothjozsi96
#16530
DNReNTi
őstag
válasz
tothjozsi96
#16530
üzenetére
Szerintem egyszerűbb megnézni a végrehajtóban, hogy a http request post e. Ha nem az, viszlát.
-
#16531
Zedz
addikt
tothjozsi96
#16530
Zedz
addikt
válasz
tothjozsi96
#16530
üzenetére
Itt nem csak azzal van a baj, hogy 1 fájlt támadnak. Hanem a folyamatos lekérés a szervertől. Pl. ddos támadást ismered?
-
#16529
DNReNTi
őstag
tothjozsi96
#16528
DNReNTi
őstag
válasz
tothjozsi96
#16528
üzenetére
És ez miért is akadályozna meg bárkit abban, hogy szétterhelje az oldalt? A robot is megkapja a uniqid()-t.
-
#16521
DNReNTi
őstag
tothjozsi96
#16520
DNReNTi
őstag
válasz
tothjozsi96
#16520
üzenetére
De most ha mondjuk 0.1 másodpercenként van egy üzenőfali bejegyzés, ami lássuk be elég aktív oldal lehet, akkor naponta, 864.000 db bejegyzés keletkezik. Legyen 1 millió, hogy könnyű legyen számolni. Ez az INT-et 4290 nap alatt, azaz majdnem 12 év alatt meríti ki, ilyen extrém használat mellett.
Wtf? -
#16519
DNReNTi
őstag
tothjozsi96
#16518
DNReNTi
őstag
válasz
tothjozsi96
#16518
üzenetére
"Láttam olyan oldalt ahol problémát okozott már az INT(10) is."
Az 4.2+ milliárd rekord. Milyen oldal lehet az ahol ez problémát okoz? igyelmen kívül hagyva természetesen az interneten belüli interneteket (Google, Facebook, és társaik.)Most remélem nem fogok hülyeséget írni, de: Egyébként az INT esetében a mező méretének definíciója teljesen felesleges, az INT ígyis úgyis 4 byte, azaz 4.2+ milliárd egyedi egész számot tárollhatsz így. A sima INT értéktartománya: -2147483648- tól 2147483648-ig terjed. Ha ID-hoz használod az INT típusú mezőt, akkor célszerű INT UNSIGNED-ként definiálni, így negatív értékek nincsenek, 0-tól 4294967295-ig mehetnek bele az értékek.
Ha ez sem elég, ott a BIGINT, 8 byte-on, UNSIGNED-nak definiálva 0-18446744073709551615 egész szám. Nem tudom elképzelni, hogy ez se lenne elég.
Hogy a többire is válaszoljak:
Teljesen projekt függő. E-mail címeknek én simán VARCHAR(255)-öt adnék. Vannak elég extrém címek. A többi rajtad múlik. Fontos viszont, hogy a beadott stringek hosszúságát ellenőrizd szerver oldalon, ne told bele a max 40 hosszú mezőbe a 120 hosszú stringet, mert így jársz. -
#16507
biker
nagyúr
tothjozsi96
#16502
biker
nagyúr
válasz
tothjozsi96
#16502
üzenetére
Most lehet páran nekem ugranak, vagy legalább elindul egy vita, de...
Az md5 NEM alkalmas jelszó titkosítására, mert nem titkosító eljárás. egy kód, ami 32 bit hosszú, akkor is, ha az input "a" vagy épp NULL, és 32 bit akkor is, ha egy 10GB-os image file ellenőrzőkóód generálás a feladat.
Ebből ered, hogy információt nem hordoz, és persze nem is visszafejthető, (de vannak md5/szó pár adatbázisok)
Ellenben kis valószínűséggel, de előfordul hogy két teljesen más karaktersornak ugyanaz lesz az md5 értéke.
A többit rád bízom, mit választasz -
#16504
DNReNTi
őstag
tothjozsi96
#16502
DNReNTi
őstag
válasz
tothjozsi96
#16502
üzenetére
A biztonságos beléptetés valamint főleg a felhasználói adatok biztonságos kezelése elég összetett dolog, írhatnék délig, mire leírom az egésszel kapcsolatban a véleményemet.
Mivel az idő az ellenségem, rövidre fogom. Ami már kiderült itt korábban is a felhasználói adatok sütiben tárolása a lehető legrosszabb megoldás, ha ráadásul még a jelszót is sütiben tárolod (ahogy korábban írtad) az pedig egyenesen kötél általi halált ér. Leírom az én alap megoldásom, aztán majd a többiek kijavítják vagy kiegészítik, szerintem ez egy weboldal esetén megfelelően biztonságos:
A felhasználók az alap adataikon kívül regisztrációkor kapnak egy mondjuk 20 számjegy hosszú unique random számsort, amely adatbázisban a felhasználó táblában van rögzítve. Amikor a felhasználó a felhasználónév és jelszó párossal helyesen belép, akkor a $_SESSION[] változóban eltárolom ezt a random azonosítót. Innentől a böngésző bezárásáig ez alapján azonosítom a felhasználót. A számsor unique, szóval ugyan úgy használhatom erre a célra mint mondjuk az id-t. Ha lehetőséget adsz arra, hogy a felhasználó belépve maradjon, akkor ezt a számsort nyugodtan tárolhatod sütiben is, így amikor a felhasználó újra meglátogatja az oldalt, a süti tartalmát beállítod a session változóba és minden megy tovább ahogy eddig. Kilépéskor a sütit "lejáratod" a sessiont unset()-eled.Miért számsor és nem string?
Mert az SQL lekérdezés gyorsabb számszerű ekvivalenciára mint szöveges egyezésre.Miért jó ez megoldás?
Mert ha még valaki, valahogyan hozzá is jutna, ehhez az azonosítóhoz (pl. a sütiból), abban semmilyen logikai minta nincs, ami alapján a többi felhasználó azonosítója megszerezhető lenne.Hogyan lehet ez még biztonságosabb?
Ennek a level 2 változata, ha random azonosítót minden belépéskor generálod és mented el a felhasználóhoz, ez viszont félmegoldás, mivel ha a felhasználó miközben be van lépve, belép egy másik eszközről, akkor az eredeti munkamentét el fogja veszíteni.Hogyan akadályozható ez meg?
Egyszerűen, level 2 helyett egyből a level 3-mal. Ugyan úgy egyedi azonosítót generálsz belépéskor, de ezt már nem a felhasználó táblában, hanem egy külön a belépéseket kezelő táblában rögzíted. Fontos, itt nem elég csak a random azonosítókat és a felhasználó id-kat tárolni, az egyértelmű azonosítás érdekében környezeti változók mentésére is szükség van. Kilépéskor a tárolt munkamenet célszerű az adatbázisból eldobni, így nem lesz tele szeméttel, továbbá érdemes időközönként háttérfolyamattal takarítani, teszem azt mondjuk a 48 óránál régebbi munkameneteket eldobni.Röviden ennyi.
Aki nem ért egyet pls javítson ki.
-
#16503
mobal
nagyúr
tothjozsi96
#16502
válasz
tothjozsi96
#16502
üzenetére
Mindenképpen session cookie.
-
#16501
DNReNTi
őstag
tothjozsi96
#16500
DNReNTi
őstag
válasz
tothjozsi96
#16500
üzenetére
A kérdésedben benne a válasz.
UTF8 a fájlod, erre beállítod hogy a böngésző ISO-8859-2 formátumként kezelje. -
moltam88
tag
válasz
tothjozsi96
#16497
üzenetére
isset() helyett !empty() -t használj. Az empty() true-t ad vissza, ha a változó nem létezik, vagy üres a tartalma (konkrétan false-al való egyezőséget vizsgál).
Bővebb leírás PHP.net-en.
-
#16496
DNReNTi
őstag
tothjozsi96
#16494
DNReNTi
őstag
válasz
tothjozsi96
#16494
üzenetére
Jaja, pontosan. Sot ha uberbiztonsagos akarsz lenni a loginok kezelesre kulon tablat hozol letre, nem pedig a felhasznalo tablajaban tarolod.
Ez mondjuk szvsz egy sima weboldal eseteben mar agyuval a verebre kategoria. -
#16495
wis
tag
tothjozsi96
#16492
wis
tag
válasz
tothjozsi96
#16492
üzenetére
Nem. Ne tárolj felhasználó adatokat cookie-ban semmilyen formában. Amennyiben szükséged van a felhasználó nevére vagy azonosítójára, azt rakd bele a $_SESSION tömbbe. Pl. $_SESSION['user_id'] = $user_id;
-
#16493
DNReNTi
őstag
tothjozsi96
#16492
DNReNTi
őstag
válasz
tothjozsi96
#16492
üzenetére
"Kérdés hogy SQL injektálás szempontból milyen lesz majd."
Wat?"nekem kettő dolog fő a tároláshoz, igazából az egyik a felhasználó ID-je a másik pedig a jelszava megkeverve valamivel"
Wat? Miért kellene ezeket tárolnod? Miért nem elég mondjuk egy minden helyes loginnál generált unique hash, amely alapján azonosíthatod a felhasználót, és 100% biztonságban csak szerver oldalon kezelnéd az id-t jelszót, stb-t? -
#16491
wis
tag
tothjozsi96
#16490
wis
tag
válasz
tothjozsi96
#16490
üzenetére
Ugyanolyan "biztonságos", hiszen ez a megoldás is cookie-t használ.
A kliens gépén az egyedi session azonosító tárolódik amit minden kéréskor elküld a szervernek.
Ehhez az azonosítóhoz szerver oldalon társíthatod azt az információt, hogy pl. be van-e lépve.Miért tárolnád a passhash-t cookie-ban? Milyen kulcsok működését nézted meg?
-
#16489
wis
tag
tothjozsi96
#16488
wis
tag
válasz
tothjozsi96
#16488
üzenetére
A PHP alapból tartalmaz session kezelőt, neked a session cookie-val nem kell foglalkoznod közvetlenül.
Próbáld ki a példákat és figyeld meg, hogy létrejön a böngészőben a PHPSESSID cookie.Ha szeretnéd, hogy a böngésző bezárása után törlődjön akkor a session_set_cookie_params függvényben az első paraméter legyen 0.
-
#16484
fordfairlane
veterán
tothjozsi96
#16483
fordfairlane
veterán
válasz
tothjozsi96
#16483
üzenetére
Bocs, de ez marhaság.
-
#16482
sztanozs
veterán
tothjozsi96
#16479
sztanozs
veterán
válasz
tothjozsi96
#16479
üzenetére
Valamint ha olyan dolgot szeretnél csinálni, ahol fontos az "egyedi" azonosítás, ott célszerű a session-t nem csak a session tickethez, hanem egyéb más tulajdonsághoz közni (pl ip cím), különben a cookie megszerzésével a belépő felhasználó más álltal megszemélyesíthető.
Kilépéskor a session változót invalidálni kell és mind kliens, mind szerver oldalon kötelezően le kell járani adott idejű inaktivitás után.Ja és akkor még szó sem esett a https-ről...
felhasználó id és md5 password tök fölösleges és veszélyes is - főleg ha nem secure cookie-ről van szó
-
#16481
fordfairlane
veterán
tothjozsi96
#16479
fordfairlane
veterán
válasz
tothjozsi96
#16479
üzenetére
Ha a felhasználó munkamenetével kapcsolatos adatokat akarsz tárolni, akkor az általánosan bevett megoldás az, hogy a kliensnél egy egyedi, véletlengenerált azonosítót tárolsz, pl. hash formájában, minden más adatot a szerveren. A hash azonosítja a klienst minden egyes requestnél, így a többi adat hozzárendelése szerveroldalon könnyedén megoldható. PHP-ban erre való a beépített session-kezelő.
-
#16480
DNReNTi
őstag
tothjozsi96
#16479
DNReNTi
őstag
válasz
tothjozsi96
#16479
üzenetére
Én felhasználó beléptetésre mindenképp a session-t javaslom. Ha pedig engedélyezed, az "emlékezz rám" (ne lépjek ki ha bezárom a böngészőt) funkciót, akkor a kettő kombinációja. Ez esetben jó egy unique hash sütiben ami alapján be tudod léptetni a felhasználót. Sütiket szerintem csak "nem globális" beállítások tárolására érdemes használni, pl mondjuk az előbb említett "emlékezz rám". Továbbá ne felejtsd el, hogy most már fel kell hívd a felhasználók figyelmét arra, hogy sütiket használsz, és mielőtt használod őket, ezt ők el kell fogadják.
-
#16465
Sk8erPeter
nagyúr
tothjozsi96
#16462
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16462
üzenetére
Nem fogsz tudni kitalálni jobb általánosan alkalmazható, bizonyos szabályokat megfogalmazni képes "egyedi kivitelezést". Azért ez nem egy triviális feladat. Maradj csak a könyvtári függvényeknél, vagy max. keress valami komplex library-t... Amúgy a javasolt strtr sem tudom, mitől lenne jelen esetben jobb, mint az str_replace...
Mellesleg a te esetedben pont nem az str_replace a probléma, ami a lassúságot okozza, hanem az iszonyat sok smiley és hozzá tartozó külön-külön reguláris kifejezés, preg_replace-szel annak illeszkedésére való keresgélés és csere... (Magyarul a preg_replace jobban lassít, mint az annál jóval egyszerűbb cserére alkalmas str_replace.)
De ezt már egyszer kifejtettem neked. Ismétlés a tudás anyja. -
#16464
DNReNTi
őstag
tothjozsi96
#16462
DNReNTi
őstag
válasz
tothjozsi96
#16462
üzenetére
Csak kíváncsiságból, pontosan mit jelent az, hogy lassú? Úgy értem mondjuk egy 3.000 karakter hosszú string-nél milyen eredmény jön most ki, és mi lenne elfogadható? Egyáltalán mifajta oldal / alkalmazás az, ahol ennyire számítanak a milisec-ek? Már korábban is írtad valamire, hogy lassú.
Egyébként minek 300 smile? Nem e elég mondjuk 20? (#16463) fordfairlane +1
-
#16463
fordfairlane
veterán
tothjozsi96
#16460
fordfairlane
veterán
válasz
tothjozsi96
#16460
üzenetére
-
#16461
Speeedfire
félisten
tothjozsi96
#16460
Speeedfire
félisten
válasz
tothjozsi96
#16460
üzenetére
Esetleg preg_replace ?
-
#16459
Peter Kiss
őstag
tothjozsi96
#16457
Peter Kiss
őstag
válasz
tothjozsi96
#16457
üzenetére
$szoveg .= $masikSzovegAVegere; //sima concat is megy nyilvan
$szoveg[$valahanyadikKarakter] = $kicserelemMasikra; //nem multi-byte safe
Mire kellene gondolni?
-
#16458
Sk8erPeter
nagyúr
tothjozsi96
#16457
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16457
üzenetére
"Lehet valahogy úgy átalakítani szöveget, tehát nem str_replace-el hanem ilyen fgv.-ek nélkül?"
Direkt idéztem a kérdésedet, csak hogy még egyszer lásd - szerinted mi értelme van ennek a kérdésnek? -
#16430
honda 1993
senior tag
tothjozsi96
#16428
honda 1993
senior tag
válasz
tothjozsi96
#16428
üzenetére
"Remélhetőleg tartalmaz ékezetet vagy valami ilyesmit?
Most nem értem, tehát tök egyszerű a használata.
Veled van a hiba, ez biztos."Tehat mar megint itt tartunk, hogy tok egyszeru, es megis csak ennyit kapok valaszkent, hogy (velem van a problema).
De mivel mindent reszletesen leirtam, (meg a hibauzenetet is bemasoltam, es csak annyit mondasz hogy "pedig ez tok egyszeru es veled van a baj") akkor azert felmerul a kerdes, hogy miert nem kapok toled erdemleges valaszt ?
Egyebkent nem tartalmaz semmi fele ekezetet.WWW mappban van egy valami mappa, ezen belul van az index.php.
Bongeszobe pedig beirom az alabbi szoveget : localhost/valami/index.php
probaltam mar igy is: localhost/www/valami/index.php es igysem tudtam mukodesre birni.
-
#16397
honda 1993
senior tag
tothjozsi96
#16396
honda 1993
senior tag
válasz
tothjozsi96
#16396
üzenetére
AAA. letoltottem egy masik verziot a xampp-bol,de nem mukodik a mySQL.
Veglegesen leirtam ezt a programot es inkabb megnezem a wampservert. -
#16392
honda 1993
senior tag
tothjozsi96
#16391
honda 1993
senior tag
válasz
tothjozsi96
#16391
üzenetére
Megprobalom a reinstallt.
Szerintetek az apache es a mySQL-en kivul nem erdemes semmi mast telepiteni ? -
#16390
honda 1993
senior tag
tothjozsi96
#16389
honda 1993
senior tag
válasz
tothjozsi96
#16389
üzenetére
Xampp-om van, es a vezerlopanelben leallitottam az apache-ot, aztan ujrainditottam.
[link]
Es jelenleg igy nez ki.De ha csak siman azt irom be hogy localhost, akkor pedig : It works! Tehat mukodik. ( ez nekem mar teljesen erthetetlen.)
Nincs olyan fajl.
-
#16388
honda 1993
senior tag
tothjozsi96
#16387
honda 1993
senior tag
válasz
tothjozsi96
#16387
üzenetére
Hat koszonom szepen,de azt en ebbol nem tudom megallapitani, hogy mettol-meddig kellene kicserelnem.
Hat, vagysi kicsereltem, de igy sem aka mukodni.
Ugy csinaltam hogy megnyitottam a fajlt a php storm-ban, toroltem az also reszt, es beillesztettem ezt.
De ugyan az a hibauzenet fogad. -
#16385
honda 1993
senior tag
tothjozsi96
#16384
honda 1993
senior tag
válasz
tothjozsi96
#16384
üzenetére
Bameeeg.
erre gondoltam en is hogy egyszeruen csak bemasolom,de azt gondoltam hogy nektek maga a fajl kell, es nem jo, ha csak siman bemasolom.De akkor ezzel az erovel ide is be tudom masolni . XD
[link] <--- Ez most egy gomb, nem kell bemasolni .
-
#16379
honda 1993
senior tag
tothjozsi96
#16378
honda 1993
senior tag
válasz
tothjozsi96
#16378
üzenetére
nem az a mappa neve hogy valami, csak nem akartam leirni hogy mi a neve annak a mappanak. XD
Tehat van a htdocs mappa, azon belul van egy mappa aminek a neve "valami" ( de nem ez az igazi neve ).
-
#16376
honda 1993
senior tag
tothjozsi96
#16375
honda 1993
senior tag
válasz
tothjozsi96
#16375
üzenetére
Rendben, felfogtam .
Bar sajnos annak ellenere hogy elmentettem .php-val, meg mindig az alabbi hibauzenetet kapom.Object not found!
The requested URL was not found on this server. If you entered the URL manually please check your spelling and try again.
If you think this is a server error, please contact the webmaster.
Error 404
localhost
Apache/2.4.10 (Win32) OpenSSL/1.0.1i PHP/5.5.15 -
#16364
honda 1993
senior tag
tothjozsi96
#16363
honda 1993
senior tag
válasz
tothjozsi96
#16363
üzenetére
XAMPP-ot hasznalok.
De a xampp-n belul nekem csak az Apache es a MySQL fut. Csak ezeket telepitettem amikor kerdezte hogy mik kellenek. ( a haverom mondta hogy csak erre a kettore lesz szugsegem). -
#16362
honda 1993
senior tag
tothjozsi96
#16361
honda 1993
senior tag
válasz
tothjozsi96
#16361
üzenetére
Az a baj hogy nalami nincs olyan mint a videoban.
megnyitottam azt a dokumentumot amit mutat, aztan en is legalul keresgeltem azt a reszt amit mutatott, de nekem nincs olyan. -
#16358
PumpkinSeed
addikt
tothjozsi96
#16357
PumpkinSeed
addikt
válasz
tothjozsi96
#16357
üzenetére
Inaktivitás esetén igen. Szerintem a 3 nap az túl sok.
-
#16335
PumpkinSeed
addikt
tothjozsi96
#16321
PumpkinSeed
addikt
válasz
tothjozsi96
#16321
üzenetére
Viszont jobban megnéztem az URL-t amit bead. Ha egy változóban letárolnám ezt: akkor hogyan tudnám ezt normális URL-é alakítani? Van erre valami függvény, vagy nekem kellene reguláris kifejezéssel megoldani?
-
#16333
wis
tag
tothjozsi96
#16323
wis
tag
válasz
tothjozsi96
#16323
üzenetére
A foreach felesleges, a smiley-t a strtr is kicseréli és biztosan gyorsabb lesz mint a regex.
-
#16327
Sk8erPeter
nagyúr
tothjozsi96
#16326
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16326
üzenetére
Mi az, hogy akkor mi van?
Mi köze a kettőnek egymáshoz? 
- egyrészt itt írtam már, hogy amúgy is érdemes a tisztításra valamilyen kész library-t használnod (mert most nem tisztogatod a feltöltött üzeneteket egyáltalán? Mert az ugyebár nem túl jó.)
- másrészt hogy jönnek ide a <script>-tagekben elhelyezett rondaságok, XSS ahhoz, hogy te :), :D és ehhez hasonló emoticonnak megfelelő karaktersorozatokat keresgélsz, majd átalakítod őket <img>-tagekké?
- harmadrészt amúgy is whitelist-jelleggel kellene csupán engedned bizonyos limitált tageket (vagy egyáltalán nem), aszerint szűrni (ez kapcsolódik az első ponthoz), na meg létezik strip_tags függvény is, aminek pont ilyen whitelistet megadhatsz (első, legegyszerűbb megközelítés, de mondom, a tisztításra amúgy is illene használnod valamilyen library-t (pl. HTML Purifier és hasonlók)). -
#16325
Sk8erPeter
nagyúr
tothjozsi96
#16323
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16323
üzenetére
Ezt már korábban írtam, de az, hogy minden egyes megjelenítésnél minden egyes üzeneten végigmész, és még azonbelül is iszonyatosan sok reguláris kifejezésre keresgélsz, teljesen érthető, hogy rohadt lassúvá teszi az egészet. A reguláris kifejezés keresgélése amúgy sem egy gyors állat. Lehet egyrészt egyszerűbbé is tenni magát a reguláris kifejezést is (bár elég bonyolult egyszerűvé tenni
), meg lehet csökkenteni is a keresendő kifejezések számát (nem biztos, hogy érdemes 314 emoticon használatát lehetővé tenni), illetve lehet javítani a használt módszeren is, erről is írtam már, hogy egyből feltöltéskor alakítanád át a smiley-kat <img>-tagekké, eleve úgy mentenéd el az üzenetet, így azért jópár lépést megspórolsz, nem kell állandóan, minden megjelenítésnél újból és újból kikeresgélni ezeket. Ez utóbbira még mindig nem reagáltál, pedig már legalább harmadjára írom le. Vagy legalább akkor írd le, az miért nem jó megoldás. (Lehet olyan eset simán, csak legalább tudjam, hogy eljutott hozzád az információ. ) -
#16322
Sk8erPeter
nagyúr
tothjozsi96
#16315
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16315
üzenetére
Van magyarra fordított PHP-doksi is:
http://szabilinux.hu/php/function.preg-quote.htmlAz a lényeg, hogy ha a stringed tartalmazhat olyan karaktereket (mint a dollárjel ($), csillag (*), pont (.), stb.), amelyek egy reguláris kifejezésben speciális jelentéssel bíró karakterként értelmezhetők lennének, akkor előtte ezeket egy backslash-sel (\) escape-elni kell (hogy ne rontson el pl. egy egyébként jól megírt reguláris kifejezést, hogy valamilyen substringben vannak "félreértelmezhető" karakterek); pont ezt csinálja ez a függvény.
Remélem, így nagyjából érthető.(#16311) :
Nem tudok ilyen egész konkrét doksit, de Dunát lehet velük rekeszteni, én annak idején össze-vissza gugliztam mindenféle regexpekkel kapcsolatos olvasmányért, és jó sok gyakorlás után ráállt az agyam. Tényleg nem egy kétperces valami, amit csak úgy megért az ember, rá kell állítani magadat, de ez nyilván nem csak úgy megy, ha sokat olvasgatsz (nyilván az se árt), hanem ha ki is próbálgatod egyesével a különböző eseteket. Voltak különböző feladatok, amikhez nagy hasznát tudtam venni a regexpeknek, így jó gyakorlati feladatok voltak.Nagyon sokat segít egyébként a RegexBuddy (elmagyarázza a reguláris kifejezést, nagyon hasznos!), a RegExr, Regex101, RegexPal, stb.
-
#16305
kenwood
veterán
tothjozsi96
#16291
kenwood
veterán
válasz
tothjozsi96
#16291
üzenetére
jol latom,hogy a $s valtozo elnevezes valami tutorialbol van ?
erosen kerulendo kategoria. -
#16297
Sk8erPeter
nagyúr
tothjozsi96
#16291
Sk8erPeter
nagyúr
válasz
tothjozsi96
#16291
üzenetére
Hát ja, sajnos nem meglepő, hogy rohadt lassú, mert tele van regexpekkel, egyenként újból és újból végigkotorássza a szöveget arra a kifejezésre, amelyik esetleg illeszkedik (mármint mindegyik regexpre külön-külön), stb., plusz elég karbantarthatatlan is a kód, mert nem valami tömbszerű megoldás van, vagy bármi általánosabb, hanem az str_replace-ekhez vagy épp preg_replace-ekhez be van drótozva stringként az adott smiley - ezenkívül belerak további lassításokat, ilyenekkel, hogy előbb preg_match-csel ellenőrzi, van-e illeszkedés, és AZUTÁN preg_replace-el. Szerintem keress valami jobb kódot/library-t, rengeteg szócikk van Stack Overflow-n. Hozzáteszem, ez a smiley-cserélős móka egyáltalán nem triviális probléma, nehéz általános megoldást írni rá szerintem, ami minden esetet lefed.
(#16281) tothjozsi96 :
"Próbáld meg kivenni a strlen-t, szerintem az lesz a baja ..."
Miért lenne már az strlen a baja?(#16292) Des1gnR :
Hibajelzés be van kapcsolva?
"Viszont ha oda illesztem be ezt a kis kódot ahová kellene, akkor nem hozza létre az XML-t"
És ennyi a hibajelenség, semmi több?
Amúgy mondom, nagyon gáz ez a megoldás, hogy a rendeles.php fájlodba be van okádva minden. Rakd már egy globális függvénybe legalább, amit include-olás (/require) után meghívsz, még az is jobb.
Amúgy ha már ilyen jellegű kódbeillesztés, akkor inkább require_once()-t használj, az garantáltan csak egyszer include-olja a kódot.A kódot sem ártana legalább nagyvonalakban ismernünk... (Nem kell az egész, csak legalább valami útmutatás, hogy mi történik a fájlodban.)
(#16293) tothjozsi96 :
"Az include("rendeles.php")-t próbáltad már?"
Ugye tudod, hogy mi a különbség a require() és az include() között? Semmit nem oldana meg lecserélni a require()-t include()-ra. Annyi különbség lenne, hogy abban az esetben, ha nem létezne a fájl, nem produkálna egy fatális hibát. -
#16296
Des1gnR
őstag
tothjozsi96
#16295
Des1gnR
őstag
válasz
tothjozsi96
#16295
üzenetére
Kiírnia nem is kell semmit.
Ha a meghiv.php-m így néz ki:
<?php
include 'rendeles.php';
?>
Akkor is létrejön az XML. -
#16294
Des1gnR
őstag
tothjozsi96
#16293
Des1gnR
őstag
válasz
tothjozsi96
#16293
üzenetére
Próbáltam, de nem változik semmi.
-
#16283
norby10
csendes tag
tothjozsi96
#16281
norby10
csendes tag
válasz
tothjozsi96
#16281
üzenetére
de azért Köszi
-
#16282
norby10
csendes tag
tothjozsi96
#16281
norby10
csendes tag
válasz
tothjozsi96
#16281
üzenetére
nem ez a megoldás, még mindig az a probléma
-
#16280
norby10
csendes tag
tothjozsi96
#16279
norby10
csendes tag
válasz
tothjozsi96
#16279
üzenetére
be van az elöző postban
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mondjuk felőlem ikszdézhetne többet is, ha legalább tudna magyarul és értelmesen írni+fogalmazni.
Mikor lett annyi, adatbázisba való feltöltés után, vagy még az alkalmazás "szintjén"? Az a baj, hogy csomószor harapófogóval kell kiszedni belőled az érdemi, nem mellébeszélő infókat, még sokszor így sem sikerül, és így az embernek csomószor elmegy a kedve a segítéstől.
Új hozzászólás Aktív témák
Hirdetés
- OLED monitor topik
- BestBuy topik
- PH!otósok beszélgetős, offolós topikja
- Nintendo Switch 2
- eBay
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- Azonnali alaplapos kérdések órája
- Milyen légkondit a lakásba?
- Azonnali notebookos kérdések órája
- Bambu Lab 3D nyomtatók
- További aktív témák...
- Bomba ár! HP EliteBook 820 G2 - i5-5GEN I 8GB I 256GB SSD I 12,5" FHD I Cam I W10 I Garancia!
- LG 55C3 - 55" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
- Medion Erazer Beast X40-hez vízhűtés (MD 60961) (ELKELT)
- Bomba ár! Dell Latitude 5400 - i5-8GEN I 16GB I 512SSD I 14" HD I HDMI I Cam I W11 I Gari!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged