Probleme mit DCOM

[jelzi]

Ich habe einen DCOM Server entwickelt, der auch super läuft...
Ein einziges Problem gibt es doch und es ist nicht unbedeutend.
Auf die Serveranwendung sollen relativ viele Clients zugreifen.
Das Problem ist, dass die Serveranwendung bei jedem Client in der Registry eingetragen werden muss.
Die Benutzer auf den Clients, welche diese Anwendung nutzen sollen, haben aber lediglich eingeschränkte Rechte.
Die Serveranwendung wird in die Registry eingetragen, sobald es noch nicht der Fall ist, damit eine Instanz der Serveranwendung auf dem Serverrechner erzeugt wird.
Die Benutzer haben aber kein Recht einen Eintrag in der Registry vorzunehmen und das ganze scheitert an dieser "Kleinigkeit".
Hat vielleicht irgendein Kollege mit diesem Problem bereits gekämpft und evtl. eine Lösung gefunden??

Grüße

[Bernhard Geyer]

Zitat von jelzi:

Die Benutzer haben aber kein Recht einen Eintrag in der Registry vorzunehmen und das ganze scheitert an dieser "Kleinigkeit".

Das ist keine "Kleinigkeit" sondern eine der Hauptnachteile von COM. Es müssen Registrierungen (unter Admin-Rechten) in der Registry vorgenommen werden. Und da Delphi nur den Standard-Marschaler verwendet, ist dies auch nicht AFAIK zu umgehen.

"Nachfolgetechniken" wie SOAP haben diesen Nachteil nicht mehr.

[sakura]

DCOM Server können über die Verwaltung -> Komponenten Dienste (anstatt RegSvr32) installiert werden. Dabei kann man angeben

1. Wer die COM-Objekte starten darf, und
2. unter wessen Konto diese dann ausgeführt werden

Damit ist dann auch das Problem der Berechtigung auf die Registry gelöst.

Zitat von Bernhard Geyer:

"Nachfolgetechniken" wie SOAP haben diesen Nachteil nicht mehr.

Das hat auch nichts mit der Technik zu tun, sondern mit dem Account unter welchem der Host, welcher die Funktionen anbietet, läuft. Auch SOAP-Server haben keine Garantie, dass diese auf die Registry zugreifen können. Wäre ja schlimm.

......

[Bernhard Geyer]

Zitat von sakura:

DCOM Server können über die Verwaltung -> Komponenten Dienste (anstatt RegSvr32) installiert werden. Dabei kann man angeben

1. Wer die COM-Objekte starten darf, und
2. unter wessen Konto diese dann ausgeführt werden

Damit ist dann auch das Problem der Berechtigung auf die Registry gelöst.

Wirklich? COM-Anwendungen erfordern einen Eintrag unter HKEY_LOCAL_MACHINE. Und dies ist AFAIK auch bei dieser Lösung nötig. Und unter HKEY_LOCAL_MACHINE hat nicht jeder einen Schreibzugriff.

Zitat von sakura:

Zitat von Bernhard Geyer:

"Nachfolgetechniken" wie SOAP haben diesen Nachteil nicht mehr.

Das hat auch nichts mit der Technik zu tun, sondern mit dem Account unter welchem der Host, welcher die Funktionen anbietet, läuft. Auch SOAP-Server haben keine Garantie, dass diese auf die Registry zugreifen können. Wäre ja schlimm.
......

Es geht ja nicht um den Server, sondern um den Client. Und dort ist (bei vernünftiger Wahl des Realisierungswegs kein Eintrag in der Registry nötig.
Auch auf dem Server ist (je nach Realisierungsweg) kein Schreibzugriff auf die Registry (HKEY_LOCAL_MACHINE) nötig.

[sakura]

Vergesst was ich getippt habe, ich hatte es falsch verstanden. Ich dachte, der Server soll (warum auch immer ) jeden zugreifenden Client in der Registry speichern... Unter den mir jetzt klar gewordenen Gesichtspunkten ist mein Vorschlag dumpfsinnig

Jetzt kann man aber dem COM-Server mithilfe des MS SOAP ToolKit in einen SOAP-Server umwandeln und dann die Clients via Seifenanbindung arbeiten lassen - damit ist immerhin der Server der alte. Allerdings müssten die Clients angepasst werden

......

[jelzi]

Zitat von Bernhard Geyer:

Es geht ja nicht um den Server, sondern um den Client. Und dort ist (bei vernünftiger Wahl des Realisierungswegs kein Eintrag in der Registry nötig.
Auch auf dem Server ist (je nach Realisierungsweg) kein Schreibzugriff auf die Registry (HKEY_LOCAL_MACHINE) nötig.

würd mich interessieren ein wenig mehr darüber zu erfahren .. nach meinem Wissen ist es zwingend notwendig für DCOM

[Bernhard Geyer]

Zitat von jelzi:

Zitat von Bernhard Geyer:

Es geht ja nicht um den Server, sondern um den Client. Und dort ist (bei vernünftiger Wahl des Realisierungswegs kein Eintrag in der Registry nötig.
Auch auf dem Server ist (je nach Realisierungsweg) kein Schreibzugriff auf die Registry (HKEY_LOCAL_MACHINE) nötig.

würd mich interessieren ein wenig mehr darüber zu erfahren .. nach meinem Wissen ist es zwingend notwendig für DCOM

Ist es ja auch für (D)COM (wie in meinem ersten Posting zu lesen).

Bei SOAP ist dies prinzipbedingt nicht nötig (Schreibrechte auf HKEY_LOCAL_MACHINE). Evtl. hat das MS SOAP-Toolkit hier einschränkungen. Aber damit hatte ich noch nicht zu tun.

[jelzi]

Da ich jetzt ziemlich viel Zeit damit verbracht habe, möchte ich nicht das Projekt über Board werfen.
Ich habe jetzt von der Funktion CreateProcessWithLogonW erfahren mit der ich einen Prozess unter einem anderem Benutzer starten kann. Damit könnte ich mit den AdminRechten den Prozess zur Registrierung der Serveranwendung auf dem Client starten. Ich bekomme die Funktion aber nicht zum laufen

dazu verwende ich den folgenden Quellcode

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var  
  si: STARTUPINFOW;
  pif: PROCESS_INFORMATION;  
  res: Bool;
  s: string;
begin
  si.cb := SizeOf(startupinfow); 
  si.dwFlags  := STARTF_USESHOWWINDOW; 
  si.wShowWindow := SW_SHOWDEFAULT;
  si.lpReserved := nil;
  si.lpDesktop := nil;
  si.lpTitle := 'Konsole';

  res := CreateProcessWithLogonW(username, domain, userpass, LOGON_WITH_PROFILE,
    'e:\projekte\runas\runas.exe', nil
    , CREATE_DEFAULT_ERROR_MODE, nil, nil, si, pif);


  if booltostr(res) = '0' then
  begin 
   //this code can be 'translated' with 'net helpmsg ' on command-prompt 
    str(GetLastError, s); 
    ShowMessage('CreateProcessWithLogonResult: ' + booltostr(res) + #10 + 
      'GetLastError: ' + s); 
  end;

end;

Ich bekomme ständig als Antwort den Fehler 87, was übersetzt "falscher Parameter" bedeutet ..
Was mache ich falsch ?