Ieskau kas uzsiima bootstrapu

[Zero Two]

prieš 6 valandas(-ų), NTQ parašė:

@mreaddy Niekam neįdomia nuomonę? O manai tavoji kažkam įdomi? Kiek suprantu, SuperGames praktikuoja laisvę į bet kokią nuomonę, tai jeigu kažkam ir ji nepatinka, absoliučiai narys negali aiškinti, jog nerašyk čia. Tai ne tavo jėgoms.

Apie programavimą žinai nieko ir kiši savo neprofesionalią nuomonę programuotojui, kuris dirba su technologijomis jau daugiau nei 5 metus? Really?

O apie Bootstrap dabar paaiškinsiu kaip 7 metų vaikui.

Bootstrap turi apie 60% šlamšto savo viduje ir dalykų, kurių net nenaudosi. Naršyklė užkrauna visa tai, kas yra masinis atminties panaudojimas, tačiau absoliučiai nereikalingas.

Žvilgtėk kokio ilgumo kodas: https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.css

Taip pat kode matau pilną nelogiškų dalykų. Kūrėjai neatsižvelgė į senesnes naršykles. Nežinau, kodėl, kadangi IE varikliuko palaikymas iki 8 yra must. Kai kurių gamintojų integruotos naršyklės veikia panašiai ir yra pasenusios. Tai ne tik ant kompiuterių viskas išsikraipys, bet ir ant telefonų su senesne programine įranga.

Pažvelkime į Android versijų statistiką – https://developer.android.com/about/dashboards. Šiais metais apie 10% visų naudotojų turi 4.4 versiją arba mažesnę. Android 9 10.4%. Ir tokie senumo įrenginiai sufailins iškart Bootstrap svetaines, bye bye visiems tiems varotojams.

Ar reikia kokių nors specialių pastangų ar kokybės aukojimo, kad kodas atsižvelgtų į įvairiausių versijų naršykles? Atsakymas labai paprastas – nereikia. Bootstrap kūrėjai norėjo pasirodyti protingesniais už kitus ir eilinį kartą sufailino. Jų ten tas CSS kodas įvairiausių versijų kratinys.

Vietoj background, naudoja background-color (žmogeliai dar sėdi ant CSS2 standartų), kai background: [spalva] [pasirinktis|nuotraukos url) – viskas rašoma į vieną. [>], [+] atributai absoliučiai nereikalingi (gal kokį 1 -2 kartus teko panaudoti per visą patirtį). Flex panaudojimas irgi kvailas sprendimas (vien dėl jo senos naršyklės sufailins teisingai atvaizduoti blokus).

Kai float, display yra universalus ir veiks visada. Žinoma, tik jį sunkiau panaudoti, turi turėti pakankamai patirties, kad pvz įkištum su jo kairį, centrinį, dešinį bloka į vieną liniją.

Kuo personalizuotas kodas yra geresnis už bet kokias open-source bibliotekas? Kodas yra 3x mažesnis, dėl to greičiau naršyklės krauna CSS failą, žymiai lengviau išplėtoti ateityje, leisti atnaujinimus + tikrai tvarkingesnis už Bootstrap, jei koduotojų žinios & patirtis pakankamos.

Nuo nulio rašytas kodas niekur nedingsta. Tą patį kodą galėsi panaudoti ir kt. projektuose. Kuo daugiau sukursi projektų rankiniu būdu su CSS, tuo daugiau turėsi šablonų ir 90% atveju reikės tik copy-paste svarbiausius dalykus.

+ Kūrybos laisvė. Nereikia vadovautis kito kūrėjo sprendimais, pasidarai sau suprantamą struktūrą. O pažiūrėjus Bootstrap puslapių HTML, tragedija. Tokios netvarkos gyvenime nesu matęs.

Dėl šių priežasčių pasakiau, kad Bootstrap naudotojai yra tinginiai. Nėra jokių pasiteisinimų, kodėl dar 2019 m. turėtų būti naudojamas. Arba tingi investuoti laiką į ilgalaikį, bet vertą sprendimą, arba ant tiek žemos žinios, kad CSS ir HTML absoliučiai neišmano.

