[Release]AutoIt3 powerful webserver v1.0

FacePalmMan · 01/27/2016, 22:53

(v1.1)
~~BIS AUF WEITERS DISCONTINUIERT~~ (Download trotzdem noch verfügbar)

I'm back from....... uhm...... the offline world?
Spaß beiseite, ich habe ENDLICH mal wieder was produktives von mir gegeben! *party*

Einige AutoIt Programmierer unter euch haben sich sicherlich schon mal gedacht: "Wie gern würde ich jetzt Autoit programmieren..... Aber ich kann ja leider kein AutoIt auf diesen PC installieren.

"

Das ist blöd, aber hier ist eine Lösung: Ein online AutoIt compiler. Hört sich cool an, oder? Nein? Ok., war zumindest einen Versuch wert....

Was habe ich tatsächlich gemacht? Ich habe in meinen Webserver eine Seite hinzugefügt in der man ein AutoIt script auswählen kann, welches dann hochgeladen, kompilliert, und für den User sichtbar verlinkt wird. So ist die AutoIt-Installation nicht mehr obligatorisch, sondern nur sehr hilfreich.

Die einzigen die mir da noch fehlt ist eine Schreiboberfläche (z.B. wie:

).

~~Ich versuche meinen Webserver wenn ich am PC bin am laufen zu halten, (d.h. ~12-22 Uhr, est. ~40% uptime) damit ihr, wenn nötig, euer Zeugs darüber kompillieren lassen könnt.~~
Webadresse:

Mediafire download link:

Virustotal link:

Bugs:
-Man kann sich die UserDB anschauen und nicht sehr erwünschte Blicke in die Login-daten werfen.
(Ich werde das Problem beheben, indem ich ein Restriction-system hinzufüge)
-Aufsteigen-funktion im Serverexplorer-script funktioniert nicht, sondern fügt / zu Pfad hinzu.
-Das Uploaden von Scripts mit Endung .php.au3 führt zum sofortigen Ausführen des Scripts (Sicherheitsrisiko!!!)
ToDo:
-UDF für die "PHP"-scripte um das Erstellen von "PHP"-scripts zu vereinfachen
(z.B. das Verarbeiten von cmdline zu Cookies/Data/etc. und das automatisierte, nicht mehr hardgecodete, Senden von Befehlen an das Serverprogramm)
-Ein Editor für AutoIt scripts mit Syntax check & highlighting
(Dafür bräuchte ich aber Unterstützung von jemanden der sich mit HTML/JavaScript besser auskennt)
-Eine Abfrage zum Neuöffnen der Listensocket, wenn das Internet mal für ein paar Sekunden ausfällt
-Ein Präfix für Dateien implementieren, damit diese nicht gelesen werden (wie z.B. die UserDB)

Ich wäre sehr dankbar, wenn jemand eine solche Programmieroberfläche erstellen (oder die oben genannte verändern), und allen zur Verfügung stellen könnte. Mir wäre dabei wichtig, dass die Dateien auf den Webserver hochgeladen werden, der gerade offen ist.

~~Deverixz~~ · 01/28/2016, 12:53

Gefällt mir,
werde ich gerne mal ausprobieren - vielen dank!

EDIT: Der Login weißt bei mir einige kleine Probleme auf, eventuell könnte man diesen ausbessern, ansonsten funktionierts super ^^

~~TheMokko~~ · 01/28/2016, 12:58

Geile Idee,
und für so AutoIt abhänige scriptsprachen schlampen wie mich kommt das sehr gut!

Shadow992 · 01/28/2016, 14:17

Ich habe mir das Projekt zwar (noch) nicht näher angeschaut, aber da ich ja selbst ein Fan davon bin zu zeigen wozu AutoIt alles fähig ist, finde ich deine Idee sehr genial.

Ich werd mir später den Code mal anschauen und richtig digge ablästern über allerlei Zeugs was du so treibst (oder dich gen den Himmel loben). :P

FacePalmMan · 01/28/2016, 16:20

Quote:

Originally Posted by Deverixz

Gefällt mir,
werde ich gerne mal ausprobieren - vielen dank!
EDIT: Der Login weißt bei mir einige kleine Probleme auf, eventuell könnte man diesen ausbessern, ansonsten funktionierts super ^^

