- Samsung Galaxy S23 Ultra - non plus ultra
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Milyen okostelefont vegyek?
- Samsung Galaxy Watch7 - kötelező kör
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Google Pixel topik
- Telekom mobilszolgáltatások
- Hívószám-hamisítás
- Youtube Android alkalmazás alternatívák reklámszűréssel / videók letöltése
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
Új hozzászólás Aktív témák
-
cucka
addikt
Mehet így is.
Igazából minél többet nézem a kód részleteket, amiket mutatsz, annál kevésbé világos, hogy ez a framework pontosan mit is fog tudni, hova akarsz eljutni? Tulajdonképpen ez (mármint hogy mit tud a framework, hogyan épül fel, stb.) első körben sokkal fontosabb annál, mint hogy most globális függvényként írod-e ezeket meg vagy egy osztály statikus függvényeiként. -
cucka
addikt
A struktúra szerintem alapvetően jó így.
Egy apró megjegyzés: private adattagok/függvények helyett a legtöbb esetben érdemesebb protected-et használni. Kívülről nézve nincs különbség, származtatásnál viszont jellemző, hogy szeretnéd használni az ős osztály védett metódusait/adattagjait.
Mondjuk ez a session kezelés osztály pont olyan, ami nem hasonlít a legtöbb esetre. Ezt várhatóan nem fogod származtatni, így teljesen jó a private is. -
cucka
addikt
Nem muszáj singleton-t használni, tulajdonképpen elsőre bőven jó egy olyan osztály, ami valóban oop-s és elvégzi a dolgát, az osztályt használó kód majd biztosítja azt, hogy csak 1 példány legyen belőle.
(A session amúgy is egy globális valami és egy darab van belőle)Itt találsz példát singleton osztályra.
-
cucka
addikt
Egy gyors ránézés után egyértelmű, hogy nálad nem jött át, hogy mire jó az abstract osztály.
A kódod gyakorlatilag globális függvények halmaza, amiket egy osztályba tettél. Na ettől nem lett oop-s a kód.
Az absztrakt osztály lényege, hogy ez egy osztály, aminek néhány függvénye csak deklarálva van, de nincsenek definiálva (abstract függvények). Ez azt jelenti, hogy az osztály megmondja, hogy milyen pontosan függvényekre van szükség a működéséhez, de ezeket a függvényeket a leszármazottak kötelesek implementálni.
A fentiek alapján ki lehet jelenteni, hogy a te osztályod teljesen fölöslegesen használja az "abstract" kulcsszót, mert pont a lényeg hiányzik belőle.Amire neked ennél a session osztálynál szükséged lenne, az egy rendes példányosítható osztály, ami singleton (tehát egy időben csak egy példánya létezhet, nézz utána wikin, hogy hogyan és miért).
Az alkalmazásod indulásnál példányosítja a session osztályt, majd használja azt. Természetesen az osztály függvényei nem statikusak, mert annak semmi értelme nincs ebben az esetben.Szólj ha valami nem kerek
(Egyébként egy nem sértőnek szánt megjegyzés: sokkal jobban járnál, ha fognál egy komoly php-s framework-öt és elkezdenéd használni, illetve megpróbálnád megérteni, hogy hogy működik, mert nekem innen úgy tűnik, hogy azért van egy-két lyuk a tudásodban, amit be kéne foltozni ahhoz, hogy értelme legyen a saját framework írásának)
-
LW
őstag
Javítva: http://pastebin.com/dwuZLAJK
-
cucka
addikt
Cucka mondta nékem, hogy statikus eljárásokat/függvényeket abstract osztályba rakni bohóckodás.
Most nem nézek utána, de szerintem azt írtam, hogy saját framework-öt írni a bohóckodás. (De ha mégsem, akkor erre gondoltam)
Statikus függvényeket nem blaszfémia használni, egyszerűen csak ugye ezek lényege, hogy egy osztályra vonatkoznak, nem pedig az osztály egyes példányaira, így pontosan akkor kell őket használni, amikor pontosan erre van szükség - általában nincs. Kód vagy osztálydiagram nélkül nehéz okosakat mondani, esetleg megmutathatnád, hogy mit készülsz implementálni.
A statikus függvények másik jellemző felhasználása, amikor rengeteg segédfüggvényeked van (mondjuk egy framework-ben ez jellemző) és ezeket témakör szerint osztályokba rendezed úgy, hogy mindegyik statikus lesz. Tulajdonképpen globális függvényként használod őket. Ennek az előnye:
- ha megcsináltad rendesen az autoload()-ot, akkor az megoldja az include-okat erre is
- nem parse-oltatsz le fölöslegesen egy csomó kódot a php-val
- szép rendezett kódod lesz -
cucka
addikt
a tömb elemei referencia nélkül is megmaradnak az éterben?
Természetesen ez esetben nem maradnak meg az éterben, jól is néznénk ki, ha ilyen memory leak-ekkel lenne tele a php.
A php-ben van garbage collector, ami folyamatosan figyeli a lefoglalt változókat (pontosabban zval-okat) és ha valamelyiknek a ref_count-ja nulla lesz, akkor felszabadítja a hozzá tartozó memóriát. Ha nagyon érdekel a téma, a php manual-ban le van írva részletesen [link] -
cucka
addikt
Vágom. Az első megoldást javaslom, mert
- nem kell nyilvántartani, hogy mire futott már le a stripslashes és mire nem
- ha valami ott van a REQUEST-ben, akkor az valószínűleg azért van ott, mert szükség van rá, használni szeretnéd valamire. Ha a REQUEST tele van szeméttel, akkor előbb azt kell megoldani, hogy ne legyen. -
cucka
addikt
hanem egyszer beállítom és mindegyikre objektumra érvényes. Végső soron ezért vannak a statikus adattagok, vagy nem?
A lényeg, hogy ha az objektum be tudja állítani magának a konstruktorban, akkor ne kelljen kívülről beállítani.
Amúgy igen, lehet statikusnak is deklarálni ezt a változót, ez esetben mondjuk legyen null a kezdőértéke és a konstruktor csak akkor állítsa be az értékét, ha az null.Am így valóban jobb és szakszerűbb, bár sztem így több memóriát eszik
Többet nyersz a jó kóddal, mint azzal, ha spórolsz 3 byte memóriát.viszont a GET és POST nem minden elemén stripslashelek, hanem csak amelyik kell.
Ha be van kapcsolva a magic_quotes, akkor mindegyiken kell.Az megint egy kérdés, hogy egy elemet többször fölöslegesen is, amennyiben nem tárolom el egy változóban.
Ha egy elemre többször fut le a stripslashes, az nagy baj, mert módosítja magát az adatot is. A kódnak biztosítania kell, hogy csak egyszer fusson le. Például a kód, amit írtam/írtál, az biztosítja ezt. -
cucka
addikt
Kicsit átírtam. Pár ökölszabály:
- a konstruktor azért van, hogy inicializálja az objektum változóit
- ha nem vagy benne biztos, hogy statikus adattagot/függvényt kell használj, akkor nem kell használd.class Superglobal{
protected $content = array();
protected $magic_quotes = false;
function __construct($sga){
$this->content = $sga;
$this->magic_quotes=get_magic_quotes_gpc();
}
function Get($key, $secure = false, $default = false, $remove_html = false, $remove_js =false){
if(isset($this->content[$key])){
$value=$this->content[$key];
if($this->magic_quotes)$value= stripslashes($value);
if($secure)$value = STRINGS::Secure($value, $remove_html, $remove_js);
return $value;
} else {
return $default;
}
}
} -
cucka
addikt
Egy kis saját keretrendszert készítek és született az alábbi elgondolás.
Ne készíts saját keretrendszertMinden bizonnyal lassítja a futást, de egyszerűsíti a munkát. Szerintetek érdemes ezt így használni?
Nem érdemes. Ha már keretrendszert készítesz és szeretnél egy szuperglobál osztályt készíteni ahhoz, hogy biztonságosan kezeld a user inputot, akkor
- legyen egy osztályod, ami általánosan meg tudja oldani a feladatot akármilyen tömbre
- a program indulásánál példányosítod az ősosztályt a szuperglobálokra
- az ilyen megoldás egyetlen előnyös oldala, hogy egy helyen le tudod kezelni azt, hogy a szerveren be van-e kapcsolva a magic_quotes_gpc, na pont ez hiányzik a kódból
- a PHP case insensitive függvénynevek esetén, de ha minőségi kódot szeretnél kiadni a kezeid közül, akkor erről a "fícsörről" nem veszel tudomást.
- mivel a PHP egyik alapvető funkciója, hogy implicit cast-ol (szinte) bármit bármivé, ezért ezt beépíteni az osztályodba teljesen fölösleges.Ennek az abstract static bohóckodásnak semmi értelme, gyakorlatilag amit írtál, az ekvivalens azzal, mint ha megírtál volna néhány globális függvényt, csak mellette ott van zajnak egy csomó OOP-s keyword.
-
shaggy
aktív tag
így van elé írtam a taget én a rövidet használtam és engedélyezve is volt és azt az útvonalat használtam amit leírtál igen de nekem akkor sem jó nem tudom miért csinálja ezt.
Most megpróbálom a PHP4 leszedni és a könyv alapján mert én a php5 raktam fel de nekem nem nagyon akar működni. -
LW
őstag
Öhm... Megvan a megoldás és ez fájt.
Mi volt az, ami eddig nem volt és a közelmúltban került a képbe? Sokadik Apache-mysql-php trió után sorra elkövettem?
A phpeditor debugja hülyítette meg ennyire az apacheot. Reggel felkeltem, raktam fel egy újabb wampot, jól ment, egészen addig, amig nem volt debugra szükségem. Beállítottam a szerkesztőt és jött a facepalm meg a Connection was reset.Azt hiszem, tanulságos volt.
-
jeges
senior tag
-
Sk8erPeter
nagyúr
Előző kommentekhez hozzáfűzve:
ha már JS-függő site, és cikkírások, akkor érdemes megfontolni azt a megoldást is, amit a Gmail és pl. akár a stackoverflow is alkalmaz: levél/hozzászólás/... írása esetén időszakos mentéseket készít az addigi piszkozatról, így nem vész el az irományod. Gmailnél mondjuk meg is marad véglegesen. Felhasználóhöz kötve tehát érdemes lehet piszkozatot is készíteni bizonyos cikkekről, így később is folytatható, valamint nem vész el - legalábbis nem teljesen, ha közben lejár a munkamenet. Természetesen a legjobb megoldás az, amit mostanában Neptunnál is alkalmaznak végre, hogy a munkamenet lejárta előtt figyelmeztet annak lehetséges megújítására - ha 1 percen belül nem kattintasz arra a gombra, ami ezt elintézi neked, akkor kiléptet; na, a kiléptetés előtt lehetne közvetlenül piszkozatként elmenteni a cikket.
Manapság az AJAX-os megoldások szerintem elkerülhetetlenek, nagyságrendekkel felhasználóbarátabbá és akár programozói szempontból is kényelmesebbé tehetik az oldalakat (a programozói szopásoktól most eltekintve).
-
Tele von Zsinór
őstag
Ahogy előttem is írták: a munkamenet hosszát az alkalmazás határozza meg - komolyabb biztonságnál egyértelműen rövidebbre érdemes venni, a php alapbeállítása (1440 másodperc - 24 perc) egy elég jó arany középút. Ritkán tartom szükségesnek állítani.
Az "emlékezz rám" megoldások nem a session idő megnövelésével működnek, hanem plusz egy sütivel, ami mondjuk él egy hétig, és egyértelműen köthető egy felhasználóhoz. Az egyszerű megoldás az, ha ennek meglétét a bejelentkező oldal vizsgálja, ha létezik és érvényes, akkor rögtön továbbít is anélkül, hogy látnád a login formot.
Előfordulhat olyan helyzet, hogy egyetlen oldalon (vagy egy páron - az alkalmazásod méretéhez képest kevés helyen) kell hosszabb munkamenet, erre egy kerülőút: egy, csak azokon az oldalakon behúzott javascript, ami párpercenként egy ajax kéréssel a háttérben életben tartja a sessiont, mondjuk ötpercenként egy kéréssel legfeljebb 12 alkalommal, az plusz egy óra. Például az említett cikkírós oldalra jól jöhet, cserébe innentől JS-függő az alkalmazásod. Mai világban nem tragédia, cserébe ne feledd figyelmeztetni az ilyenre a felhasználót egy jól elhelyezett noscript taggal.
Adatbázisban tárolás, erről megoszlanak a vélemények, kap hideget is, meleget is. Akkor tagadhatatlanul hasznos, ha több gépen elosztva van az alkalmazás egy load balancer mögött, ilyenkor kénytelen vagy valami központi megoldást használni, amúgy bőven jó a php.ini-ben beállított, általában fileban történő mentés.
IP, useragent ellenőrzés. Ismét azt mondom, hogy a szükséges biztonsági szint a fő meghatározó, de: a useragent ritkán változik, az ipvel viszont vigyázz: az országban is több szolgáltató van, aminél több user van egy ip mögött, esetleg bonyolítva azzal, hogy egy user ipje is változik kérésről kérésre attól függően, melyik proxy épp van legkevésbé terhelve.
Saját hash generálás felesleges, de amikor változik az authentikációs szint (be- és kijelentkezés, plusz jog kiadása vagy annak elvétele) érdemes egy session_regenerate_id() hívást intézni, ez elég jó védelem a session fixation támadások ellen.
-
RedSign
tag
Szia!
Hát a fő kérdés szerintem, hogy mi az oldal célja és mekkora szintű biztonságra van szükséged? (minél nagyobb annál kisebb időre és annál gyakoribb megújításra). Sok trükköt lehet alkalmazni, a kérdés, hogy szükséges-e az adott oldalhoz?
Persze nem tagadom minél biztonságosabb valami annál jobb...
Üdv,
RedSign -
Tele von Zsinór
őstag
Konvenció kérdése. Ha kell valami validálás, hogy érvényes értékre akarod-e állítani, vagy egyéb tevékenységet is kell akkor futtatnod, akkor kell a setter. Ha semmi ilyesmi, és csak egy állítást végezne belül, akkor felesleges.
Én szoktam létrehozni settereket, ahol érvényes típusra castolom, amit kapok.Az osztályba csoportosítás jó dolog, de ésszel kell csinálni, nehogy túllőj a célon. Példányosítást az abstract kulcsszóval tudod megakadályozni.
-
rt06
veterán
ha nem binary az osszehasonlitas, es megfeleloen van beallitva a collation, akkor az ekezeteket figyelmen kivul hagyja, vagyis u = ú = ü = ű
amennyiben ezt szeretned elkerulni, vagy allitsd be az adott mezot binary-ra, vagy a lekerdezesben hasznald a binary kulcsszot, pl.:
SELECT BINARY 'ü' = BINARY 'ű'; -
Tele von Zsinór
őstag
Látatlanban úgy tippelem, kényelemből a webroot alá mented őket. Ezen logika szerint ha valaki feltölt egy .php filet, simán eléri (és az lefut!), azaz azt csinál a szervereden, amit akar.
Ne tartsd meg az eredeti nevet (már csak az ütközések miatt sem), inkább generálj - az objektum adatbázisbeli id-je remek kiindulópont. És ellenőrizd, a $_FILES-ben levő mime típus nem megbízható, azzal ne foglalkozz. Képekre jó módszer az imagecreatefrom* függvények használata annak eldöntésére, kép-e a file, illetve az engedélyezett típusok közé tartozik-e.
Jól látom, hogy az egy hosszú és egy rövid ü? Nálam hamis.
mysql> select if("ű" = "ü", 1, 0);
+-----------------------+
| if("ű" = "ü", 1, 0) |
+-----------------------+
| 0 |
+-----------------------+ -
LW
őstag
Miután ATWvel mókáztam kicsit, sikeresen életrekelt és még az Ő-s fájlokkal is megy.
A zártkörű majdcsakleszvalahogy.
Viszont a MYSQLes anomália továbbra is érthetetlen számomra.
-
Sk8erPeter
nagyúr
"PHP mindig szerver oldalon fut."
Tévedsz. Ilyen kijelentések előtt inkább tájékozódj.http://en.wikipedia.org/wiki/PHP#Usage
"PHP is a general-purpose scripting language that is especially suited to server-side web development where PHP generally runs on a web server. Any PHP code in a requested file is executed by the PHP runtime, usually to create dynamic web page content. It can also be used for command-line scripting and client-side GUI applications."Erre utalt rt06 is.
-
Tele von Zsinór
őstag
session_id — Get and/or set the current session id
Új hozzászólás Aktív témák
Hirdetés
- user2: Kia Ceed Gold 160 1.5 T-GDI MY2024
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Intel Dual Core 2000 felhasználók barátságos offolós topikja
- Autós topik
- Nyíregyháza és környéke adok-veszek-beszélgetek
- Gyúrósok ide!
- Samsung Galaxy S23 Ultra - non plus ultra
- Honda topik
- Parfüm topik
- További aktív témák...
- Intel Core Ultra 7 265 /// Bontatlan, Teljesen Új // Üzletből, Számlával és Garanciával
- Csere-Beszámítás! Ryzen 9 9950X Processzor!
- Újszerű Gamer Asztali PC Számítógép 2026-ig Garis ASUS H510M-K R2.0 i5 11400F RTX 4060 8GB Dobozába
- Samsung Galaxy Tab A8 (2021) , 3/32 GB,
- Samsung Galaxy S6 Lite (2022) , 4/64 GB ,Wi-fi
- ÁRCSÖKKENTÉS Panasonic Viera 37" TH-37PV8P plazma TV eladó (2 HDMI)
- BESZÁMÍTÁS! 4TB Samsung 870 EVO SATA SSD meghajtó garanciával hibátlan működéssel
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! MSI B450M R5 5500 32GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Chieftec 600W
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest