Environment Variablen für den übergeordneten Prozess setzen?



  • Kennt jemand eine Möglichkeit, Environment Variablen für die Kommandozeile zu setzen, in dem das eigene (Konsolen-)Programm gestartet wurde?

    Die Situation ist folgende: Ich habe eine Client-Server Anwendung. Nun soll ein Kommandozeilen-Programm her, um bestimmte Sachen auch über die Kommandozeile erledigen zu können (die normale Anwendung ist mit GUI). Mein Problem ist die Benutzerverwaltung. Sämtliche Aktionen erfordern eine entsprechende Berechtigung. Also habe ich mir gedacht, ich schaue mir das einfach bei DB2 ab, denn das finde ich sehr elegant gelöst. Also will ich folgendes: Angenommen der Anwender will einen Kunden löschen. Dazu soll er eine Kommandozeile öffnen können und eingeben können (PROG sei mal der Name des Programmes):

    PROG anmelden als meine_user_id mit passwort mein_passwort
    PROG loesche kunde 4711

    Das heisst, die Benutzerrechte, die im ersten Programmaufruf ermittelt werden, müssten für den zweiten Aufruf des Programmes gespeichert werden, damit man nicht bei jedem Programmaufruf wieder Benutzer-ID und Passwort eingeben muss. Sie sollen solange gültig bleiben, bis die Konsole geschlossen wird.

    Ahh, habe ich mir gedacht, da bieten sich ja Environment-Variablen an. Also die Benutzerrechte verschlüsselt und Base64-Kodiert (damit's eine Zeichenkette ist) und einfach eine Environment-Variable damit angelegt. Das Problem ist nur, das die Environment-Variablen immer nur für den aktuellen Prozess gültig sind. Sobald das Programm beendet wird, ist die Variable wieder weg.

    Ich brauche jetzt irgendeine Möglichkeit die Environment-Variable für den Prozess der Konsole zu setzen, damit ich bei nachfolgenden Programmaufrufen wieder darauf zugreifen kann, eben z.B. um im obigen Beispiel zu prüfen, ob der User die Berechtigung hat Kunden zu löschen.

    Das Ganze ist für die Windows-Konsole.

    Wenn jemand eine andere Idee hat, wie man sowas lösen könnte, wäre ich auch sehr Dankbar.



  • Das Problem ist ja jenes, das du ganz einfach Daten erhalten willst, über die "Lebensdauer" deines Programms hinaus.

    Da bieten sich dann natürlich temporäre Dateien oder die Registry an.

    Ein Problem könnte es werden wenn du willst das die Daten gelöscht werden sobald jemand die Konsole schließt.

    Falls sowas in der Konsole geht, würde sich dann ein TSR eignen.

    Oder, falls das mit dem TSR klappt, könntest du das auch zur authentifizierung heranziehen und das TSR deine Daten speichern lassen.



  • Hmmm, TSR? Das ist mit Dos-Interupt und Assembler, gell? Ich glaube nicht, dass ich das will 🙂

    Das bringt mich aber auf eine andere Idee. Mal sehen, man könnte ja bei der Anmeldung einen weiteren Prozess klammheimlich und unsichtbar starten (detached), der die Daten der Anmeldung in einem Shared-Memory-Bereich hält. Das kann ja dasselbe Programm mit einem geheimen Parameter sein. Gleichzeitig könnte es auch die Konsole überwachen, indem es einfach einmal pro Sekunde nachschaut, ob sie noch da ist (geht vielleicht auch per WaitForSingleObject() mit dem Prozess-Handle, muss ich mal nachsehen). Ist die Konsole beendet, gibt das Hintergrund-Programm den Shared-Memory Bereich frei und beendet sich, und somit ist die Anmeldung gelöscht. Der Schard-Memory Bereich bekommt als Teil seines Namens die Prozess-ID der Konsole, damit sich zwei gleichzeitig geöffnete Konsolen nicht in die Quere kommen...

    Hmmm, ich denke das könnte klappen.

    Danke für den Denkanstoss 🙂


Anmelden zum Antworten