Könntest du bitte die Probleme beim Login genauer beschreiben damit ich die Sache eventuell beheben kann?

Und ich hätte nicht erwartet dass dieses "Proof-of-concept" (das soll es eigentlich sein) so gut ankommt. Ich bin positiv überrascht.

Oh und ich habe vergessen das externe Send-script mit in die Rar zu packen. Fail.
Aber da ich das Script jetzt eh update, packe ich es gleich dazu.

~~Deverixz~~ · 01/28/2016, 16:39

Quote:

Originally Posted by FacePalmMan

Könntest du bitte die Probleme beim Login genauer beschreiben damit ich die Sache eventuell beheben kann?

Und ich hätte nicht erwartet dass dieses "Proof-of-concept" (das soll es eigentlich sein) so gut ankommt. Ich bin positiv überrascht.

Oh und ich habe vergessen das externe Send-script mit in die Rar zu packen. Fail.
Aber da ich das Script jetzt eh update, packe ich es gleich dazu.

Das war eventuell das Problem. Beim Login kam es bei mir zum Crash des Webservers weswegen ich einige kleine Modifikationen vorgenommen habe um es mal zu testen. Dann funktionierte es auch ^^
Also um das Problem zu beschreiben: Beim Login crashte der Webserver (meist)

Shadow992 · 01/28/2016, 18:45

Ich habe den Code nicht probiert, aber was mir so aufgefallen ist:

1. Cookies werden leider gar nicht unterstützt, das ist schade, vielleicht passt du das noch an.
2. Das Connection-Array scheint irgendwie die Anzahl der Connections als auch die Connections selbst zu halten. Vielleicht sollte man das auftrennen.
3. Die leere While-Schleife sieht irgendwie komisch aus, vielleicht solltest du auch nicht Adlib-Register benutzen, sondern mit Timern-Arbeiten. Immerhin gibt es bei Adlib immer das Problem, dass sich Adlib-Aufrufe gegenseitig unterbrechen können (und es auch tun). Wenn kacke läuft, kommste dadurch in eine Endlosschleife oder zumindest in eine große Verzögerung.
4. Normalerweise will man aus Sicherheitsgründen kein Zugriff aufs ganze File-System gewähren und prüft daher ob der Pfad ein absoluter oder ein relativer ist.
5. Das Schreiben des Packets in eine Datei und dann das ausschließende Auslesen frisst unnötig Zeit. Eine Alternative wäre eine Pipeline einzurichten. Noch besser wäre ein Shared-Memory Ansatz, was aber nicht "einfach so" geht.

Aber ansonsten sieht das ziemlich gut aus. Ernsthaft benutzen wird man es wohl kaum, aber die Idee ist echt cool und das zeigt auch mal wieder, dass AutoIt einiges kann.

~~Deverixz~~ · 01/28/2016, 19:01

Quote:

Originally Posted by Shadow992

Ich habe den Code nicht probiert, aber was mir so aufgefallen ist:

1. Cookies werden leider gar nicht unterstützt, das ist schade, vielleicht passt du das noch an.
2. Das Connection-Array scheint irgendwie die Anzahl der Connections als auch die Connections selbst zu halten. Vielleicht sollte man das auftrennen.
3. Die leere While-Schleife sieht irgendwie komisch aus, vielleicht solltest du auch nicht Adlib-Register benutzen, sondern mit Timern-Arbeiten. Immerhin gibt es bei Adlib immer das Problem, dass sich Adlib-Aufrufe gegenseitig unterbrechen können (und es auch tun). Wenn kacke läuft, kommste dadurch in eine Endlosschleife oder zumindest in eine große Verzögerung.
4. Normalerweise will man aus Sicherheitsgründen kein Zugriff aufs ganze File-System gewähren und prüft daher ob der Pfad ein absoluter oder ein relativer ist.
5. Das Schreiben des Packets in eine Datei und dann das ausschließende Auslesen frisst unnötig Zeit. Eine Alternative wäre eine Pipeline einzurichten. Noch besser wäre ein Shared-Memory Ansatz, was aber nicht "einfach so" geht.

