Programm Datenverifizierung

[Andidreas]

hallo zusammen...

bin grad etwas ideenlos, deshalb der beitrag ^^

ich hab ein programm das mit einer sqlite db arbeitet. die daten werden in files gespeichert die die sqlite anlegt.
ich hab nun das problem das manche benutzer auf die idee kommen und sich die db files sichern und später wieder zurückkopieren, d.h. sie arbeiten dann mit einer alten datenbasis...

wie kann man das programmtechnisch vermeiden das alte daten ins programmverzeichnis kopiert werden, würde gern eine sicherheitsprüfung beim programmstart einbauen...

zu berücksichtigen ist evtl. das dass programm nicht jeden tag verwendet wird...

für anregungen wär ich dankbar...

[mkinzler]

Nein. Verwende ein richtiges DBMS, dann kannst du den Server auf einem anderen Benutzer mit mehr Rechten laufen lassen.

[Andidreas]

Zitat:

Zitat von mkinzler (Beitrag 1150717)

Nein. Verwende ein richtiges DBMS, dann kannst du den Server auf einem anderen Benutzer mit mehr Rechten laufen lassen.

lol... das is ne aussage... meinst du nicht das ich ein dbms verwenden würde wenn es ginge?!

anyway die info hat in meinem post gefehlt... technisch ist es leider nicht möglich ein dbms einzusetzen welches auf einem server installiert ist...

[mkinzler]

Man kann auch ein lokales DBMS installieren ( Firebird, MSSQL express, ...)

[Andidreas]

Zitat:

Zitat von mkinzler (Beitrag 1150727)

Man kann auch ein lokales DBMS installieren ( Firebird, MSSQL express, ...)

mit firebird und mssql express kenn ich mich nicht aus...
aber ich denke die installation müsste vor ort von einer person an dem rechner vorgenommen werden und das ist leider ebenfalls nicht möglich, da die pc kenntnise bei den personen die das programm verwenden zu begrenzt sind... ich sags mal ganz unverblümt die wären zu doof dafür das ding zu installieren...

[mkinzler]

Die Installation von Firebird kann problemlos silent von einem Installer aus erfolgen.

[joachimd]

Zitat:

Zitat von Andidreas (Beitrag 1150714)

ich hab ein programm das mit einer sqlite db arbeitet. die daten werden in files gespeichert die die sqlite anlegt.
ich hab nun das problem das manche benutzer auf die idee kommen und sich die db files sichern und später wieder zurückkopieren, d.h. sie arbeiten dann mit einer alten datenbasis...

Du könntest nach Schliessen der DB über die Datei einen Hash ermitteln und separat speichern. Vor dem Öffnen prüfst Du diesen Hash.

[Andidreas]

Zitat:

Zitat von mkinzler (Beitrag 1150734)

Die Installation von Firebird kann problemlos silent von einem Installer aus erfolgen.

kann der installer auch über ein delphi programm gestartet werden?
nur zu meinem verständnis... firebird muss doch auch irgendwo files ablegen in denen die daten gespeichert werden... diese können doch auch über copy + paste verändert werden? oder nicht?!

Zitat:

Zitat von joachimd (Beitrag 1150737)

Du könntest nach Schliessen der DB über die Datei einen Hash ermitteln und separat speichern. Vor dem Öffnen prüfst Du diesen Hash.

über den hash kann ich dann aber nur prüfen ob die datei kopiert wurde oder nicht?!
das kopieren an sich kann man dadurch aber nicht abfangen oder?

[DeddyH]

Das Abfangen könntest Du wenn überhaupt wohl nur auf Dateisystemebene erledigen. Den Aufwand würde ich persönlich mir allerdings sparen: wenn ein Benutzer mit aller Gewalt Mist machen will, dann ist er auch selbst dafür verantwortlich. Du könntest höchstens Sicherungskopien anlegen, über den angesprochenen Hash prüfen, ob da kopiert wurde und zur Not die Kopie wiederherstellen.

[Luckie]

Zitat:

Zitat von Andidreas (Beitrag 1150742)

nur zu meinem verständnis... firebird muss doch auch irgendwo files ablegen in denen die daten gespeichert werden... diese können doch auch über copy + paste verändert werden? oder nicht?!

Aber nur von den Benutzern, die die nötigen Rechte dazu haben. Das sind in der Regel Administratoren. Arbeiten natürlich alle Benutzer als Administratoren, brauchst du keinen Gedanken an die Sicherheit verschwenden, die ist dann nämlich de facto nicht existent auf dem System. ;)

[Sir Rufo]

