Access ADODB Connection

  • Hallo Zusammen,


    ich habe eine Access Accdb. Diese leigt im Netzwerklauf. Alle Benutzer haben hier nur Leserechte.

    Wenn der User das Script ausführt wird Aufgrund da er nur Leserechte hat nichts in die DB geschrieben.


    Ist es daher möglich der ADODB Connection ein User und PWD zu übergeben? Oder gibt es hier einen anderen Lösungsansatz, ohne dem User ändern Rechte zu geben?



    Danke


    Gruß gmmg

  • Zitat

    ich habe eine Access Accdb. Diese leigt im Netzwerklauf. Alle Benutzer haben hier nur Leserechte.

    Wenn der User das Script ausführt wird Aufgrund da er nur Leserechte hat nichts in die DB geschrieben.

    Dann liegt das Problem meiner Meinung nach nicht daran, dass der Access-Benutzer keine Schreibrechte hat, sondern daran, dass der Windows-Benutzer keine Schreibrechte hat. Liege ich da richtig? Wenn ja, müsste man dem ganzen evtl. ein #RequireAdmin voranstellen oder für das Verzeichnis der Access-Datenbank für alle Benutzer die es ausführen eine Windows-Freigabe erteilen.

    neben AutoIt jetzt auch noch in C/C++, Java und Python aktiv :)
    Stand 04.04.2018, 13:34

  • Ist es jetzt eigentlich ein Problem der Schreibrechte in die Datenbank oder in das Laufwerk?

    neben AutoIt jetzt auch noch in C/C++, Java und Python aktiv :)
    Stand 04.04.2018, 13:34

  • Danke für die Antworten.

    Wie geschrieben, hat der User nur Lese Rechte auf dieser Freigabe, deshalb sollte das Schreiben in die DB über einen anderen User gelöst werden.


    Gruß gmmg

  • Also über einen anderen Windows-User? Sorry, irgendwie stehe ich gerade auf dem Schlauch :/

    Dann evtl. #requireAdmin, RunAs() oder andere Freigabe.

    neben AutoIt jetzt auch noch in C/C++, Java und Python aktiv :)
    Stand 04.04.2018, 13:34

  • Mal so nebenbei... was genau ist dein Ziel, bzw. was erhoffst du dir davon einen anderen User für den Schreibzugriff zu verwenden?


    Du willst wohl verhindern, dass User Max.Muster manuelle Änderungen an der DB vornehmen bzw. vielleicht auch alle Daten aus der DB sehen kann, wenn er denn möchte.


    Wenn du jetzt aber einen anderen allgemeinen Schreibberechtigten User dafür verwendest kommst du nicht drum herum die Zugangsdaten im Script zu speichern.

    Das ist noch viel schlimmer als den oder die User direkt zu berechtigen, da du so bei Mißbrauch nicht einmal mehr feststellen kannst wer genau diesen allgemeinen Account nun benutzt hat.

    Die Zugangsdaten können durch Dekompilieren, ggf. durch einen Hex Editor oder durch diverse Sniffingtools mitgeschnitten werden. Davon ab bedeutet eine Änderung der Zugangsdaten auch automatisch, dass du die Scriptinstanzen auf den Nutzerrechnern aktualisieren musst.


    Sicherer ist es das schreibende Script mit den allgemeinen Zugangsdaten vom Userscript zu separieren.

    Das schreibende Script liegt irgendwo auf einem Server, wo der User keine Zugangsberechtigung hat, genauso wie er keine Zugangsberechtigung zur DB Datei hat.

    Das Userscript läuft auf dem Rechner des Users und kommuniziert mit dem Serverscript, z.B. über TCP und eine von dir definierte API. Der User kann also nix weiter tun als die von dir vorgesehenen Aktionen an das Serverscript zu senden. Alles andere wird verworfen.


    Wenn du protokollieren willst welcher User was an das Serverscript gesendet und letztlich indirekt an der DB geändert hat kannst du dies problemlos über das Serverscript tun. Hätte sogar den Vorteil, dass die Aktionen evtl. sogar granulär rückgängig gemacht werden können und der Verwantwortliche für die Fehlnutzung entsprechend geschult werden kann.

  • olfibits :

    misterspeed :


    Danke für eure Beteiligung. Richtig, ein normaler User hat nur Schreibrechte auf den Share Ordner. Daher wird ein Szenario benötigt, welches mir ermöglicht, das ich das Script mit User YX ausführe, welcher auf diesen Ordner Schreibrechte hat. Das Speichern der Zugangsdaten im Script sehe ich nicht als Problem, weil man dafür einen Dummy User nutzen kann, der dann nur auf diesem Share Ordner schreibrechte hat.

    Außerdem kann man die Zugangsdaten noch verschlüsselt ablegen.

    100% Sicherheit gibt es nicht, aber es sind auch keine Sicherheitsrelavante Daten im Script, es geht nur darum, dass der normale User nichts löscht, weil das kann er ja mit ändern rechten.


    Ich habe jetzt aber eine Lösung gefunden. Ich habe die Zugriffsrechte so angepasst, dass man schreiben darf, aber nicht löschen.


    Gruß gmmg