PHP - deserializace objektu - ošetření vstupu

[Filip Jirsák]

Proste pouzit redis backend pre session.

Prostě zavést do systému další komponentu, o kterou se musíte starat a kterou musíte platit.

Len sa ta stavovost neprenesie do browseru uzivatela, ale tam kam patri.

HTTP protokol vznikl jako bezstavový. Stav do toho přináší až uživatel. Takže podle mne stav patří na klienta.

To o co sa znazite vy, na tom si vylamalo zuby uz mnoho vyvojarov.

Zároveň to mnoho vývojářů úspěšně provozuje.

[Reklama]

[Logik]

Také se mi to zdá jako úplně ukázková věc na aplikaci redisu.

Nicméně, pokud bych už to chtěl řešit bez "externího úložiště" a použít PHP serializaci, tak bych k serializovanému objektu připojil ještě hash s nějakým secret code (defakto další podpis), kterej bych ověřil před unserializací. Ale i tak i to přijde jako "very bad practice".


Pokud už posílat nějaká data takto na klienta, tak ne serializovaný objekt, ale např. něco v JSON formátu a ten objekt z toho JSONu vytvořit "ručně". Tam je podstatně menší prostor na bezpečnostní díry, než při použití serializace. Ale to jsme vlastně u toho JSON web tokenu, kterej tu někdo navrhoval, aneb u klasické zásady:

Pokud se něco týká bezpečnosti, POUŽIJ OSVĚDČENÁ ŘEŠENÍ. Šance, že při samodomo řešení bezpečnosti něco uděláš blbě je v podstatě 100%. To neplatí jen pro úplné lopaty:lidí, kteří opravdu zvládají všechny aspekty bezpečnosti a zároveň jsou ještě k tomu schopni je dobře implementovat zas tak moc není.


Filip:

HTTP protokol vznikl jako bezstavový. Stav do toho přináší až uživatel. Takže podle mne stav patří na klienta.

Vznikl, ale také vznikl pro naprosto jiné účely, než pro které se dnes používá. Takže ať už se to bude řešit jakkoli, vždycky to je "rovnák na vohejbák". Oni už samotný cookies, který k tomu ať tak či tak použiješ, popíraj původní ideu HTTP.

[Death Walker]

Proste pouzit redis backend pre session.

Prostě zavést do systému další komponentu, o kterou se musíte starat a kterou musíte platit.

Bez tak, ako vzdy dojde na to ze radsej ako 10000x to generovat v php, tak je lepsie 1x php a 9999x si siahnut do cache. Php v dnesnej dobe sic uz nie je tak pomale, ale stale to nie je raketa.
Naviac ide kp komponentu naviac, ktorej vyvoj ide mimo vyvojara konkretnej aplikacie. Kdezto riesenie urobime to v php, je funkcionalita o ktoru sa zbytocne naviac musi starat vyvojar.

Len sa ta stavovost neprenesie do browseru uzivatela, ale tam kam patri.

HTTP protokol vznikl jako bezstavový. Stav do toho přináší až uživatel. Takže podle mne stav patří na klienta.

Podla mna ani nie, s pohladu uzivatela ide o poziadavku a odpoved. Na strane serveru je odlisit jednotlivych uzivatelov tak aby dostali odpoved v spravnom kontexte.

To o co sa znazite vy, na tom si vylamalo zuby uz mnoho vyvojarov.

Zároveň to mnoho vývojářů úspěšně provozuje.

Slovo uspech je vysoko relativne. "Uspech je, ze to funguje" asociuje so slovom zazrak.