Zabezpieczenie - wartość parametru po zamknięciu okna przeglądarki

Cześć,

Potrzebuję porady co do jednego problemu. Apka klient-serwer. Java, javascript itd.
Mam aplikację, z której korzysta kilku user'ów jednocześnie.

Aplikacja ma np. Taski, które można edytować itd. W bazie danych jest pole status (active/edition).
No i jak tam klikamy w apce edycję Taska to nam w bazie zmienia status na edition. W momencie zakończenia edycji status jest zmieniany z powrotem na active.
Jak jakiś prosty sposób można zabezpieczyć to rozwiązanie dla przypadku gdy np. user1 otworzy okno edycji, parametr zmieni się na edition i zamknie okno przeglądarki. (wtedy status edition będzie wisiał i nie zmieni się samoczynnie na active)?
Myślę, bo są metody "window.onunload"/window.onbeforeunload, które niby się mają wywołać w takim przypadku, żeby zastosować do wywołania zmiany statusu na active.
Pierwszy raz spotykam się z takim problemem. Ma ktoś inne pomysły, jak można to prosto zrobić?

Batman109 napisał(a):

Jak jakiś prosty sposób można zabezpieczyć to rozwiązanie dla przypadku gdy np. user1 otworzy okno edycji, parametr zmieni się na edition i zamknie okno przeglądarki. (wtedy status edition będzie wisiał i nie zmieni się samoczynnie na active)?
Myślę, bo są metody "window.onunload"/window.onbeforeunload, które niby się mają wywołać w takim przypadku, żeby zastosować do wywołania zmiany statusu na active.
Pierwszy raz spotykam się z takim problemem. Ma ktoś inne pomysły, jak można to prosto zrobić?

Twoje pytanie to nie jest problem programistyczny, tylko problem użytkowy.

Sam sobie musisz odpowiedzieć na pytanie: "w którym momencie ma się zmienić status?", bo wygląda że sam nie wiesz.

• Czy jak user nagle wyłączy kompa, braknie mu prądu?
• Czy jak userowi nagle odłączy neta?
• Czy jak odejdzie od komputera?
• Czy jak będzie nieaktywny przez x minut
• Czy jak zmieni focus na inną kartę
• Czy jak zmieni focus na inne okno (np z Chrome na Firefox)
• Czy jak otworzy jakąś grę na fullscreen.
• Czy jak odświeży stronę?

Jak widzisz, problem wcale nie jest taki prosty jak się wydaje. W zależności od odpowiedzi na te pytania, wynikowe rozwiązanie będzie inne.

• Możesz użyć metod w JavaScripcie, żeby przeglądarka dała Ci znać kiedy jest zamykana, to może zadziałać. Jeśli problem jest urwanie prądu, nagłe odcięcie neta, to metodą chyba byłoby pingowanie/odpytywanie klienta co jakiś czas czy nadal jest aktywny, i jeśli nie jest, to zmienić status. Alternatywa to byłoby ciągłe połączenie, np przez websockety, i jeśli gniazdo servera wykryje zerwanie połączenia, to wtedy ustawia status na nieaktywny - ale to ma problem, bo wtedy nawet krótkotrwałe połączenia, np 2-4 sekundy byłoby uznane jako "zapisanie".

Jesteś w ogóle pewien że chcesz "blokować" dostęp do treści? Nie lepiej byłoby jakoś ogarnąć równoczesne zmiany?

@Riddle dobrze prawi.

Ja tylko dodam dwa pytania kontrolne.

1. Z jaką konsekwencją w systemie czy dla użytkownika ta sytuacja się wiąże? Umrze ktoś czy straci $$$ czy coś innego poważnego się stanie?
2. Czy taka sytuacja jest czymś "normalnym" w systemie i paraliżuje pracę innych użytkowników aplikacji?

Jeśli na któreś z pytań odpowiedziałeś nie, to niepotrzebnie się tym przejmujesz. No chyba, że to w ramach aplikacji pisanej dla sportu, żeby poćwiczyć jakieś edge case'y, to inna sprawa. Ale jak życie pokazuje czasem lepiej jest powiedzieć YOLO niż niepotrzebnie komplikować system - patrz Amazon i ich ignorancja w zakresie obsługi rzadkich sytuacji gdy klient zamówi produkt którego nie ma na stanie. Zamiast tworzyć kuloodporny system, który przy ich skali będzie nieutrzymywalny wolą wysłać mejla z przeprosinami i dać talon na ku.. eee kolejne zakupy :P

Faktycznie nietypowe.
Możesz to rozwiązać odwracając problem.
Niech raz na minutę javascript wysyła do serwera, że zadanie jest w trakcie edycji i zapisuj sobie czas ostatniego "ticka".
Teraz zadanie jest w edycji (logicznie) jeśli od ostatniego ticka minęło nie więcej niż np. 3 minuty.

I też zgadzam się z przedmówcą, że całość (ten status edycji/blokowanie) wygląda na niepotrzebną komplikację, która tylko będzie wkurzać użytkowników.

Pośrednim rozwiązaniem jest coś w stylu optimistic lock - pole version, które spowoduje, że pechowiec, który probuje zapisać jako drugi dostanie komunikat o błędzie - będzie wiadomo, że nastąpił konflikt.

jarekr000000 napisał(a):

Pośrednim rozwiązaniem jest coś w stylu optimistic lock - pole version, które spowoduje, że pechowiec, który probuje zapisać jako drugi dostanie komunikat o błędzie - będzie wiadomo, że nastąpił konflikt.

Optimistic locking to ostateczność, kiedy chcemy podmienić globalny stan. Nie zasugerowałbym tego chyba że nie ma innego wyjścia.