Tarp kita ko, CSS kodas nėra kažkoks algoritmas, kuris reikalauja daug laiko. Jeigu išmanai ką darai, personalizuotą puslapį gali sukurti per 3 val. su sunkesne struktūra. Jei šablonus turi – dar greičiau.

kartu sudėjus užima 50KB daugiau nei šita (low quality) nuotrauka:

Be to, jei nežinojai, šių laikų naršyklės naudoja tokį dalyką kaip caching'ą, o dėl to, naršyklėms nereikia kiekvieną kartą užkrauti iš naujo failų kurie nepasikeičia (ir tai kartais net ir pasikeitus rodo cachintą versiją).

Atrodo, kad laikai save "geru programuotoju", bet kažkaip neatrodo lyg suprastum faktą, kad tą patį bootstrap'ą gali pats keisti pagal savo norus sutaupydamas laiką perkuriant viską pačiam.

 

 

 

 

[MagicBeen]

Į ginčą nesiveliu, bet paminėsiu, kad yra dabar toks Boolma CSS. Jei neklystu, jį Bootstrap kūrėjai kūrė. Bootstrap buvo ok, kol neatėjo CSS3. Bootstrap naudoja jQuery tam kas dabar padaroma su CSS3, tad yra atgyvenęs reikalas. Siūlyčiau vietoj jo naudot Boolma geriau. Ten vien CSS ir visiškai light-weight

[D.S.]

Kadangi jau buvo prikelta tema tai aš kelis sakinukus...

2019-11-09 19:54, NTQ parašė:

Žinai kas yra bootstrap? Prikrauta, gan didelė CSS biblioteka, taip pat turi JS patobulinimų, bet spalvos ant tiek nuvalkiotos, kad iš tolo atpažins kas naudoja.

Galėtum pervadinti temą į: Ieškau tinginių koduotojų, kurie nesugeba apsirašyti savo CSS kodo.

Žmogau, kodėl tu toks agresyvus visam forume? Veliesi į konfliktus visur, keli vėjus neaiškius, rašai nesąmones, žemini, įžeidinėji, nepriimi kritikos... Aš čia šiaip pasiskaitinėjau, tai nebejuokinga, žinok. Visi mes turim savo įgūdžius ir visada atsiranda žmonių, kurie kažkur nusimano geriau nei mes. Bootstrapo nenaudotų niekas, jei jis būtų šlamštas. Yra labai narsu iš kažkur išlįsti ir pačiam pasakyt, kad daugelio žmonių darbas yra niekas. Dar pasakyti, jog turi savo šablonus, kurie yra daug geresni nei beveik 20 000 commitų GitHube turintis Bootstrapas. Tai yra arogancija, kito žodžio nerandu. Tikriausiai Laravel, Django ir kiti irgi yra nesąmonės? Aš su visais informatikos reikalais jau irgi nemažą laiką užsiimu. Na, aš galiu savo CSS nuo 0 parašyti ir rašausi, kai man to reikia, bet 90% atvejų to tiesiog nereikia, užtenka įmesti Bootstrap ir pakoreguot. Zero Two įdėjo screenshot, kur aiškiai matosi, kad viso Bootstrapo svoris yra vargani 200kb. Šiais laikais svetainės yra virš vieno, neretai virš dviejų megabaitų svorio ir tai nėra problema. Ar likusius 800-1800 kb užkimši savo kodu? O gal nuotraukom? Net jeigu turėsi kelias nuotraukas, greičiausiai jos tiek vietos neužims, nebent nekreipsi dėmesio į nuotraukų dydį prieš uploadindamas, bet čia jau kita problema.

 

Kodėl tu viską radikalizuoji?

Citata

Nėra jokių pasiteisinimų, kodėl dar 2019 m. turėtų būti naudojamas. Arba tingi investuoti laiką į ilgalaikį, bet vertą sprendimą, arba ant tiek žemos žinios, kad CSS ir HTML absoliučiai neišmano.

