WebServer

[DeddyH]

Lies Dir doch Phoenix' Beitrag noch einmal durch und vergleiche den Aufwand. Darauf wollte ich mit meinem Hammer-Vergleich hinaus. Dass diese Delphi-Programmierer immer gleich Schnappatmung bekommen müssen...

[Delphi.Narium]

Der von Phoenix beschriebene Aufwand entspricht meiner Erfahrung nach nicht der Realität.

Man muss keine HTTP-Spezifikation durchimplementieren, ... (das ist in den INDY-Komponenten alles schon enthalten).

Zitat von Phoenix:

Das Beispiel mit dem vollständigen Webserver (inkl. CSS, JS, Bildern, Videos, Binärformaten etc.) ist in modernem .NET 7 vermutlich irgendwas zwischen 3 und 5 Zeilen.

In meinem obigen Beispiel sind's halt keine 3 bis 5 Zeilen, sondern 13.

Man könnte es auch noch verkürzen:

Delphi-Quellcode:

sFilename := Format('%s%s',['htdocs',ARequestinfo.Document]);
if not FileExists(sFilename) then sFilename := 'htdocs/index.html';
Stream := TFileStream.Create(sFilename, fmOpenRead or fmShareDenyWrite);
// Hier muss man noch den ContentType abhängig von dem Dateityp, setzen.
AResponseinfo.ContentType := 'text/html';
AResponseinfo.ContentStream := Stream;

Delphi-Quellcode:

procedure TForm1.ServerCommandGet(AContext: TIdContext;
  ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
var 
  Stream : TFileStream;
  Filename : String;
begin
  Filename := Format('%s%s',['htdocs',ARequestinfo.Document]);
  if not FileExists(sFilename) then Filename := 'htdocs/index.html';
  Stream := TFileStream.Create(sFilename, fmOpenRead or fmShareDenyWrite);
  // Hier muss man noch den ContentType abhängig vom Dateityp, setzen.
  AResponseinfo.ContentType   := 'text/html';
  AResponseinfo.ContentStream := Stream; 
  AResponseinfo.ContentLength := Stream.Size;
end;

Und damit haben wir dann auch in Delphi 'nen 14-Zeiler
Mehr ist für

Zitat von Phoenix:

Das Beispiel mit dem vollständigen Webserver (inkl. CSS, JS, Bildern, Videos, Binärformaten etc.)

nicht erforderlich.

[himitsu]

Ja, ich gebe hier auch über einen TidHTTPServer eine Webseite raus,
genauer geht es um das HTML/CSS/JS/Image-Zeugs, was von Help&Manual generiert wurde.

Damit aber der Browser Bilder/JS/CSS ordentlich behandelt, mußte ich dann auch teilweise Dateien umkodieren (ANSI<>UTF-8), beim Rausgeben,
und zusätzlich auch an den HTTP-Headern rumspielen, also ContentType, Charset und Dergleichen alles selbst behandeln, entsprechend der angefragten DateiEndungen.

[Delphi.Narium]

Zitat von himitsu:

Damit aber der Browser Bilder/JS/CSS ordentlich behandelt, mußte ich dann auch teilweise Dateien umkodieren (ANSI<>UTF-8), beim Rausgeben,
und zusätzlich auch an den HTTP-Headern rumspielen, also ContentType, Charset und Dergleichen alles selbst behandeln, entsprechend der angefragten DateiEndungen.

Das ist aber (streng genommen) keine Aufgabe des Webservers, bei spezifikationkonformen Aufbau der HTML-Dateien, sollte die Umcodierung entbehrlich sein.

Und neben AResponseinfo.ContentType sollte man natürlich alle weiteren Werte für AResponseinfo korrekt setzen.

Z. B.:
AResponseInfo.ContentEncoding
AResponseInfo.ContentLanguage
AResponseInfo.ContentLength

und die ausgegebenen HTML-Seiten sollten auch die entsprechenden Meta-Tags im Header enthalten.

Aber auch das ist eigentlich keine Aufgabe des Webservers, sondern der Routinen, Programme, Autoren, ..., die die HTML-Seiten erstellen.

[himitsu]

Dafür müssen diese Angaben dort auch stimmen ... tun sie aber nicht und daher hatten wir dann Hand angelegt.
* die erste Version war auch nur "prüfen des Pfades", damit ausschließlich gewünschte Dateien raus gehen
* und dann LoadFromFile und als Stream 1:1 raus zum Browser

* zerst überlegt alles wie \ und / im Pfad abzulehnen, aber sicherer fühlten wir uns dann, als wir einfach nur a-zA-Z0-9_.- zuliesen

Da Microsoft/InternetExplorer komischer Weise das Intranet z.B. von SambaShares (obwohl die ja eine ausreichende Zugangskontrolle haben) als "unsicher" einstufte,
aber wilde lokale HTTP-Server von Localhost oder irgendwo aus dem lokalen Netzwerk als sicher ....

Nja, direkt die Webseite vom Dateisystem (filerotokoll) wurde selten korrekt angezeigt, außer man fummelte auf jedem einzelnen Rechner an den Sicherheitseinstellungen rum,
war ein "WebServer" die einfache Lösung.

Der Hersteller (Help&Manual) hatte das auch schon lange bemerkt und stellte dafür eine EXE bereit
* erstmal nicht als Service, sondern als GUI-EXE
* und wo dann sonstwer ohne Prüfungen von Festplatte/Netzwerk JEDE Datei darüber runterladen kann (auf die Leserechte besteht, also fast alles vom Windows)

[Delphi.Narium]

Zitat von himitsu:

war ein "WebServer" die einfache Lösung.

In der Tat, das ist eine einfache Lösung.

Man bringt dem eigenen WebServer einfach nur das bei, was man tatsächlich abdecken will.

Und ja, die HTML-Originaldateien von diversen Systemen sind nicht zwingend spezifikationskonform, so dass man kaum umhinkommt, da vereinzelt bis grundsätzlich nachzuarbeiten.

Und das Schöne an 'nem eigenen WebServer: Er kann wirklich das und nur das, was man benötigt.

[Rollo62]

Zitat von Delphi.Narium:

Und das Schöne an 'nem eigenen WebServer: Er kann wirklich das und nur das, was man benötigt.

Stimmt.
Ein eigener, selbstgebauter WebServer kann aber dafür auch alle möglichen sicherheitskritischen Probleme haben, je nach Umfang,
denn da testen im Prinzip nur Wenige und nicht Millionen User in Tausenden von Einsatz-Szenarien.
Kann sein dass man das im lokalen Netz akzeptiert, aber im echten Web hätte ich da ziemliche Bauchschmerzen.

Ich glaube man sollte heutzutage nicht alles versuchen selber zu machen, es sei denn man hat das als Hobby.

[himitsu]

Jupp, der erwähnte WebServer des Herstellers.
Wenn du den noch in der Firewall und im Router eine Portweiterleitung von außen einrichtest ... da er ja garkeine Sicherheit bietet ... könnte dann JEDER fast deine komplette Festplatte und alles zugängliche im Netzwerk runterladen.

Authentifizierung hatten ir und gespart, da unsere Hilfe zusätzlich auch nochmal online auf der über unseren richtigen WebServer (Webseite) frei zugänglich ist, war Diesbezüglich nichts mehr nötig.
Nur eben, dass "offentlich" alle Lesezugriffe außerhalb des gewünschten Verzeichnisses unterbunden werden. Und nurmal ist dieser kleine HelpServer auch nur lokal im Netz unterwegs, aber dennoch wäre es unschön, wenn er einfachen Zugriff auf das Dateisystem des Datenbankservers erlaubt hätte.

[Delphi.Narium]

Zitat von Rollo62:

Zitat von Delphi.Narium:

Und das Schöne an 'nem eigenen WebServer: Er kann wirklich das und nur das, was man benötigt.

Stimmt.
Ein eigener, selbstgebauter WebServer kann aber dafür auch alle möglichen sicherheitskritischen Probleme haben, je nach Umfang,
denn da testen im Prinzip nur Wenige und nicht Millionen User in Tausenden von Einsatz-Szenarien.
Kann sein dass man das im lokalen Netz akzeptiert, aber im echten Web hätte ich da ziemliche Bauchschmerzen.

Ich glaube man sollte heutzutage nicht alles versuchen selber zu machen, es sei denn man hat das als Hobby.

Ich käme nie auf die Idee, einen WebServer für das weltweite Internet zu bauen.

Es geht hier doch nur darum zu versuchen ob es geht. Zum Lernen, zum Probieren, sicherlich nicht um eine kommerzielle Software zu erstellen, die mit vorhandenen WebServeren auch nur im leisesten Ansatz konkurieren kann.

Hiermit

Delphi-Quellcode:

sFilename := Format('%s%s',['htdocs',ARequestinfo.Document]);
if not FileExists(sFilename) then sFilename := 'htdocs/index.html';

hat man schonmal keinen Zugriff mehr auf die gesamte Festplatte, sondern nur auf die Dateien, die unter htdocs liegen. Wo das physikalisch liegt, ist von außen nicht erkennbar. Sinnvollerweise macht man das konfigurierbar und sorgt dafür, dass die Rechte entsprechend eingeschränkt sind.

Über ARequestinfo bekommt man auch die IP des Anfragers heraus, hierüber kann man dann auch nochmal die Zugriffe einschränken. Ein eigener WebServer muss nicht auf Port 80 oder 8080 laufen, wie meist üblich bzw. vorgegeben.

Mögliche sicherheitskritische Probleme hat ein eigener WebServer alle die, die man sich auch sonst mit Delphiprogrammen "einfangen" kann, also z. B. auch alle die, die in den Indykomponenten enthalten sein könnten, ... und natürlich alle die, die man selbst einbaut

[himitsu]

Code:

http://1.2.3.4:80/../../../../../../../Windows/System32/TeamViewer_Hooks.log

und mit etwas Glück hab ich deinen "Schutz" schon umgangen.

Genau sowas war der Grund, warum ich bei uns dann die Prüfung umgekehrt hab, weil ich sorum bestimmt auch nicht jede Möglichkeit bedenke und irgendwas vergessen/übersehen hätte.


Gut, mein Webserverchen kommt unter Anderen auch in einer Firma zum Einsatz, die z.B. mit Airbus zusammenarbeitet und deren Regel unterliegt, da sind die Sicherheitsbestimmungen schon bissl böse ... und ich wollte diesbezüglich dann einfach keine keine unnötigen Sicherheitslöcher riskieren.