nicht angemeldet
Hi,
danke Euch beiden für Eure Antworten. Hat mir sehr geholfen.
- Habe mir Trigger und Stored Prozedures angeschaut. Der Unterschied wäre ja, dass man einen Trigger (Bsp. Select, Insert) anlegt und einer Tabelle zuordnet. Sobald nun ein Select auf diese Tabelle erfolgt, wird der Trigger aufgerufen.
weniger von einem SELECT, mehr von DML befehlen wie INSERT, UPDATE und DELETE.
Bei Stored Prozedures hingegen, wird die Prozedur von der Applikation aufgerufen, die dann erst den Select, Insert, was auch immer aufruft.
es muss nicht immer eine applikation sein, die eine stored procedure aufruft. jeder der auf irgendeine weise zugriff auf die datenbank hat und die sp ausführen darf, kann sie aufrufen.
verstehe. Ich könnte praktisch für alle Benutzer einer bestimmten Tabelle die DML Befehle verbieten (GRANT) aber Stores Prozedures erlauben. Von einer Applikation oder ein Benutzer könnte dann nur bestimmte gespeicherte SP ausführen. Ob das Sinn macht oder nicht, weiß ich jetzt nicht, da man in den SP ja auch viel mist in die Variablen einfügen kann.
Ansonsten habe ich mich noch informiert, wie man Java-Klassen schützen kann. Diese seien aber nur bedingt schützbar, da man im Endeffekt den Maschinencode in den Registern, Prozesse und Speichern per Reverse Engineering mit viel Mühe etwas aufschlüsseln kann.
Ich frag mich aber, was man mit solchen Befehlen anfangen kann? Daraus kommt man ja schlecht zu nem Programm oder wenn dort Zahlen addiert oder so werde auf Maschinencodeebene?
Bzgl. der Datenbankauthentifizierung, die man im Code dann hat, kann man dann genauso wenig machen. Hart in den Code reinschreiben, einen Obfuscator drüberlaufen lassen, dann hätte man sich etwas von Ahnungslosen gesichert, die nur die Klassen decompilieren können.
Grüße