Aš pažįstu žmonių, kurie turi dešimtis metų programavimo patirtį ir naudojasi Bootstrapu ir kitais įrankiais. Dėl to, jog šiais laikais tas "siaubingas bootstrap dydis" yra nereikšmingas, mes gyvename ne 30 metų praeity, kai kilobaitai svarbūs būdavo. Dabar kalba eina apie tai, kaip pasiekti didesnių rezultatų per mažesnį laiko tarpą, paaukojant kažkiek vietos todėl, kad jos dabar turime daug.

Taip pat viskas yra apie STANDARTĄ. Niekas nelįs į Bootstrapo vidų, ir netikrins jo kodo, bet žmonės pagal klases žinos, kas ir kaip aprašyta. Jei tu dabar atsiųstum man savo css kodą, man reiktų ganėtinai ilgai pasėdėt, išsiaiškint, ką konkrečiai kas daro tavo kode, ką kokia css klasė reiškia. O Bootstrap klases aš atpažinčiau, greitai perprasčiau ir žinočiau, ką kur daryti, kad kažką pakeisčiau.

Man yra tekę matyti žmonių, kurie užsispyrę eina prieš standartą, galvodami, kad jie daro gerai. Visur yra netobulumų, ir tas Bootstrapas turi savo bjaurasčių, bet niekada nėra gerai ką nors radikalizuoti. Pavyzdžiui, mačiau žmonių, kurie peikia OOP dėl to, kad jis lėtesnis, bet nesupranta, jog šiais laikais yra labai svarbu turėti struktūrizuotą, įskaitomą, tvarkingą kodą, ką OOP labai padeda padaryti. Jie rašo "spagetinį" kodą, kuris prideda 0.0001 sekundės efektyvumo ir porą valandų ar net dienų skaitymo, kai kodą pažiūri kitas asmuo.

 

Kitas dalykas, tikrai esi prirašęs neteisingų dalykų, vienoje temoje užmačiau didelę nesąmonę, bet tema, deja, užrakinta, tai nelabai ką galiu padaryti.

 

Šioje temoje taip "prikoregavai" žmogaus kodą, kad dar ir pavojingą skylę atvėrei.

Citata

Prepare statementų absoliučiai nereikia naudoti, nes nesikreipi į duomenų bazę du kartus. O kad išvengti SQL injekcijos labai prasta mintis.

Patraukei žmogų nuo teisingos minties naudoti prepared statements ir padavei kodą, kuris labai gražiai leidžia "nuknisti" visą duombazę.

Jeigu nori patikrinti ar toks vartotojas egzistuoja, paprasčiausiai rašai:

if ($conn->query("SELECT COUNT(`id`) FROM `vartotojai` WHERE `email` = '$email';") > 0) {

echo 'Toks naudotojas jau yra užregistruotas.';

} 
Insertinimas:

if ($conn->query("INSERT INTO `vartotojai` (`username`, `password`, `gender`, `email`, `phoneCode`, `phone`) VALUES ('$username', '$password', '$gender', '$email', '$phoneCode', '$phone');")) {

echo 'Naudotojas buvo sėkmingai užregistruotas.';

} 

 

Kas čia dabar? Negalima plikai padavinėti parametrų... Pabandyk įvest email:   "  '; DROP TABLE vartotojai -- ", pažiūrėsim, koks bus rezultatas... O ir tie tavo minėti HTML filtrai menkai apsaugos. Net jeigu prafiltruosi "pavojingus" simbolius - dėl MySQL encoding galimai skylė vis tiek liks. Prepared statements yra dar vienas standartas, tik, kitaip nei Bootstrap, būtinas. Čia jau ignoruot yra totalus dviračio išradinėjimas ir savo vartotojų duomenų negerbimas saugant savo paties įvertintais niekieno nepatvirtintais metodais.

 

