Anmelden an Webmodul über IdHTTP

[nahpets]

Hallo Thom,

nö, funktioniert nicht.

Der Datenaustausch zwischen Webserver und DLL erfolgt über den TEXTENSION_CONTROL_BLOCK. In Delphi 7 ist er so definiert:

Delphi-Quellcode:

 TEXTENSION_CONTROL_BLOCK = packed record
    cbSize: DWORD;                    // size of this struct.
    dwVersion: DWORD;                 // version info of this spec
    ConnID: HCONN;                    // Context number not to be modified!
    dwHttpStatusCode: DWORD;          // HTTP Status code
             // null terminated log info specific to this Extension DLL
    lpszLogData: array [0..HSE_LOG_BUFFER_LEN-1] of Char;
    lpszMethod: PChar;                // REQUEST_METHOD
    lpszQueryString: PChar;           // QUERY_STRING
    lpszPathInfo: PChar;              // PATH_INFO
    lpszPathTranslated: PChar;        // PATH_TRANSLATED
    cbTotalBytes: DWORD;              // Total bytes indicated from client
    cbAvailable: DWORD;               // Available number of bytes
    lpbData: Pointer;                 // pointer to cbAvailable bytes
    lpszContentType: PChar;           // Content type of client data

    GetServerVariable: TGetServerVariableProc;
    WriteClient: TWriteClientProc;
    ReadClient: TReadClientProc;
    ServerSupportFunction: TServerSupportFunctionProc;
  end;

Zu finden in der \source\rtl\win\Isapi2.pas.

Die Werte aus diesem Block werden letztlich mit dieser Routine gelesen:

Delphi-Quellcode:

function TISAPIRequest.GetStringVariable(Index: Integer): string;
begin
  case Index of
    0: Result := ECB.lpszMethod;
    3: Result := ECB.lpszQueryString;
    4: Result := ECB.lpszPathInfo;
    5: Result := ECB.lpszPathTranslated;
    1..2, 6..24, 26..28: Result := GetFieldByName(ServerVariables[Index]);
    25: if ECB.cbAvailable > 0 then
      SetString(Result, PChar(ECB.lpbData), ECB.cbAvailable);
   else
      Result := '';
  end;
end;

Die möglichen, zu lesenden Werte sind:

Delphi-Quellcode:

const
  ServerVariables: array[0..28] of string = (
    '',
    'SERVER_PROTOCOL',
    'URL',
    '',
    '',
    '',
    'HTTP_CACHE_CONTROL',
    'HTTP_DATE',
    'HTTP_ACCEPT',
    'HTTP_FROM',
    'HTTP_HOST',
    'HTTP_IF_MODIFIED_SINCE',
    'HTTP_REFERER',
    'HTTP_USER_AGENT',
    'HTTP_CONTENT_ENCODING',
    'CONTENT_TYPE',
    'CONTENT_LENGTH',
    'HTTP_CONTENT_VERSION',
    'HTTP_DERIVED_FROM',
    'HTTP_EXPIRES',
    'HTTP_TITLE',
    'REMOTE_ADDR',
    'REMOTE_HOST',
    'SCRIPT_NAME',
    'SERVER_PORT',
    '',
    'HTTP_CONNECTION',
    'HTTP_COOKIE',
    'HTTP_AUTHORIZATION');

Es ist mir bisher nicht gelungen, an andere Werte zu kommen.

Ist dieser Kommentar aus der Isapi2.pas eventuell von Bedeutung?

Delphi-Quellcode:

{       Structure definitions and prototypes for the    }
{       version 2.0 HTTP Server Extension interface.    }

Sprich: Hat sich da in der Version was verändert?

Irgendwie weiß ich momentan nicht weiter. Die Anmeldedaten sind in einer DLL wohl sehr geheim

[Thom]

Wahrscheinlich...

Ich habe jetzt nach etlichen Mühen Delphi 7 unter Windows Server 2008 zum Laufen bekommen. Dummerweise akzeptiert der IIS nur 32- oder 64Bit Dll's, so daß ich den ganzen Rest auch noch mal "schnell" nach 32Bit umsetzen mußte.

Die gute Nachricht: Die Anmeldung funktioniert auch mit einer ISAPI-Dll, die mit Delphi 7 kompiliert wurde. Das kannst Du hier testen.

Die schlechte Nachricht: Ich habe momentan absolut keine Idee, weshalb das bei Dir nicht funktioniert.
Könntest Du eventuell mal Deine Dll (Quelltext) hier posten, damit ich die bei mir ausprobieren kann?

[nahpets]

Hallo Thom,

Quelltext und kompilierte DLL als Zip.
Die DLL ist kein Meisterwerk in objektorientierter oder sauberer Programmierung, sondern so dahingedaddelt und teilweise aus Textlisten generiert. Tut halt

Könnte es sein, dass unterschiedliche Webserver hier die Daten nach "gutdünken" weitergeben?