Aber ansonsten sieht das ziemlich gut aus. Ernsthaft benutzen wird man es wohl kaum, aber die Idee ist echt cool und das zeigt auch mal wieder, dass AutoIt einiges kann.

Er arbeitet gerade an patches und neuen Funktionen, schaue via TeamViewer zu *^* Ich leite es ihm mal weiter ^^

FacePalmMan · 01/28/2016, 19:14

Quote:

Originally Posted by Shadow992

Ich habe den Code nicht probiert, aber was mir so aufgefallen ist:

1. Cookies werden leider gar nicht unterstützt, das ist schade, vielleicht passt du das noch an.
2. Das Connection-Array scheint irgendwie die Anzahl der Connections als auch die Connections selbst zu halten. Vielleicht sollte man das auftrennen.
3. Die leere While-Schleife sieht irgendwie komisch aus, vielleicht solltest du auch nicht Adlib-Register benutzen, sondern mit Timern-Arbeiten. Immerhin gibt es bei Adlib immer das Problem, dass sich Adlib-Aufrufe gegenseitig unterbrechen können (und es auch tun). Wenn kacke läuft, kommste dadurch in eine Endlosschleife oder zumindest in eine große Verzögerung.
4. Normalerweise will man aus Sicherheitsgründen kein Zugriff aufs ganze File-System gewähren und prüft daher ob der Pfad ein absoluter oder ein relativer ist.
5. Das Schreiben des Packets in eine Datei und dann das ausschließende Auslesen frisst unnötig Zeit. Eine Alternative wäre eine Pipeline einzurichten. Noch besser wäre ein Shared-Memory Ansatz, was aber nicht "einfach so" geht.

Aber ansonsten sieht das ziemlich gut aus. Ernsthaft benutzen wird man es wohl kaum, aber die Idee ist echt cool und das zeigt auch mal wieder, dass AutoIt einiges kann.

"Das Schreiben des Packets in eine Datei und dann das ausschließende Auslesen frisst unnötig Zeit" ? Ich lasse die nur in eine Datei schreiben wenn sie eine nicht unterstütze Methode verwenden. Das ist also nur zu Entwicklungszwecken.

"Normalerweise will man aus Sicherheitsgründen kein Zugriff aufs ganze File-System gewähren und prüft daher ob der Pfad ein absoluter oder ein relativer ist" Solch eine Abfrage ist schon drin, b.z.w hat nicht geklappt, weswegen man sich dabei keine Sorgen machen muss

"Das Connection-Array scheint irgendwie die Anzahl der Connections als auch die Connections selbst zu halten. Vielleicht sollte man das auftrennen"
Es ist besser so. Man hat das in einer Array. Zwar muss man immer schauen was was ist, aber ist halt einfach besser.

Shadow992 · 01/28/2016, 19:45

Quote:

Originally Posted by FacePalmMan

"Das Schreiben des Packets in eine Datei und dann das ausschließende Auslesen frisst unnötig Zeit" ? Ich lasse die nur in eine Datei schreiben wenn sie eine nicht unterstütze Methode verwenden. Das ist also nur zu Entwicklungszwecken.

Das kommt davon, wenn man sich das ganze unter Linux ohne Syntax-Highlighting in der Konsole anschaut.

Quote:

Originally Posted by FacePalmMan

"Normalerweise will man aus Sicherheitsgründen kein Zugriff aufs ganze File-System gewähren und prüft daher ob der Pfad ein absoluter oder ein relativer ist" Solch eine Abfrage ist schon drin, b.z.w hat nicht geklappt, weswegen man sich dabei keine Sorgen machen muss

Echt Autoit filtert sowas "..\temp\file" automatisch raus? :O

Quote:

Originally Posted by FacePalmMan

"Das Connection-Array scheint irgendwie die Anzahl der Connections als auch die Connections selbst zu halten. Vielleicht sollte man das auftrennen"
Es ist besser so. Man hat das in einer Array. Zwar muss man immer schauen was was ist, aber ist halt einfach besser.

Na also das ist keine Begründung, die mich überzeugt. :P
Aber waren ja nur Vorschläge.

FacePalmMan · 01/28/2016, 20:26