Ich weiß nicht, ob ich mir darüber groß Gedanken machen würde, den User so extrem vor sich selber zu beschützen ... wenn der da was "kaputt" machen will -> sein Problem.

Ich würde allerdings solche Daten auch an einem Ort speichern, der normalerweise für den User nicht sichtbar ist (AppData Local oder Roaming).

Wenn der da jetzt auch noch drin rumpfuscht, dann gibt es für den was auf die Mütze.

[DeddyH]

Zitat:

Zitat von Sir Rufo (Beitrag 1150769)

wenn der da was "kaputt" machen will -> sein Problem.

Zitat:

Zitat von DeddyH (Beitrag 1150744)

wenn ein Benutzer mit aller Gewalt Mist machen will, dann ist er auch selbst dafür verantwortlich.

Ich sehe, wir sind da einer Meinung ;)

[Andidreas]

Zitat:

Zitat von DeddyH (Beitrag 1150770)

Zitat:

Zitat von Sir Rufo (Beitrag 1150769)

wenn der da was "kaputt" machen will -> sein Problem.

Zitat:

Zitat von DeddyH (Beitrag 1150744)

wenn ein Benutzer mit aller Gewalt Mist machen will, dann ist er auch selbst dafür verantwortlich.

Ich sehe, wir sind da einer Meinung ;)

ich stimm euch da völlig zu... am anfang dachte ich auch die werden an sowas nicht rumspielen, aber die erfahrung zeigt das sies doch machen, und das doofe is das wir als IT dann wieder die daten irgendwie wiederherstellen müssen...
da die tools aber eh neu gemacht werden sollen, werd ich wohl in die richtung gehen das die daten irgendwo abgelegt werden wo se der user net findet...

lt. luckie geht das mit dem hash ja nur über admin rechte... gibt es noch andere alternativen?

[DeddyH]

Das hast Du wohl falsch verstanden, für den Hash brauchst Du keine Adminrechte.

[BUG]

Das Problem sehe ich hier:
In dem Moment, indem der User die Datenbank mit dem Backup überschreibt, ist diese verloren. Dem User dann noch mit einem Hashwert mitzuteilen, dass er etwas falsch gemacht hat, hilft niemanden.

Betrachte es mal anders: Anscheinend sucht der Kunde eine Möglichkeit ein Backup zu machen.
Also biete ihm eine an, die du kontrollierst.

1. der User kann ein Backup anlegen
2. der User kann ein Backup importieren, wenn es neuer ist
   (ansonsten nachfragen oder/und mergen)
3. außerdem kopierst du bei Programmende die jeweils aktuellste Datenbank an eine Stelle, die der User nicht findet/überschreibt
   (vielleicht auch alle aktuellen Versionszweige, wenn jemand sehr rumsaut)
4. wenn jetzt ein Nutzer eine alte Kopie zurückschreibt, gehst du vor wie bei 2. und gibst eine böse Fehlermeldung aus, so das er es nicht nochmal macht.

Das Datum der letzten Änderung schreibst du einfach in die Datenbank und in die Registry.

Wenn du das mergen geschickt realisierst, können die Benutzer sogar untereinander Datensätze tauschen.

[Sir Rufo]

Hmmm, ein Backup kann nur zurückgespeilt werden, wenn dieses neuer ist ... macht ja irgendwie keinen Sinn mit dem Backup :mrgreen:

Eine weitere Möglichkeit (zum Verstecken in den AppData-Foldern) wäre:

• Datei selber mit dem Attribute HIDE versehen
• Datei mit einem Schreibschutz versehen (beim Programmstart entfernen und am Ende wieder setzen)

Der Schreibschutz hält natürlich den "advanced" User nicht auf, diese Datei doch zu löschen, aber da kann keiner mehr sagen "aus Versehen"

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1150823)

Hmmm, ein Backup kann nur zurückgespeilt werden, wenn dieses neuer ist ... macht ja irgendwie keinen Sinn mit dem Backup :mrgreen:

Naja, neuer ist es, wenn es über Neuinstallation des Programms oder ein von einem Image neu aufgesetztem System geschrieben wird.
Ansonsten muss der User eben informiert werden, was er da tut oder sogar ein Zusammenführen der Datensätze angeboten werden.

[shmia]

Sqlite unterstützt eine Schema-Version und eine User-Version.
Da haben die Programmierer mal eine richtig gute Idee gehabt. :thumb:
Mit der Schema-Version kann deine Anwendung überprüfen, ob die Datenbank strukturiell neu genug ist.
Hier etwas Pseudecode:

Delphi-Quellcode:

