Zákaz a povolení editace pro uživatele

Zdravím mám webovou aplikaci (php a mysql) do kterého přistupuje více uživatelů a potřebuji udělat ošetření, aby si nepřepisovali záznamy vzájemně pod rukama. V současné době to dělám tak, že jakmile uživatel rozklikne záznam tak, v databázi se uloží jeho ID (do sloupce upravuje), jakmile editaci dokončí (záznam uloží) tak se jeho ID smaže. Problém však nastává, v případě, kdy rozklikne záznam a pak prohlížeč zavře, v tu chvíli v databázi visí jeho ID, že záznam upravuje ačkoliv záznam už needitujeNapadá někoho nějaká jiná možnost, jak provádět ochranu proti tomu abysi uživatel záznam přepisovali? Ještě dodám, že k 1 záznamu má přístup x úživatelů.Jediné co mě napadlo, tak je promazávat neplatné editace pomocí cronuDěkuji

pri zmene zaznamu aktualizuj automaticky "changed" stlpec(timestamp). ked nejaky uzivatel spravi aktualizaciu zaznamu tak v transakcii si overis ci changed nebolo medzicasom zmenene, ak ano, fejlnes a zobrazis spravu ze obsha bol zmeneny inym uzivatelom.

A co ten systém locku doplnit o timestamp s tím, že zamčení trvá maximálně 20 minut. Každých 10 minut můžeš z otevřené stránky poslat AJAX request na prodloužení locku. Případně můžeš pracovat s websockets a opět pomocí pingů udržovat zámek.

existuje tzv. COW (copy on write), rádi to používají journalové file systémy. Nepřepisuj záznamy, ale vkládej nové a vazební tabulkou vybírej, který je aktuální a platný, nad tím můžeš udělat view a současné sql na čtení se nebude muse měnit.Pokud více uživatelů upraví záznam, ten první bude brán jako platný a ta další úprava je konfliktní, uživateli řekneš, že již někdo před ním udělal úpravu a nabídneš mu automatický merge nebo ruční, ať si sám rozhodne, většinou není problém udělat diff a uživatele vést za ruku.Či můžeš nahodit websocket (či http/2) a dělat všechny úpravy live pro všechny prohlížející stejně jak funguje webový Google word, frameworků na to je již několik.Pokud bys vyloženě chtěl zůstat v současném stavu přepisování řádků s locky, za mě to je dost archaická cesta, která je uživatelsky problematická, ale můžeš to vyřešit tak, že lock má platnost třeba 5 minut a prohlížeč, kde je otevřen editační formulář bude každých 30s posílat na server ping a ten prodlouží lock o dalších 30s, že editace pořád probíhá, pokud okno prohlížeče zavře (či mu vypadne internet), lock se sám uvolní po 5 minutách, protože nepříjde ping. Doplň si tam sloupečky typu lock_until_timestamp, lock_author, lock_token. Lock_token bude obsahovat náhodný string, který vygeneruješ při otevření locku, dostane ho prohlížeč a funguje podobně jako csrf token, při uložení úprav se musí token v prohlížeči shodovat s tím, který je v db, tím ošetříš stav, kdy daný člověk po nějaké době se k článku vrátí (či otevře uspaný notebook) a chtěl by znovu editovat a přepsal by změny někoho jiného. Lock_author je jen pro informaci, kdo to má locknutý, aby se každý nemusel dokola ptát "kdo sakra na tom dělá", ale aby v případě problémů věděl koho kontaktovat. Všechny tyhle kontroly můžeš dělat přes ajax, takže informaci o tom, že mu již expiroval token či zrovna někdo dokončil editaci a už tam může udělat svoje změny můžeš editorovi zobrazovat rovnou a nemusí pořád klikat a čekat a zkoušet.Nepotřebuješ cron, stačí, když proces uvolnění, expirace a získání locku budeš dělat při každém přístupu k danému řádku, tj. i při čtení a pro získání článků k editaci můžeš mít podmínku typu "where ... lock_until_timestamp is null or lock_until_timestamp < now + interval 5 minutes". U cronu se ti může stát, že přestane běžet či přestane fungovat a celý systém se ti začne chovat divně a většinou to nedoporučuji.

koukám, že již Pavel Janků doporučil to co já :), sorry za duplicitu, měl jsem to rozepsané příliš dlouho :)

Napsal TomášX;1500785

existuje tzv. COW (copy on write), rádi to používají journalové file systémy. Nepřepisuj záznamy, ale vkládej nové a vazební tabulkou vybírej, který je aktuální a platný, nad tím můžeš udělat view a současné sql na čtení se nebude muse měnit.

Pokud více uživatelů upraví záznam, ten první bude brán jako platný a ta další úprava je konfliktní, uživateli řekneš, že již někdo před ním udělal úpravu a nabídneš mu automatický merge nebo ruční, ať si sám rozhodne, většinou není problém udělat diff a uživatele vést za ruku.

Či můžeš nahodit websocket (či http/2) a dělat všechny úpravy live pro všechny prohlížející stejně jak funguje webový Google word, frameworků na to je již několik.

