COM Server bekommt keinen Schreib-Lese Zugriff auf Registry

[Michael Emmrich]

Hallo !
Ich möchte eine ASP Komponente schreiben, mit der ich Daten aus der Registry des Internetservers (IIS5) lesen und hineinschreiben kann. Ich verwende für den Zugriff auf die Registry eine LMD 5.x Klasse (LMDIniCtrl). Da die Komponente noch im Anfangsstadium ist, sind noch keine I/O Felder definiert, die Ausgabe erfolgt bislang ausschließlich über Response.Write. Allerdings kann ich die Registry nicht auslesen und auch keine Schlüssel erzeugen. Ist das ein Problem der Rechte ? Ich habe auf dem Testserver dem Ordner System32 und dem Dir des .asp Files umfangreiche Rechte für IUSR und Jeder und IWAM (Vollzugriff) eingeräumt - keine Besserung. Was mache ich falsch ? Der komplette Sourcecode liegt auf ftp-Server, Login Anonym, 62.116.131.41/ReadOnly . Vielen Dank für JEDEN Hinweis ! ! !

[Andreas Kosch]

Hallo,

auf dem o.g. FTP-Server sehe ich zwar das Unterverzeichnis <i>DerEntwicklerHilferuf...</i>, aber ich kommt dort nicht mehr hin :-(

Aus verständlichen Gründen sind alle Web-Anwendungen in der Voreinstellung in ihren Rechten beschränkt. Um nun einen erweiterten Zugriff auf die Maschine zu bekommen, gibt es verschiedene Möglichkeiten:

a) WAM <br>
Die Web-Anwendung (ASP-Verzeichnis) wird mit dem <i>Anwendungsschutz</i> <b>Hoch</b> versehen, so dass der WAM (Web-Application-Manager) des IIS5 eine COM+ Application einrichtet. Dort kann über den Eigenschaftsdialog ein Benutzerkonto ausgewählt werden, dessen Rechte ausreichen. Dieser generelle Weg hat allerdings Sicherheitsrisiken, da nun alle Webzugriffe diese Rechte haben.

b) ASP-Objekt <br>
In Delphi wird ein ASP-Objekt (COM-Objekt) entwickelt und in eine COM+ Application installiert. Dieser COM+ Application wird ein Benutzerkonto zugewiesen, das die notwendigen Rechte hat. Die ASP ruft nun nur noch das eigene ASP-Objekt auf, so dass die eingeschränkten Rechte der Web-Anwendung selbst nicht aufgebohrt werden müssen

[Michael Emmrich]

Lieber Herr Kosch !
Zunächst Vielen Dank für die prompte Antwort ! Allerdings bin ich noch zu blöd, genau zu verstehen, was Sie da schreiben - deshalb umschreibe ich mal, was ich hab:
die meUServe.dll (ActiveX dll aus Delphi) hat Vollzugriff für u.A. IUSR, IWAM, Jeder, SYSTEM.
Den gleichen "Zugriff" haben die Ordner WINNT, SYSTEM32 und INETSVR

Die Tests laufen derzeit in virtuellen Verzeichnissen, nicht in eigenen Webs. Die Rechte dort sind grundlegen sehr freizügig, Jeder darf Alles sozusagen - was in meinem lokalen Netzwerk ja auch noch egal ist - Hauptsache ich finde die Ursache für den fehlenden Registry-Zugriff.

Leider funktioniert Lösung a) (s.o.) nicht. Auch b), soweit überhaupt verstanden geht nicht. Die Eigenschaften der Registry-Komponente lassen sich auslesen, offenbar ist diese richtig instantiert. Vielleicht hab ich ja was ganz anderes übershen, was mit Rechten gar nix zu tun hat ? Bitte versuchen Sie nochmal, den Source zu laden, alternativ lege ich die Dateien auf: Sokotek.de -> Fernkorrektur -> Daten sehen -> DerEntwicklerHilferuf -> zip-Datei

Vielen Dank im voraus