Labai gera taisyklė yra, jeigu dauguma sako, kad esi neteisus, tai greičiausiai ir esi Gal ir aš čia prigrybavau, pamatysim, kaip bus įvertinta. Visgi, priimk bent šiek tiek kritikos, nes sveika. Visi mes mėgstame būti geriausiais, bet reikia turėt pagarbos kitiems. O visi tokie Bootstrapo klausimai gali būti suprantami kaip filosofiniai, atsakymas priklauso nuo žmogaus, o tu čia bandai savo nuomonę prastumt įžūliai.

[NTQ]

59 minutes prieš, D.S. parašė:

Kitas dalykas, tikrai esi prirašęs neteisingų dalykų, vienoje temoje užmačiau didelę nesąmonę, bet tema, deja, užrakinta, tai nelabai ką galiu padaryti.

 

Šioje temoje taip "prikoregavai" žmogaus kodą, kad dar ir pavojingą skylę atvėrei.

Patraukei žmogų nuo teisingos minties naudoti prepared statements ir padavei kodą, kuris labai gražiai leidžia "nuknisti" visą duombazę.

Jeigu nori patikrinti ar toks vartotojas egzistuoja, paprasčiausiai rašai:

if ($conn->query("SELECT COUNT(`id`) FROM `vartotojai` WHERE `email` = '$email';") > 0) {

echo 'Toks naudotojas jau yra užregistruotas.';

} 
Insertinimas:

if ($conn->query("INSERT INTO `vartotojai` (`username`, `password`, `gender`, `email`, `phoneCode`, `phone`) VALUES ('$username', '$password', '$gender', '$email', '$phoneCode', '$phone');")) {

echo 'Naudotojas buvo sėkmingai užregistruotas.';

} 

 

Kas čia dabar? Negalima plikai padavinėti parametrų... Pabandyk įvest email:   "  '; DROP TABLE vartotojai -- ", pažiūrėsim, koks bus rezultatas... O ir tie tavo minėti HTML filtrai menkai apsaugos. Net jeigu prafiltruosi "pavojingus" simbolius - dėl MySQL encoding galimai skylė vis tiek liks. Prepared statements yra dar vienas standartas, tik, kitaip nei Bootstrap, būtinas. Čia jau ignoruot yra totalus dviračio išradinėjimas ir savo vartotojų duomenų negerbimas saugant savo paties įvertintais niekieno nepatvirtintais metodais.

 

Labai gera taisyklė yra, jeigu dauguma sako, kad esi neteisus, tai greičiausiai ir esi Gal ir aš čia prigrybavau, pamatysim, kaip bus įvertinta. Visgi, priimk bent šiek tiek kritikos, nes sveika. Visi mes mėgstame būti geriausiais, bet reikia turėt pagarbos kitiems. O visi tokie Bootstrapo klausimai gali būti suprantami kaip filosofiniai, atsakymas priklauso nuo žmogaus, o tu čia bandai savo nuomonę prastumt įžūliai.

Apie ką tu čia kalbi? Anksčiau pats naudojau visur prepared statements, bet kai labiau panagrinėjau jų veikimą, pradėjau vengti jų kai kuriuose situacijose. Pvz, prepared statements absoliučiai nereikalingas SELECT užklausai. Kaip tik, sulėtina ją, nes MySQL nepalaiko būtent tokio dalyko. Tai tik INSERT, UPDATE. DELETE kartais, jeigu keičiasi ID. O šiaip masiškai įrašus galima ištrinti su 1 query.

Ten tas atsakymas rašytas iš telefono, tai žinoma, kad nesivarginau su apsaugomis. Be to, labai aiškiai parašiau, jog reikia apsaugoti. Jeigu manai, kad vienintelio prepared statements užtenka kaip pagrindinės apsaugos – klysti. Iškart prasileistum su XSS ataka, t. y. <script>alert(':)');<script>.