if SchemaVersion < CURRENT_SCHEMA_VERSION then
   MsgBox('Achtung: Datenbankstruktur ist zu alt! Weitermachen auf eigene Gefahr.')
else if SchemaVersion > CURRENT_SCHEMA_VERSION + 3 then
   MsgBox('Achtung: Anwendungsprogramm könnte zu alt für die Datenbank sein.');

Die User-Version kannst du für eigene Zwecke benützen.
Bei jedem Programmende zählt deine Anwendung die User-Version um Eins hoch und speichert diesen Wert in einer Ini-Datei oder Registry.
Sollte beim Programmstart eine Abweichung zwischen dem gespeicherten Wert und der aktuellen User-Version gibt es einen Hinweis an den Benutzer.
Ausserdem wird in einem Flag gespeichert, dass es eine Abweichung gegeben hat.
Bei gesetztem Flag muss die Anwendung am Ende fragen ob die Datenbank als aktiv gelten soll;
falls User mit "Nein" antwortet unterbleibt das Hochzählen der User-Version.

[neo4a]

Bei kleinen DB hat sich bei mir folgender Ansatz bewährt:

- Erzeuge die DB (intern und dynamisch) immer neu (hier CDS).
- Öffne die gespeicherte DB (hier tempCDS).
- Kopiere die Felder etwa so:

Delphi-Quellcode:

  begin
    tempCDS := TClientDataset.Create(nil);
    sl      := TStringList.Create;
    try
      tempCDS.LoadFromStream(aStrStream);
      tempCDS.Open;
      sl.Text := tempCDS.FieldList.Text;
      while not tempCDS.Eof do
      begin
        CDS.insert;
        for i := 0 to CDS.FieldCount - 1 do
        begin
          s := CDS.Fields[i].FieldName;
          if sl.IndexOf(s) > -1 then
            CDS.FieldByName(s).Value := tempCDS.FieldByName(s).Value;
        end;
        CDS.post;
        tempCDS.Next;
      end;
      tempCDS.Close;
    finally
      sl.free;
      tempCDS.Free;
    end;

Vorteil dieser Methode: Man übernimmt, was nur geht und lässt weg, was nicht mehr geht. Natürlich kann man den Ansatz auch etwas anpassen und zuvor erst einmal so den Strukturunterschied feststellen, den Anwender fragen, was zu tun ist, und entsprechend weiter gehen.

[Luckie]

also ich bin davon abgekommen extra Sicherheitsmaßnahmen zu ergreifen. Ich mache nur das was das OS von sich aus hergibt. Wenn der Benutzer eine Linux-Live-CD einschiebt und die Daten löscht...selber schuld. Ich meine Autohersteller haben auch keine Sicherheitsmaßnahmen, dass man keinen Zucker in den Tank schütten kann oder sich selbst die Bremsschläuche durchschneiden.

[Andidreas]

Zitat:

Zitat von shmia (Beitrag 1150873)

Sqlite unterstützt eine Schema-Version und eine User-Version.
Da haben die Programmierer mal eine richtig gute Idee gehabt. :thumb:
Mit der Schema-Version kann deine Anwendung überprüfen, ob die Datenbank strukturiell neu genug ist.
Hier etwas Pseudecode:

Delphi-Quellcode:

if SchemaVersion < CURRENT_SCHEMA_VERSION then
   MsgBox('Achtung: Datenbankstruktur ist zu alt! Weitermachen auf eigene Gefahr.')
else if SchemaVersion > CURRENT_SCHEMA_VERSION + 3 then
   MsgBox('Achtung: Anwendungsprogramm könnte zu alt für die Datenbank sein.');

Die User-Version kannst du für eigene Zwecke benützen.
Bei jedem Programmende zählt deine Anwendung die User-Version um Eins hoch und speichert diesen Wert in einer Ini-Datei oder Registry.
Sollte beim Programmstart eine Abweichung zwischen dem gespeicherten Wert und der aktuellen User-Version gibt es einen Hinweis an den Benutzer.
Ausserdem wird in einem Flag gespeichert, dass es eine Abweichung gegeben hat.
Bei gesetztem Flag muss die Anwendung am Ende fragen ob die Datenbank als aktiv gelten soll;
falls User mit "Nein" antwortet unterbleibt das Hochzählen der User-Version.

gute idee, danke für den tipp

Zitat:

Zitat von Luckie (Beitrag 1150897)

... Ich meine Autohersteller haben auch keine Sicherheitsmaßnahmen, dass man keinen Zucker in den Tank schütten kann oder sich selbst die Bremsschläuche durchschneiden.

da is auch was dran... aber sofern möglich versuch ich meine programm so sicher wie möglich zu machen ;-)