[Michael Emmrich]

Hallo Herr Kosch !

Ich glaubs zwar nicht - aber könnte es daran liegen, daß die DLL unter XP-Prof. entwickelt wird und unter W2K laufen soll ??

[Andreas Kosch]

Hallo,

für Windows 2000 und den IIS 5 ist jedes virtuelle Webverzeichnis mit Ausführenrechten eine eigene Web-Application, die vom WAM kontrolliert wird. Im Eigenschaftsdialog des virtuellen Webverzeichnisses gibt es auf der Registerseite <i>Virtuelles Verzeichnis</i> im unteren Bereich die Konfigurations-Elemente für die Web-Anwendung. Über <b>Anwendungsschutzt</b> legt man fest, ob für dieses virtuelle Webverzeichnis (alias Web-Anwendung) eine eigene (konfigurierbare) COM+ Anwendung (siehe <i>Komponentendienste</i>) angelegt werden soll oder nicht.

Die entscheidende Frage bei <i>meUServe.dll </i> ist, <b>wie</b> dieses ActiveX unter Windows 2000 installiert/registriert wurde. Unter Windows 2000 sollte die DLL <b>nicht</b> über regsrv32 registriert werden, sonder statt dessen in eine neue COM+ Anwendung (siehe <i>Komponentendienste</i>) ínstalliert werden. Und dort legt man über den Eigenschaftsdialog (Registerseite <i>Identität</i>) das Benutzerkonto fest, unter dessen Rechten dieses ActiveX ausgeführt werden soll. Es geht also darum, unter <b>welchem Benutzerkonto</b> das ActiveX ausgeführt wird, und nicht um die Zugriffsrechte (denn die ergeben sich beim Benutzerkonto automatisch). Da nur die von dem ASP-Objekt (ActiveX) implementierten Interface-Methoden unter dem im Eigenschaftsdialog zugewiesenen Benutzerkonto ausgeführt werden (aber nicht die ganze Web-Anwendung), darf man unbesorgt das Administator-Konto für die COM+ Anwendung auswählen. Somit "darf" das ASP-Objekt (ActiveX) alles das machen, was auch der Administrator auf diesem Rechner machen darf

[Michael Emmrich]

B-I-N-G-O
<B>Vielen, vielen Dank !</B> Jetzt bleiben nur noch <B>1000</B> Fragen übrig ! Ich gebe ja gerne zu, daß ich die vielen Bücher in meinem Regal zu fast allen Themen nur Kapitelweise gelesen habe. Manches davon ist auch nur schwer zu verstehen - ich halte es auch schlicht für unmöglich, sich in allen betreffenden Themenbereichen von Rechtschreibung über HTML, JavaScript, ASP, Webseitenerstellung, Serveranwendungen, Win32 Anwendungen und was weiß ich was noch alles so gut auszukennen, daß man keine Probleme bekommt. Auch in dreien Ihrer Bücher (2x COM, 1x C/S) fand ich bislang keine detaillierte Anleitung zur Komponentenregsitrierung - vielleicht habe ich auch nur nie danach gesucht? <B>Woher bekommt man dieses Wissen - und wann weiß ich, wie ich eine dll registrieren muß ? </B> Welche Bücher zu diesem doch sehr speziellen Thema empfehlen Sie mir ?????</B>

Nochmals vielen Dank ! Ich denke, mit diesem Baustein und dem Wissen, wo er hin muß, ist für mich jetzt vieles mehr übers Web möglich geworden ! [email protected]

[Andreas Kosch]

Hallo,

in meinem Buch <i>COM/DCOM/COM+ mit Delphi</i> gehe ich auf den Seiten 880 bis 886 auf das Thema WAM, Anwendungsschutzt und Zugriffsrechte einer Web-Anwendung ein. Auf der Seite 885 stellt eine Abbildung die Verbindung zwischen WAM und COM+ anhand eines praktischen Beispiels dar.

