On 18.9.2016 13:30, Petr Messner wrote:
> Ahoj,
>
> Dne 18. září 2016 12:58 Vladimír Macek <ma...@sandbox.cz
> <mailto:ma...@sandbox.cz>> napsal(a):
>
>     On 18.9.2016 12:29, Tomáš Ehrlich wrote:
>     >>> Jestli je problém, je uživatel double clickne na submit, tak
>     řešit přes JS? OnClick -> Disable?
>     >> Ano, to bude první fáze řešení a určitě to zlepší UX, jak píšeš
>     níže. Ale
>     >> nejde na to spoléhat.
>     > Spoléhat na to nejde, ale pokud to vyřeší 99,9% případů, tak bych
>     to tak nechal. Museli by
>     > se sejít dvě události zároveň, aby to nefungovalo:
>     >
>     > 1) Javascript nepojede (stránka ještě není načtená nebo javascript
>     vypnutý globálně),
>     > 2) Uživatel double clickne
>
>
> To, že by ještě nejel Javascript, se dá vyřešit tím, že to tlačítko bude
> ze začátku (ve statickém HTML) neaktivní a teprve Javascript ho zprovozní.

My považujeme JS za nepovinný.


>  
>
>     Jj, vidím to stejně. Přesto je podle mě dobré chránit i backend.
>
>
> Backend je třeba chránit před útoky - zkoušení náhodných id, operací,
> které by frontend sám od sebe nevyvolal, ale backend je podporuje...
> Chránit backend před tím, co se dá ošetřit ve frontendu, ake zároveň v
> případě neošetření frontendem jde jen o kosmetický a ne o bezpečnostní
> problém, je podle mě zbytečné.
>
> Jinak tohle má ještě jiné řešení, které bude pro tento případ asi moc
> hardcore, ale zmiňuju ho aspoň pro úplnost - klient (frontend, tj.
> javascript) si pro každou operaci vygeneruje nějaké operation_id (UUID v1
> nebo v4 nebo nějakou obdobu vhodnou pro JS), které identifikuje ten
> konkrétní pokus o registraci uživatele, nebo o změnu stavu nějaké entity
> apod. Backend pak pozná, jestli jde o duplicitní požadavek, umí se s tím
> vypořádat a vrátí sémanticky relevantní odpověď. Např. "uživatel úspěšně
> zaregistrován", i když už ve skutečnosti byl zaregistrovaný právě tím
> předchozím požadavkem se stejným operation_id. Vlastně jde o rozšíření té
> myšlenky s response keší. Cílem je, aby i volání, která mění stav, byla
> idempotentní. Využití to má ale spíš v microservices architektuře, kde je
> potom větší prostor a tolerance pro dočasné chyby nebo nedostupnosti
> (např. se něco restartuje, databázový cluster se vzpamatovává z výpadku
> mastera atd.).
>

Ano, je to rozšíření té myšlenky s response keší. Každopádně děkuju.

Mám rád jednoduché věci a zde uvažuju o řešení Kladivo: Kombinaci disable
submitnu při prvním kliknutí pomocí JS a globálního locku na všech POSTech
pomocí middleware. Lock by byl klíčovaný csrftokenem, pokud by existoval, a
uměl by vytikat, aby netrval příp. deadlock.

Tomu zlomku non-JS uživatelů by tedy pak vyběhla chyba validace, že user už
existuje. Řekl bych přijatelná collateral damage.

V.

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/164d4051-6034-9056-6955-c71c36ec6578%40sandbox.cz.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Reply via email to