Update ist gleich fertig. Ich bräuchte vielleich ein wenig Hilfe. AutoIt meint plötzlich dass die Socket die das FileSendScript kriegt nicht gültig/keine Socket ist..... .-.
Das mit der durch Run(..., "", Default, 3) Sockets sharen zu können klappt also anscheinend nicht mehr. Ich habe alles überprüft. Es wird richtig übertragen und richtig als richtiger Parameter bei der TcpSend Funktion verwendet.
Ich bin ratlos.

Edit:
Ich habe das Rätsel gelöst.
Childprozesse haben nur zugriff auf zum Startzeitpunkt schon vorhanden gewesene Sockets.
Wäre nice wenn jemand einen Workaround erarbeiten könnte. Ich schaue mich ein wenig um und gucke was sich machen lässt. Ich würde mich freuen wenn sich jemand damit auskennt und mich diesbezüglich beraten könnte.

Shadow992 · 01/29/2016, 12:41

Für alle, die auch einmal Sockets zwischen Prozessen hin und herverschieben wollen:

Als kleine Hintergrund-Info:
Sockets in Windows sind standardmäßig immer nur Pointer zu bestimmten Bereichen im eigenen Prozess. Diese Pointer sind aber nicht absolute Pointer (sodass sie jeder benutzen kann), sondern sie sind immer relativ zum Prozess, der sie erstellt hat. Das heißt man muss "nur" die relativen Pointer zu absolute Pointer und dann wieder zu relativen Pointern (in dem anderen Prozess) umändern. Die Lösung ist im Anhang zu finden.

Zuerst "servertest.exe" starten und anschließend "Handle forwarding test.exe". Diese ruft dann die "Child.exe" auf und übergibt ihr das Socket + ProzessId, welches dann vom Child konvertiert wird und die entsprechende Nachricht an "servertest.exe" sendet.

FacePalmMan · 01/31/2016, 02:24

V1.1 ist draußen.
Leider schließt und öffnet sich das Zweitscript immernoch je nach gebrauch, aber die Verzögerung ist zum großteil behoben. Der Grund dafür war dass für die Größenbestimmung die Dateien immer ausgelesen werden mussten. Und bei einer 30MB großen Datei kann das schon ein wenig dauern. Deswegen wird ab jetzt für solche Zwecke nur noch FileGetSize in meinen Scripten verwendet. Die neue Verzögerung (Run (Hauptscript) ---> erste Zeile (Zweitscript)) beträgt jetzt laut Msgboxen ~150-200ms, was für mich noch akzeptabel ist.

Bitte probiert es mal aus und sagt was ihr von der Veränderung haltet.

BladeTiger12 · 01/31/2016, 13:45

In deiner AutoIt_webserver_SenFile.au3 verstehe ich diesen Teil nicht:

Code:

$32MB = (1024 ^ 2) * 1 ;<--- 0.5 MB, adjustable :D
$1GB = 1024 ^ 3

If FileGetSize($sPath) < $1GB Then
	$aRequests[3] = FileRead($aRequests[2], $32MB)
Else
	$aRequests[3] = FileRead($aRequests[2], $32MB)
EndIf

Macht ja 1: Genau das gleiche
2: Warum liest du die Dateien nicht am Anfang 1x ein?

FacePalmMan · 01/31/2016, 18:24

Quote:
Originally Posted by BladeTiger12
In deiner AutoIt_webserver_SenFile.au3 verstehe ich diesen Teil nicht:
Code:
$32MB = (1024 ^ 2) * 1 ;<--- 0.5 MB, adjustable :D
$1GB = 1024 ^ 3

If FileGetSize($sPath) < $1GB Then
	$aRequests[3] = FileRead($aRequests[2], $32MB)
Else
	$aRequests[3] = FileRead($aRequests[2], $32MB)
EndIf
Macht ja 1: Genau das gleiche
2: Warum liest du die Dateien nicht am Anfang 1x ein?

1. Habe ich vergessen rauszunehmen, da ich daran rumgespielt habe.
2. Weil StringTrimLeft lange braucht um lange Strings zu bearbeiten. Deswegen lasse ich immer nur ein Teil der Datei auslesen.

Schaut euch mal den Mainpost genauer an! Hab ein wenig geupdated (auch den Downloadlink)

Einen Cookie* an denjenigen der den Easteregg zuerst findet

*7-stellig, in Hexadezimal generiert.