Im COM+ Buch kümmert sich das ganze Kapitel 17 auf über 150 Seiten um die Komponentendienste (COM+ Anwendungen) von Windows 2000. Auf der CDROM zum Buch ist eine HTML-Datei mit einer Unmenge von Abbildungen, in der Schritt für Schritt jeder Handgriff aufgelistet wird, der für das Anlegen einer neuen COM+ Anwendung und die Installation eines COM-Objekt notwendig ist.

&gt;Woher bekommt man dieses Wissen - und wann weiß ich, wie ich eine dll registrieren muß ?

Ab Windows 2000 hat man die Qual der Wahl, ob ein COM-Objekt auf dem alten Weg (regsrv32) oder auf dem neuen Weg (COM+) registriert werden soll. Immer dann, wenn das eigene Objekt die neuen Features von COM+ ausnutzen möchte, muss das Teil in eine COM+ Anwendung installiert werden. Braucht man den neuen COM+ Kram nicht, wird die ActiveX-DLL auf dem klassischen Weg installiert.

P.S: Auf der MSDN Library DVD liefert Microsoft Unmengen von Dokumentationen zu diesem Thema aus

[Michael Emmrich]

Hallo Andreas,
Stimmt ! Ich habs nachgeschlagen - allerdings setzt die Lektüre doch ziemlich viel Zeit und Konzentration voraus, beides Dinge die meistens sehr knapp sind. Was ich nicht gefunden habe ist folgender Fall:

Die Delphi DLL wird als COM+ Komponente ausgeführt und erhält 4 Parameter (Username, Paßwort, IP-Adresse und SessionID). Die Prozedur in der DLL prüft nun Username und Paßwort und leitet je nach übereinstimmung auf eine error,asp oder eine auswahl.asp mit Response.Redirect um. Allerdings muß ich der auswahl.asp noch einen Paramater zum Abgleich mitgeben, die SessionID. Ruft man die auswahl.asp direkt ohne Parameter auf macht sie einen Redirect auf die error.asp, stimmt die SessionID mit dem Aufrufparameter überein, wird die auswahl.asp angezeigt. Im Augenblick kann ich die SessionID aus der DLL nur mit ?USI=... an den url anhängen. Ich möchte aber gerne ohne Frames arbeiten und den url ohne Anhang aufrufen, bzw. die SessionID die der DLL übergeben wurde nachträglich auslesen, eigentlich ist der Thread aber dann nicht mehr gültig bzw zerstört. Denke ich falsch ? Natürlich könnte ich SessionID in der Registry ablegen und über die global.asa beim Verlassen oder Session-Timeout wieder löschen... Welchen Weg gäbe es denn noch nach Rom ? (Vielleicht eine neue Variable im Sessionobjekt des Servers anlegen und dort ablegen

[Andreas Kosch]

Hallo,

der letzte Gedanke war der Beste. Das ASP-Objekt kann über TASPMTSObject direkt auf das <b>Application</b>- sowie <b>Session</b>-Objekt der ASP zugreifen und auf diesem Weg eigene Variablen auslesen/schreiben:
<pre>
function TUseAppVarObj.DoWork(const sInfo: WideString): Integer;
begin
// globale Variable für alle Sessions
Application.Value['MeineVariable'] := sInfo + ' (ASPUseVar)';
Result := 1;
{
// Session-bezogene Variable
Session.Value['MeineVariable'] := sInfo + ' (ASPUseVar)';
}
end;
</pre>
Der gleiche Zugriffsweg steht in der ASP zur Verfügung:
<pre>
Response.Write Application("MeineVariable")
</pre&gt

[Michael Emmrich]

Hallo Herr Kosch,
<p>Ich habs inzwischen über eine zwischengeschaltete ASP gemacht, die Session("PrivateSessionID") setzt und den Wert als url-Anhang von der Komponente kriegt. Ihr Weg ist allerdngs besser, da die SessionID nicht mit der url übergeben werden muß - ich muß das bei mir ändern. Danke