Prosty sposób na oznaczenie/podpisanie dokumentu?

Witam

Potrzebuję pomysłów na to jak "ostemplować" dany dokument?
Nie może to być podpis elektroniczny.

Np. jak ktoś akceptuje w obiegu jakiś dokument to żeby jakoś go oznaczyć i powiązać z tą akceptacją zalogowanego użytkownika?
Może jakaś kombinacja z tokenami?

Czekam na propozycje.

Nie rozumiem pytania

Jakieś formy "podpisu dla ubogich" prowadziły by do hashowania dokumentu, danych czasowych i danych użytkownika

@AnyKtokolwiek: dostałem takiego "kejsa" w pracy...

Chodzi tutaj bardziej o oznaczenie, że "dokument", który jest przechowywany w bazie SQL jak tabela został zaakceptowany przez danego użytkownika.
I żeby to było jakoś tak no... nawet nie wiem jak to nazwać :P

to jak masz dokument w bazie to co za problem dorobić tabelę powiązaną a tam już od metra kolumn oznaczony, oznakowany, podstemplowany, obejrzany itd.

I hash zawartości wiersza., data z godziną.

bo chyba nie wszyscy zrozumieli

1. założenie jest takie, że dokument mamy w bazie (nieważne czy jako blob w rekordzie czy jako stream do którego mamy link w rekordzie)
2. jakiekolwiek zmiany w dokumencie (dodanie dokumentu / zmiana treści / usunięcie) TYLKO przez aplikację
   dwa powyższe gwarantują nam tylko i aż jedno - mamy pełną kontrolę nad czasem życia dokumentu oraz możemy sobie wersjonować jego zmiany. Jeśli powyższe jest osiągalne to teraz tak: mamy trzy tabele - documents users actions. w documents mamy wersjonowane dokumenty, w users mamy userów (te dwie to tak dla niepoznaki :p) a w actions mamy wiele do wielu - powiązanie konkretnej wersji dokumentu z użytkownikiem i jako opis/status/cokolwiek właśnie ten nieszczęsny status, np. user A zobaczył doc B albo user X dodał doc D. Można dodać datę do tabeli ze statusami. Nie trzeba żadnego hasha, dokument może oglądać dowolna liczba userów (i dla każdego się ten fakt odnotuje) itd., itp.

Hash to IMO mus ale zalezy od wymagan, ktorych nie znamy. Jesli to np. zamowienie, ktore ktos generuje, ktos akceptuje i potem ktos realizuje to wersjonowanie niepotrzebne a hash potrzebny i / lub jakaś logika blokująca edycje po zatwierdzeniu.

jacek.placek napisał(a):

Hash to IMO mus ale zalezy od wymagan, ktorych nie znamy. Jesli to np. zamowienie, ktore ktos generuje, ktos akceptuje i potem ktos realizuje to wersjonowanie niepotrzebne a hash potrzebny i / lub jakaś logika blokująca edycje po zatwierdzeniu.

chociaż jeden argument za tym, że a hash potrzebny, biorąc pod uwagę punkt 1 i 2 z mojego poprzedniego postu

Może tych punktów nie być w systemie.
Co mi po wersjonowaniu jeśli np
dyrektor zatwierdził inne zamówienie niż zostanie wysłane do dostawcy? No ale to wymyślanie bo ja nie wiem do czego to służyć.

to przed czym hash ratuje w takiej sytuacji?

Pomaga kontrolowac czy to co jest zatwierdzone to to samo co ktos chce wyslac do realizacji.
Edit
Poza tym hash do czego innego służy niz wersjonowanie w tym kontekście.

jeśli dane kontroluje aplikacja i pozwala na takie rzeczy to żaden hash nie pomoże. Tak samo jeśli ktoś zacznie grzebać ręcznie w bazie

No właśnie pomoże. Jak ktoś zmieni coś w bazie to funkcja wysyłając zamówienie obliczu hash, sprawdzi czy taki sam jak hash zatwiedzonego i zablokuje w przypadku zmian.

chyba, że ktoś zmieni hash w bazie...

Nie zartuj. Niepotrzebnie pisałem o zmianach w bazie.

Sproboj silniejszy algorytm ,ktory da wieksza roznorodnosc. Poczytaj jak mozna sygnature wygenerowac. Możesz spróbować zrobić tak jak jest implementacja unique key (poszukaj co to za identyfikator , ps micro$oft go zrobil... pzdr.

Jeśli po drodze jest kilku akceptorów to co mi da hash ?