Zusammenarbeit mehreren Scrips auf mehreren Rechnern im Netzwerk ohne / oder mit verschlüsselter Textdatei

  • Hallo,

    ich möchte mehrere Script zusammenarbeiten lassen die allerdings auch auf mehreren Rechnern im Netzwerk laufen. Ich habe also einen Server auf den die Scripts als *.exe abgelegt sind. Mehrere Clients greifen per Verknüpfung auf den Server zu und führen die jeweilige *.exe aus. Funktioniert an sich ganz gut, allerdings arbeite ich zur Zeit mit einer Textdatei in der jeder rumfuschen kann.
    Hier mal ein Beispiel:

    Auf Server liegen Dateien: Schreiben.exe, Lesen.exe, file.txt

    Client1 führt Schreiben.exe aus. (Text = Testtext)

    Auf Server wird "Testtext" in file.txt in Zeile 1 geschrieben mit einem Absatz in Zeile 2.

    Client 2 führt Lesen.exe aus.

    Script ließt Anzahl der Zeilen aus und gibt die Zeilen nach und nach in einer MsgBox aus.



    Gibt es eine Möglichkeit, ohne der Textdatei zu arbeiten oder die Textdatei zu verschlüsseln, so dass nur das Script damit arbeiten kann und eine manuelle Änderung nicht möglich ist?

    Mit freundlichen Grüßen

  • Du könntest anstatt einer Textdatei eine Datenbank verwenden. Den Zugriff darauf kannst du dann ebenso steuern, als auch entsprechend die Änderungen.

    Ist nur die Frage ob für das Minimale, was du hier machst, sich eine Datenbank lohnt.

    Theoretisch bräuchtest du auch nur eine Exe, mit der du beides machen kannst (dann aber halt mit GUI).

  • Das ist nur ein Beispiel.
    Ich habe n kleines Internes Bestellprogramm geschrieben.

    Zurzeit wird alles in der Textdatei gespeichert. Da kommt dann rein:
    Name;Bestellung;Shop;Artikel;Artikelnummer;Kunde;Auftragsnummer;Priorität,BestätigtigVon

    und das je nach dem wieviele Bestellungen vorliegen.
    Dann geht es weiter in einer weiteren Textdatei für die Lieferungen wo was rein geschrieben wird.

    Und letztendlich eine Log.txt wo alles protokolliert wird.

    Wie funktioniert das mit einer Datenbank?
    Gibt Simples Beispiel. Vielleicht anhand meines Beispiels oben?


    Gruß

  • Naja, einfach ist relativ.

    Du musst einen Datenbankserver auf deinem Server installieren. Welche Datenbank (z.B. MYSQL) du nutzen möchtest/kannst hängt auch von Lizenzen etc. ab.

    Je nachdem welche Datenbank du nutzt sind die Zugriffe auch ein wenig anders umzusetzen.

    Da gehört schon ein bisschen mehr zu aber wenn das wirklich was mit Bestellungen zu tun hat (wenn auch nur intern) ist eine Datenbank generell, eine bessere Lösung.


    Du kannst im "Bestellprogramm" dann auch gewisse Sachen für den Besteller per Default (gespeichert in einer IN-Datei) eintragen lassen (z.B. Name, Kunde,...), damit dieser das nicht jedesmal selber eintippen muss. Aber das wäre

  • Wie funktioniert das mit einer Datenbank?
    Gibt es ein simples Beispiel. Vielleicht anhand meines Beispiels oben ?

    Du könntest mit Textdateien und FileLocks arbeiten, aber das wird (auch abhängig von der Datenmenge) irgendwann an Grenzen stoßen.


    Der Vorschlag von Moombas eine Datenbank zu nutzen ist besser !

    Datenbanken wie MySQL (besser MariaDB), MSSQL (Lizenzkosten) oder PostgreSQL erfordern aber einiges an Hintergrundwissen.

    Einen leichteren (nicht leichten ;)) Einstieg hättest Du mit SQLIte (wird von AutoIt gut unterstützt !).


    Ich weiß nicht wie gut Dein englisch ist, aber dies wäre z.B. eine hilfreiche und aktuelle Quelle :

    https://www.autoitscript.com/f…-from-multiple-computers/


    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."


  • SQLite ist aber IMHO nicht geeignet für Mehrbenutzer im Netzwerk

    Grundsätzlich wurde SQLite nicht als Client-Server DB konzeptioniert, da hast Du recht.


    Da ich mit SQLite bisher nur trivial und nicht im Netzwerk gearbeitet habe, möchte ich hier kein gefährliches Halbwissen verbreiten.

    Aus dem o.a. Link und z.B. :

    https://www.autoitscript.com/f…h-cooperative-semaphores/

    entnehme ich aber, dass das möglich ist (solange man kein Hochlastsystem betreiben möchte) .

    Wie funktioniert das mit einer Datenbank ?
    Gibt Simples Beispiel. Vielleicht anhand meines Beispiels oben ?

    Simpel ist ein dehnbarer Begriff ;).

    SQLite hätte einige Vorteile wie :

    • Leicht zu installieren und zu betreiben
    • breite Unterstützung seitens AutoIt
    • haufenweise Informationen
    • lizenzrechtlich unproblematisch

    Andere Systeme wie MariaDB, MySQL, PostgreSQL und Microsoft SQL Server Express (alle kostenlos) wären nach Deiner Definition sicher nicht simpel.

    Das ist nur ein Beispiel.
    Ich habe n kleines Internes Bestellprogramm geschrieben.

    Zurzeit wird alles in der Textdatei gespeichert. Da kommt dann rein:
    Name;Bestellung;Shop;Artikel;Artikelnummer;Kunde;Auftragsnummer;Priorität,BestätigtigVon

    Wo/wie werden denn z.Zt. die Artikel- und Kundendaten etc. gespeichert ?


    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."


  • Sorry, Musashi  
    Das geht eigentlich völlig am Thema vorbei. Es geht ihm nicht darum Schreibkonflikte zu überwinden, sondern die Daten vor Manipulation abzusichern.

    Funktioniert an sich ganz gut, allerdings arbeite ich zur Zeit mit einer Textdatei in der jeder rumfuschen kann.

    Gibt es eine Möglichkeit, ohne der Textdatei zu arbeiten oder die Textdatei zu verschlüsseln, so dass nur das Script damit arbeiten kann und eine manuelle Änderung nicht möglich ist?

    Eigentlich müsste zuerst das Sicherheitsbedürfnis noch einmal genauer geklärt werden. Geht es um absichtliche Manipulation?
    Dann ist als erstes das eingebundene Netzlaufwerk mit Schreibrechten raus. Wenn dann serverseitig sichergestellt ist, dass nur Select und Insert akzeptiert wird, kann man noch bei AutoIt bleiben, ansonsten ist auch das raus.

  • Eigentlich müsste zuerst das Sicherheitsbedürfnis noch einmal genauer geklärt werden. Geht es um absichtliche Manipulation?
    Dann ist als erstes das eingebundene Netzlaufwerk mit Schreibrechten raus. Wenn dann serverseitig sichergestellt ist, dass nur Select und Insert akzeptiert wird, kann man noch bei AutoIt bleiben, ansonsten ist auch das raus.

    Hallo, genau, es geht um absichtliche manipulation. Es gibt halt Kollegen die erlauben sich dann einen Spaß und ändern da irgendwas...

    Wenn ich allerdings den Ordner mit schreibrechte versehe, kann Autoit sicher auch nicht mehr darin etwas ändern?

    Gruß

  • Wenn ich allerdings den Ordner mit schreibrechte versehe, kann Autoit sicher auch nicht mehr darin etwas ändern?

    Genau.
    Dann wäre eher eine MySQL Datenbank auf einem nicht eingebundenen Laufwerk eine Lösung. Die Kontrolle der Schreibzugriffe, müsstest du serverseitig machen - da AutoIt-Code nicht geheim oder sicher ist. Ich meine - diese "Scherze" verstehe ich eh nicht. Aber wenn es um hohe Sicherheit geht, dürfen die User einfach keine direkte Kontrolle haben/erlangen können.

  • In wie fern nicht sicher. Ich mein aus der *.exe ist nicht so einfach ohne Kenntnisse den Code zu lesen oder?

    Ohne Kenntnisse so einfach nicht (zumindest wohl nicht für deine Spaßkollegen) aber möglich.

    Zugangsdaten etc. im AutoIt-Code abzulegen ist NICHT sicher !


    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."


  • Google einfach mal nach "decompile AutoIt". Man braucht keinerlei Programmierkenntnisse zum Dekompilieren und hat den Job mit Suche, Download und Ausführen wohl in weniger als fünf Minuten erledigt.. Danach muss man sich im Code zurechtfinden, was du mit dem AutoIt Code Stripper etwas erschweren kannst. Das spielt aber keine Rolle, wenn jemand dein Programm gar nicht verstehen will, sondern nur nach den Datenbankzugriffen sucht. Die Strings sind klar lesbar. Wenn du also wie Musashi schreibt Passworte speicherst oder auch denkst, ich muss das nicht serverseitig absichern, niemand sieht die Datenbankzugriffe, hast du verloren.

  • Wenn du also wie Musashi schreibt Passworte speicherst oder auch denkst, ich muss das nicht serverseitig absichern, niemand sieht die Datenbankzugriffe, hast du verloren.

    Yep ;) !

    Zitat von Joschy41 :

    "Hallo, genau, es geht um absichtliche Manipulation. Es gibt halt Kollegen die erlauben sich dann einen Spaß und ändern da irgendwas..."


    Ich meine - diese "Scherze" verstehe ich eh nicht. Aber wenn es um hohe Sicherheit geht, dürfen die User einfach keine direkte Kontrolle haben/erlangen können.

    Das sehe ich auch so !

    Joschy41 : Was ist das denn bitte für ein Laden (sorry), wo Mitarbeiter sich einen Spaß daraus machen Produktivprozesse zu manipulieren :cursing:. Da sollte dein(e) Chef(in) vielleicht mal die große Keule 'rausholen.


    Eine Verschlüsselung der Datei würde übrigens nichts bringen ! Deinen "Kollegen" geht es ja nicht um den Inhalt (der wäre an sich nicht extrem schutzbedürftig). Mittels (Hex-)Editor etc. lässt sich auch eine verschlüsselte Datei leicht 'kaputtmachen'.


    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."


  • Ansonsten ein ergänzender Vorschlag:

    Grundsätzlich:

    1. Idealerweise für jedes Feld eine Plausibilitätsprüfung (sofern möglich) durchführen. Das minimiert Blödsinneingaben oder Tippfehler.

    2. Den Windowsbenutzer + IP + Zeitstempel mit abspeichern. Dadurch solltest du auch zurückverfolgen können, wer sich da Späße erlaubt.

    3. Die Textdatei auf einem für die Benutzer unbekannten Server/Speicherort ablegen.

    4. Drohen, das Bestellungen bei zu häufigem Missbrauch persönlich, auf einem schriftlich auszufüllenden Zettel (nur beim Bearbeiter erhältlich) einzureichen sind... glaub mir das will KEINER.


    Irgendjemand wird ja die Bestellungen bearbeiten. Warum also nicht mit zwei getrennten "Bereichen" arbeiten:

    1. Ein Programm (Ich empfehle: mit GUI) für die Besteller, die in deine besagte Textdatei schreiben können.

    2. Ein separates Programm (für den Bearbeiter), welches die Bestellungen einließt und über den Bearbeiter erst in eine finale Datei (nicht zugängliche Datei für den Rest) schreibt. Quasi eine Freigabe der Bestellung mit der Möglichkeit diese auch gleich weiter zu verarbeiten.

    3. Sind falsche Angaben dabei kann man sie ggf. korrigieren oder nachhaken. Ist offensichtlicher Blödsinn dabei kann man den MA auch aus Nutzername + IP + Zeitstempel wahrscheinlich ermitteln und ermahnen.


    Dann würde es ohne Datenbank gehen, aber der Aufwand ist unwesentlich geringer und die Manipulationssicherheit geringer.


    Tipp: Ich kenne eure Abläufe nicht, aber ich würde generell dazu raten eingehende Bestellungen immer separiert zu betrachten und manuell "fix" zu übernehmen, auch wenn man mit Datenbanken arbeitet (z.B.: 1 Tabelle eingehend, 1 Tabelle in Bearbeitung, 1 Tabelle Archiv).

  • Hallo,

    Ich habe jetzt selbst mal versucht mein Script zu "decompilen". Innerhalb 5 Minuten habe ich zwar ein Programm gefunden, was aber ein Error ausgibt, bzw. 64 bit Dateien nicht unterstützt.

    Desweiteren schaffen es meine Kollegen höchstwarscheinlich nur rechte Maustaste auf die Verknüpfung zu machen und den Dateipfad öffnen zu lassen. Wenn die dort aber nicht finden, reicht das ja schon. Ich denke explizit danach zu suchen und das zu ändern, werden sie nicht.

    Beispiel: Wir haben ein Programm mit Namen, wo man sich umstellen kann in welchem Gebäude man sich auffhält. Geht man in dem Serverordner wo die Exe abgelegt ist findet man einen Ordner mit den Bildern der Personen. Dementsprechend wurden einige Bilder ausgetauscht und anschließend wieder Original benannt. Somit nimmt das Script ja die "Eigendlich falschen" Bilder.

    Sowas wollte ich halt vermeiden. Gelegentliche Späße verhindern.
    Jetzt denkt man sich, warum sollte das ein Spaß sein die BEstellung zu ändern. Keine Ahnung.
    Manche Leute versteht man einfach nicht.


    Nunja. Ich habe das ganze mit einem FTP realisiert.
    Das Script holt sich nun Textdateien vom FTP, bearbeitet diese, schiebt die auf dem FTP zurück und löscht sie Lokal.
    Das ganze passiert in weniger als eine Sekunde. Auch wenn sie dann herausfinden wo die Dateien Lokal abgespeichert werden, können sie trotzdem nicht die entscheidenen Dateien auf dem FTP ändern.

    Ich werde das glaube ich mal in einer Testphase bringen. Parallel sollten die jenigen die betreffende Person telefonisch kontaktieren.
    Mal schauen was passiert ^^


    Mit freundlichen Grüßen