Regex, trimai, html*, strip_tags, (int), (float) – suteikia didesnę apsaugą nei prepared. Taip pat turi naudoti mb_strlen funkcijas, kad neleistum vartotojui įrašyti mažiau arba daugiau simbolių nei reikia. Dauguma nusistato per MySQL dydžius ir taip palieka, kas niekada nėra gerai. Visad turi likti laisvų simbolių. Pvz, varchar(50) yra bloga praktika. varchar(250) – liuks. Galbūt ir nesieks 250 simbolių, tačiau jeigu darysi pakeitimus ateityje, nereikės redaguoti šimtai lentelių. Bet be mb_strlen spamintojai greitai tuo pasinaudos.

Reiškiasi jeigu tu naudoji insert arba update, pavyzdžiui, kokiems nors skaičiams įterpti, tai $input = (int) $_POST['value'] bus 3x efektyvesnis nei prepared. Jokio real_escape_string tuo labiau nereikia.

Basically, naudok prepared, jeigu naudotum real_escape_string daug kartų. Arba darysi pakeitimus daug kartų tai pačiai lentelei. Taip padidinsi efektyvumą. O prepared ar real_escape_string yra same shit, saugumo prasme.

Bootstrap šiuo atveju yra subjektyvus dalykas, bet vertinu tavo nuomonę.

Redaguota Balandžio 12, 2020, nario NTQ

[D.S.]

prieš 10 valandas(-ų), NTQ parašė:

Apie ką tu čia kalbi? Anksčiau pats naudojau visur prepared statements, bet kai labiau panagrinėjau jų veikimą, pradėjau vengti jų kai kuriuose situacijose. Pvz, prepared statements absoliučiai nereikalingas SELECT užklausai. Kaip tik, sulėtina ją, nes MySQL nepalaiko būtent tokio dalyko. Tai tik INSERT, UPDATE. DELETE kartais, jeigu keičiasi ID. O šiaip masiškai įrašus galima ištrinti su 1 query.

Ten tas atsakymas rašytas iš telefono, tai žinoma, kad nesivarginau su apsaugomis. Be to, labai aiškiai parašiau, jog reikia apsaugoti. Jeigu manai, kad vienintelio prepared statements užtenka kaip pagrindinės apsaugos – klysti. Iškart prasileistum su XSS ataka, t. y. <script>alert(':)');<script>.

Regex, trimai, html*, strip_tags, (int), (float) – suteikia didesnę apsaugą nei prepared. Taip pat turi naudoti mb_strlen funkcijas, kad neleistum vartotojui įrašyti mažiau arba daugiau simbolių nei reikia. Dauguma nusistato per MySQL dydžius ir taip palieka, kas niekada nėra gerai. Visad turi likti laisvų simbolių. Pvz, varchar(50) yra bloga praktika. varchar(250) – liuks. Galbūt ir nesieks 250 simbolių, tačiau jeigu darysi pakeitimus ateityje, nereikės redaguoti šimtai lentelių. Bet be mb_strlen spamintojai greitai tuo pasinaudos.

Reiškiasi jeigu tu naudoji insert arba update, pavyzdžiui, kokiems nors skaičiams įterpti, tai $input = (int) $_POST['value'] bus 3x efektyvesnis nei prepared. Jokio real_escape_string tuo labiau nereikia.

Basically, naudok prepared, jeigu naudotum real_escape_string daug kartų. Arba darysi pakeitimus daug kartų tai pačiai lentelei. Taip padidinsi efektyvumą. O prepared ar real_escape_string yra same shit, saugumo prasme.

Bootstrap šiuo atveju yra subjektyvus dalykas, bet vertinu tavo nuomonę.

 

Klysti. Prepared statements nenaudoji tokiu atveju, jei nepaduodi jokio parametro (SELECT `name` FROM `users`). Jei paduodi parametrą bet kokiu atveju jis yra būtinas, kitaip palieki skylę saugume. XSS ataka SELECT atveju NIEKAIP nesuveiks, nes niekas nėra išsaugoma, niekas nėra atvaizduojama, yra tik ieškoma duombazėje. Bendru atveju, žinoma, reikia galvoti apie visas atakas, bet šiuo atveju vienintelis nereikalingas dalykas yra minėti "Regex, trimai, html*, strip_tags". Suplaki dvi atakas XSS ir SQL injekciją.