Nach weiterem Suchen in diversen Quelltexten habe ich herausgefunden, dass ich bei meinem Webserver und meiner DLL den Benutzernamen in der Servervariabel AUTH_NAME und das Passwort in AUTH_PASS finden kann. Ob das aber immer so ist oder so sein muss, kann ich nicht sagen.

Würde mich schon interessieren, ob Du mit dieser DLL die Werte an den gleichen Stellen bekommst oder das mit dem IIS alles irgendwie anders ist. Dann muss ich in meinem Webserver nämlich wohl doch noch ein paar Fehler beheben

[Thom]

Hallo Stephan,

ändere mal im Quelltext folgenden Abschnitt:

Delphi-Quellcode:

  [...]
  if N > 0 then begin
    Delete(S,1,n);
    S := TIdDecoderMIME.DecodeString(S);
    N := Pos(':',S);
    if N > 0 then begin
      sAuthorization := Format('Username: %s'+ sLineBreak +'Password: %s',[Copy(S,1,N-1),Copy(S,N+1,Length(S)-N+1)]);
    end;
  end else //<- ab hier zusätzlich
  begin
    Response.WWWAuthenticate := 'Basic';
    Response.StatusCode := 401;
    Exit;
  end;
  [...]

Ansonsten fordert der Server keine Autorisation an und damit wird diese auch nicht angezeigt. Im Feuerfuchs funktioniert das auch mit Username:Password@xyz.

P.S.: Test hier.

[nahpets]

Hallo Thom,

Danke für die viele Mühe die Du Dir bei der Probelmlösung machst.

Auf dem IIS hast Du quasi meine DLL eingebunden, die Ergebnisseite ist bei Dir deutlich "besser" mit Informationen gefüllt, als bei mir. D. h.: Mein Webserver gibt (warum auch immer) nicht alle Informationen preis. Da ich für das ganze nur die Indy-Komponenten sowie idRunner components v. 3.4 nutze, muss ich die Ursache (vermutlich) dort irgendwo suchen oder eine Stelle finden, an der ich die Informationen gezielt "einstreuen" kann.

Die Änderung an der DLL bringt bei mir keinen Vorteil, im Gegenteil, die Methode wird immer im neuen Else-Zweig verlassen, so dass ich nie ein Ergebnis zu Gesicht bekomme. Der Webserver fordert aber die Anmeldung an und protokolliert die erfolgreiche Anmeldung.

Das sieht im Protokoll dann so aus:

Code:

HTTPServer | 2013.04.10 23.49.45,453 | 127.000.000.001:4068 | stephan | GET /scripts/webmodul.dll/request
HTTPServer | 2013.04.10 23.49.45,453 | 127.000.000.001 | localhost | erlaubter Zugriff mit IP-Security
HTTPServer | 2013.04.10 23.49.45,500 | Login ok | Benutzername: stephan
HTTPServer | 2013.04.10 23.49.45,625 | 127.000.000.001:4068 | stephan | GET .\scripts\webmodul.dll | 4375 | 200 | text/html

Da mein Webserver nicht aus der großen weiten Welt zu sehen ist, sondern nur lokal genutzt wird, habe ich mal die Ergebnisseite, wie sie sich hier darstellt, drangehängt.

[Thom]

Hallo Stephan,

das sieht ja wirklich recht spartanisch aus...

Da ich die idRunner-Komponenten nicht kenne, kann ich leider dazu nichts sagen. Aber irgendwie scheinen die einen großen Teil der Informationen zu verschweigen. Normalerweise sollten alle Informationen, die vom Klienten kommen, auch im Rohformat an die ISAPI-Dll durchgereicht werden, so daß sie über die entsprechenden Anweisungen ausgelesen werden können. Wenn hier schon Request.GetFieldByName('ALL_RAW'); versagt, stimmt etwas nicht. Insofern scheint das ISAPI nicht vollständig unterstützt zu werden.

Wahrscheinlich hilft nur debuggen, da - so weit ich jetzt gelesen habe - diese Komponenten nicht weiterentwickelt werden.

[nahpets]

Hallo Thom,

jo, da muss ich dann nochmal ran, es war schon ein erheblicher Aufwand die Komponenten soweit anzupassen, dass sie nun mit Indy 10 genutzt werden können. Bei den Indy-Komponenten ist wohl irgendwann zwischen Indy 8 und Indy 10 erhebliches geändert worden.

Im Webserver habe ich halt TRequestInfo zur Verfügung mit allen Infos, die Indy liefert. TRequestInfo wird, inhaltlich unverändert, an die IDRunner-Komponente weitergegeben, so dass dort eher nichts verloren gehen dürfte. Im Webmodul für die DLLs steht dann TWebRequest zur Verfügung, hier enthält der Request aber nicht alle Attribute, die TRequestInfo von Indy enthält. Bisher habe ich noch nicht verstanden, wie die Daten nun genau vom Webserver an die DLL weitergereicht werden. Irgendwo in dieser (noch) Blackbox werde ich dann wohl mal suchen müssen.