Pokud bys vyloženě chtěl zůstat v současném stavu přepisování řádků s locky, za mě to je dost archaická cesta, která je uživatelsky problematická, ale můžeš to vyřešit tak, že lock má platnost třeba 5 minut a prohlížeč, kde je otevřen editační formulář bude každých 30s posílat na server ping a ten prodlouží lock o dalších 30s, že editace pořád probíhá, pokud okno prohlížeče zavře (či mu vypadne internet), lock se sám uvolní po 5 minutách, protože nepříjde ping. Doplň si tam sloupečky typu lock_until_timestamp, lock_author, lock_token. Lock_token bude obsahovat náhodný string, který vygeneruješ při otevření locku, dostane ho prohlížeč a funguje podobně jako csrf token, při uložení úprav se musí token v prohlížeči shodovat s tím, který je v db, tím ošetříš stav, kdy daný člověk po nějaké době se k článku vrátí (či otevře uspaný notebook) a chtěl by znovu editovat a přepsal by změny někoho jiného. Lock_author je jen pro informaci, kdo to má locknutý, aby se každý nemusel dokola ptát "kdo sakra na tom dělá", ale aby v případě problémů věděl koho kontaktovat. Všechny tyhle kontroly můžeš dělat přes ajax, takže informaci o tom, že mu již expiroval token či zrovna někdo dokončil editaci a už tam může udělat svoje změny můžeš editorovi zobrazovat rovnou a nemusí pořád klikat a čekat a zkoušet.

Nepotřebuješ cron, stačí, když proces uvolnění, expirace a získání locku budeš dělat při každém přístupu k danému řádku, tj. i při čtení a pro získání článků k editaci můžeš mít podmínku typu "where ... lock_until_timestamp is null or lock_until_timestamp < now + interval 5 minutes". U cronu se ti může stát, že přestane běžet či přestane fungovat a celý systém se ti začne chovat divně a většinou to nedoporučuji.

Pěkně rozepsané, ale 1. radou zavádíš revize, čímž nutno říct, že dost naroste databáze a potřeba prostředků. Nicméně je to určitě dobrá fičurka i pro účely auditování článků a možnosti revertu.Live editace ve stylu Google je trochu overkill myšlenka, takže mě ta představa celkem pobavila. Nicméně, co mě spíše zaujalo, je ta myšlenka diffu při konfliktu. Znáš na to nějakou knihovnu, kterou bys doporučil? Třeba přímo pro Symfony/Doctrine?Jinak ten lock systém je pěkně popsán, nějak takhle jsem to myslel :)

Napsal TomášX;1500785

existuje tzv. COW (copy on write), rádi to používají journalové file systémy. Nepřepisuj záznamy, ale vkládej nové a vazební tabulkou vybírej, který je aktuální a platný, nad tím můžeš udělat view a současné sql na čtení se nebude muse měnit.

Pokud více uživatelů upraví záznam, ten první bude brán jako platný a ta další úprava je konfliktní, uživateli řekneš, že již někdo před ním udělal úpravu a nabídneš mu automatický merge nebo ruční, ať si sám rozhodne, většinou není problém udělat diff a uživatele vést za ruku.

Či můžeš nahodit websocket (či http/2) a dělat všechny úpravy live pro všechny prohlížející stejně jak funguje webový Google word, frameworků na to je již několik.

...

ad Copy on write) Zajímavý koncept. Pokud to chápu správně, uchovává každou verzi a nechává tedy v databázi víc dat, na druhou stranu ale se dá jít u každého článku zpátky v historii a např. obnovit smazané pasáže. ad websocket) Zkoušel jsem se jen tak ze zajímavosti podívat na nějaké příklady: o té technologii se píše už někdy od roku 2009 a našel jsem si pár dotazů do Stack Overflow, které nebyly novější než z let 2013-14 a z pohledu dneška jsou už zastaralé. Na mém localhostu funkce websocket implicitně nefungovaly, musel jsem v konfiguraci patřičné přidat rozšíření. A poté mi v komunikaci bránil operační systém a nakonec antivirus, který mi preventivně smazal skript. :-| Zdá se, že pro řešení touto technologií musí člověk skákat skrze ohnivé obruče (nebo přinejmenším firewally) a protože to není teď můj problém, dál jsem tomu už čas nevěnoval. Ale přesto - protože se jedná o zcela novou koncepci toho, jak a kudy proutí data a informace - mohl bys načrtnout, jaká by byla struktura toho řešení a jak by mělo být implementované? ad http/2) Jak by vypadalo řešení pro http/2? Tatkéž - všichni píšete o konfliktu dvou uživatelů, ale.. jak by probíhal konflikt tří a více uživatelů?

tenhle koncept necháváním celé historie funguje ve velkých redakčních systémech, kde je nutné projít procesem schvalování, evidence a nějakého auditu, dnes jinak projekty nedodávám a nestavím.Konflikt 3 a více uživatelů lze vždy rozložit na konflikt dvou stran, viz jak to řeší GIT či obecně verzovací systémy. Máš nějaké base (ať už to je původní verze z které jsi vycházel nebo nová revize od někoho jiného) a k němu porovnáváš svoji konfliktní. Lepší systémy ti poté dokážou u jednotlivých pasáží uvést kdy došlo k její úpravě, kdo jí udělal a jestli je již live/schválená, viz třeba "git blame".Http/2 je náhrada websocketů, dnes již funkční napříč prohlížeči. Dříve se muselo uměle udržovat TCP spojení a dělat ajax long polling, dnes již http/2 umožňuje samo udržovat dlouhé spojení a JS stačí, když se bude každých pár vteřin ptát na nový obsah, pokud ho dostane, zobrazí ho. Webové editory s live collaborating existují a je jich poměrně hodně. Jeden z těch rozšířenějších je třeba https://c9.io (založen nad node.js)