html funkcijos bei strip_tags yra skirti kovai su XSS. Yra atvejų, kai htmlspecialchars gali padėti apsisaugoti ir nuo SQL injekcijos, bet tai nėra 100% saugus dalykas (https://stackoverflow.com/a/22117157/4402190). strip_tags šiaip yra ganėtinai bjaurus dalykas ir jį naudot dažniausiai yra gan keistas pasirinkimas, ypač jei input yra tekstas, o ne username, nes jis gali tiesiog panaikinti informaciją, kurią tu kiek įmanoma turi išsaugoti tokią kokią useris parašė. Nors ir nebloga apsauga nuo XSS, bet nenaudočiau. Regexas ir trimas vėlgi turi savų niuansų ir labiau tinka prieš XSS, ne prieš SQL injekciją.

Prepared statements buvo sukurti siekiant apsisaugoti nuo SQL injekcijų. Tai yra būdas turintis šiuo metu maksimalią apsaugą nuo jų. Į duombazę pirma kreipiamasi su užklausa, o po to paduodant parametrus. Tai yra tinkamiausias ir logiškiausias būdas daryti SQL queries. Sakyti kad real_escape_string ir prepared statemets yra tas pats saugumo prasme yra nesąmonė. Gal laikinai escape string gali apsaugoti, bet jis turi daug daugiau potencialo būti pažeidžiamu, jeigu dar nėra pažeidžiamas (https://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string/12118602#12118602), nei prepared statements. Nėra prasmės kelti pavojų duomenų saugumui siekiant išvengti to antro kreipimosi į duomenų bazę. Jeigu labai taupai laiką, tai tikrai iškelčiau klausimą, ar regex nėr ženkliai labiau resursus eikvojantis reikalas, nei antras kreipimasis į duomenų bazę

Aš sutinku, kad specifiniais atvejais, pvz rašant skaičius, galima apsieiti su int funkcija, bet jei rašai tekstą, tada tokie dalykai yra tiesiog nepriimtini. Prepared statements + htmlspecialchars, kai kuriose situacijose dar papildomi dalykai ir you are good to go.

 

Linksmų švenčių:)

 

P.S. atsiprašau autoriaus dėl nukreipimo temos, bet ta tema, kuriai buvo skirta ši diskusija uždaryta. Daugiau neberašysiu.

P.S.S. Užsiimu Bootstrap.

P.S.S.S. Prisiminiau, jog tema sukurta prieš daug mėnesių.

Redaguota Balandžio 12, 2020, nario D.S.

[NTQ]

@D.S. tu absoliučiai neišmanai nieko apie SQL užklausas. Apie kokias tu atakas kalbi? ', ", \, `, /, ; – pagrindinės spragos (tos tavo baisios SQL injekcijos). Jeigu naudoji regex, tokie simboliai nepraeis. + nereikia cherry pickinti. real_escape_string saugumas lygiai toks pats kaip ir prepared stmt, jeigu naudoji latin1, utf8, utf8mb4, o pastarasis labiausiai rekomenduotinas. Išrenki praėjusių versijų saugumo spragas ir su tuo mėgini įrodyti? Nejuokink vaikų.

Kitas dalykas, apie parametro padavimą nieko nerašiau SELECT užklausai + XSS ataką (ryškiai suvokimo spraga tau). Bet ir taip, jeigu tik 1 parametras, real_escape_string efektyvesnis šiuo atveju. Jeigu naudoji daug kartų šią funkciją, tik tada apkrauni duomenų bazę, nei prepared. Tuo labiau, jei inputas yra trusted, t. y. paduodamas iš programuotojo ar vidinės sistemos – nėra prasmės naudoti prepared.

Nepamiršk, kad prepared hittina duomenų bazę 2 kartus. Daug panašių užklausų ir turėsi problemų su performance. Nepadės net cache.

Tas funkcijas ir nurodžiau XSS atakomis, bet jos tinka SQL užklausos apsaugojimui. Vėlgi, SELECT ... FROM ... WHERE `column` = 'TURI PABĖGTI IŠ ŠIŲ KABUČIŲ, KITAIP NIEKAIP NEPAKENKSI'

Gal dabar matai? Jeigu išfiltruoji spec. simbolius, TU NIEKAIP nepakeisi užklausos tikslo. Šiuo atveju (int), (float): SELECT ... FROM ... WHERE `column` = ''; DROP TABLE `table`;

PHP perduos pastarąjį su 0, tai bus kaip WHERE `column` = 0.

Gal prieš rašant pasimokyk, o ne kalbėk to, ko neišmanai. Įsikabinęs į prepared, nors ryškiai matosi, kad nesuvoki net elementaraus SQL veikimo ir nusišneki čia apie kažkokias magiškas atakas. Pakartoju: BE AUKŠČIAU MINĖTŲ SPEC. SIMBOLIŲ NIEKAIP NEĮSILAUŠI. REAL_ESCAPE_STRING + HTMLSPECIALCHARS APSAUGO TIEK NUO XSS, TIEK NUO SQL ATAKŲ. PREPARED STATEMENTS APSAUGO TIK NUO SQL. JEIGU NAUDOSI PREPARED, BE NEPANAUDOSI HTML FILTRO, TAI IŠTRAUKIANT DUOMENIS IŠ DB, IŠTRAUKSI GALIMAI JS KODĄ.

Dabar šalin iš čia, vaix.

Atsiversk SQL vadovėlį, pasakų neskaitęs. Matau jau brainwashino tave prepared pakalikai. Programavimą ir jo funkcijas turi naudoti pagal logiką, paskirtį, o ne kažkoks beta cuck per stackoverflow pasakė, tą ir darai nepagalvojęs. Sheep mentalitetas.

[D.S.]

10 minutes prieš, NTQ parašė:

@D.S. tu absoliučiai neišmanai nieko apie SQL užklausas. Apie kokias tu atakas kalbi? ', ", \, `, /, ; – pagrindinės spragos (tos tavo baisios SQL injekcijos). Jeigu naudoji regex, tokie simboliai nepraeis. + nereikia cherry pickinti. real_escape_string saugumas lygiai toks pats kaip ir prepared stmt, jeigu naudoji latin1, utf8, utf8mb4, o pastarasis labiausiai rekomenduotinas. Išrenki praėjusių versijų saugumo spragas ir su tuo mėgini įrodyti? Nejuokink vaikų.

Kitas dalykas, apie parametro padavimą nieko nerašiau SELECT užklausai + XSS ataką (ryškiai suvokimo spraga tau). Bet ir taip, jeigu tik 1 parametras, real_escape_string efektyvesnis šiuo atveju. Jeigu naudoji daug kartų šią funkciją, tik tada apkrauni duomenų bazę, nei prepared. Tuo labiau, jei inputas yra trusted, t. y. paduodamas iš programuotojo ar vidinės sistemos – nėra prasmės naudoti prepared.

Nepamiršk, kad prepared hittina duomenų bazę 2 kartus. Daug panašių užklausų ir turėsi problemų su performance. Nepadės net cache.

Tas funkcijas ir nurodžiau XSS atakomis, bet jos tinka SQL užklausos apsaugojimui. Vėlgi, SELECT ... FROM ... WHERE `column` = 'TURI PABĖGTI IŠ ŠIŲ KABUČIŲ, KITAIP NIEKAIP NEPAKENKSI'

Gal dabar matai? Jeigu išfiltruoji spec. simbolius, TU NIEKAIP nepakeisi užklausos tikslo. Šiuo atveju (int), (float): SELECT ... FROM ... WHERE `column` = ''; DROP TABLE `table`;

PHP perduos pastarąjį su 0, tai bus kaip WHERE `column` = 0.

Gal prieš rašant pasimokyk, o ne kalbėk to, ko neišmanai. Įsikabinęs į prepared, nors ryškiai matosi, kad nesuvoki net elementaraus SQL veikimo ir nusišneki čia apie kažkokias magiškas atakas. Pakartoju: BE AUKŠČIAU MINĖTŲ SPEC. SIMBOLIŲ NIEKAIP NEĮSILAUŠI. REAL_ESCAPE_STRING + HTMLSPECIALCHARS APSAUGO TIEK NUO XSS, TIEK NUO SQL ATAKŲ. PREPARED STATEMENTS APSAUGO TIK NUO SQL. JEIGU NAUDOSI PREPARED, BE NEPANAUDOSI HTML FILTRO, TAI IŠTRAUKIANT DUOMENIS IŠ DB, IŠTRAUKSI GALIMAI JS KODĄ.

Dabar šalin iš čia, vaix.

Atsiversk SQL vadovėlį, pasakų neskaitęs. Matau jau brainwashino tave prepared pakalikai. Programavimą ir jo funkcijas turi naudoti pagal logiką, paskirtį, o ne kažkoks beta cuck per stackoverflow pasakė, tą ir darai nepagalvojęs. Sheep mentalitetas.

Neturi jokios kultūros

Nuorodose sakoma apie encoding, kur GALIMAI NEAPGALVOJUS AR PADARIUS KLAIDĄ (bet nebūtinai) gali atsirasti skylė. O kam rizikuoti? O sakyti, kad kažkas yra neįmanoma, yra labai arogantiška. Programavimas ir hackinimas yra menas, jei dabar kažkas yra sunkiai įmanoma, niekas negarantuoja, kad atsiradus naujovėms neatsivers naujos skylės. Jeigu naujos skylės atsivers su prepared statements, jos greitai bus užglaistytos, nes tai yra standartas ir žmonės anksčiau ar vėliau pamatys problemas. Jei naujos skylės atsiras su kodu, kurį rašai tik tu, tai tu turėsi specifinį savo sistemoms pažeidžiamumą, kurį pačiam atrasti prieš žmones, kurie nori tau pakenkt, bus sunku, ypač, su tavo dabartiniu požiūriu, kad tu kuri tobulą kodą. Laikai visus aplinkinius kvailiais, remiesi savimi, nes esi pats geriausias programuotojas ant svieto. Labai mėgsti eiti prieš standartus ir kai dirbsi su kitais žmonėmis, jie bus tuo nepatenkinti, nes standartas yra tam, kad jo laikytumeisi, o kad jo nesilaikytum, reikia turėti gerą priežastį, geresnę nei minimalus, varge reikšmingas kodo pagreitėjimas (o kartais prepared statements suveikia dar ir greičiau) Tu turi plačiau žiūrėti į gyvenimą, nes tokių žmonių niekas nemėgsta. Net jei būtum teisus, su tavim niekam nepatiktų diskutuot, o dar ir siauro mąstymo vėjus kalbi. Pasakiau, kad daugiau temos neteršiu ir neteršiu. Kažką sakau, o kaip į sieną atsimuša, tai kam ir kalbėt   Ad hominem yra vienintelė kalba, kurią supranti. O SQL pačiam vertėtų pasimokyti, kaip ir etiketo. Aš gal nekalbu super maloniai, bet vis tiek gerbiu tave, o tu mane čia siuntinėji, assumini mano amžių ir pan. Jei nori, gyvenk savo sukurtame saugiame pasaulyje, kuriame tu kuri taisykles, kuriame tu viską žinai ir kuriame kiti yra liurbiai. Tik kitų žmonių į tokį pasaulį nekviesk.

 

Čia jau tikrai paskutinė žinutė, nes mane tėvai vaikystėje gerai išmokė, kam ten reikia duoti kelią

 

[Ark'xes]

tbh nekreipkit dėmesio į tai ką rašo NTQ  čiuvas matosi nėra prie realių projektų dirbęs, kelis straipsniukus lempinius perskaitė ir bando visiem savo tiesas išaiškint.