Hallo zusammen. Ich habe einen Apache-Server, dessen Seiten in der 'sites-enabled' mittels AuthType Basic kennwortgeschützt sind. Wird eine dieser Seiten aufgerufen, muessen BN und PW in eine MessageBox eingetragen, fertig. Jetzt habe ich auf der Hauptseite das obligatorische 'Anmelden' und 'Neu Registrieren' ueber <form> ... in CGI-Skripten implementiert, die in C geschrieben sind. Nach der Eingabe prueft der Server die CGI-Daten gegen eine mysql-Datenbank (innerhalb des CGI-Skripts) und meldet dann je nach Eingabe 'ist okay - Fehler'. Soweit so gut. Mein Problem ist, dass ich jetzt an der Schnittstelle zwischen Apache AuthType Basic und den CGI-Sicherheitsdaten scheitere. Ruft das CGI-Skript eine der geschuetzten Seiten auf -nachdem die Daten erfolgreich gecheckt, gespeichert, etc. wurden, geht die MessageBox des Apache auf und wir werden freundlich um die Eingabe gebeten. Ich wuerde gerne implementieren, dass ich Apache Seiten zwar wie gehabt sperren kann, die Passoerter aber dann nach erfolgter Pruefung via CGI an den Server sende. Und hier habe ich ein Brett vor dem Kopf. Bin fuer jeden Hinweis dankbar.
Matthias schrieb: > Und hier habe ich ein Brett vor dem Kopf. ich glaube das das geht nicht. Entweder eigene Anmeldung oder von Apache. Sinnvoll ist die eigene Anmeldung aber nur über https, denn sonst kann man ja das Kennwort mitlesen.
Im WWW-Authenticate header werden die HTTP Basic credentials gesetzt, das Passwort ist Base64 encoded (deswegen eben HTTPS einsetzen!), wenn dein CGI script diesen Header nutzt sollte es gehen.
Danke für Eure Rückmeldungen. Das diese Kombination nicht machbar ist, habe ich mir schon gedacht. HTTPS und base64-basierte Uebertragung war mir klar. Ich bin noch Programmieranfänger und der Sinn des ganzen sollte eher darin bestehen ein sinnvolles, praxisbezogenes Projekt unter Verwendung von C zu programmieren, dass verschiedene APIs einschliesst, gerade oder auch um die Zusammnhänge als solche besser zu verstehen. Wegen dem Brett vor dem Kopf... Das ich mein CGI-Skript nicht mit der Apache-Authentifikation koppeln kann dachte ich mir. Aber jetzt habe ich eine Website, der Benutzer gibt seine BN-Daten ein, dass Skript prueft in einer MySQL-Datenbank auf (ja/nein)... Auch wenn es blöd klingt, war mein nächster Gedanke nun aufgrund der fehlenden Anbindung an den Apache, dass ich innerhalb des CGI-Skripts einfach ein html-Dokument anlege, welches nur dann ausgegeben wird, wenn die Benutzerdaten korrekt waren. Weil, würde ich das Dokument vorher anlegen und in meinem DocumentRoot ablegen, wüsste ich nicht, wie ich es sperren könnte und es erst mit meiner CGI-Variante freigeben könnte. Das kommt mir aber irgendwie so vor, als würde ich mir die Hose mit der Kneifzange anziehen, weil einfach zu kompliziert und davon ab, wird mein html-Doc im CGI-Skript zur Laufzeit immer wieder neu prodzuziert.
Diese Kombination ist machbar, lange CGI Script und Apache HTTP Basic Auth. nutzen ;)
@Mladen Wie gesagt...Programmieranfänger (mehr oder weniger) Ich weiss wie TCP-Header aussehen und wie man sie implementieren kann. Deinen Hinweis bezüglich des 'Authenticate header' verstehe ich nicht. Heisst das, ich kann/soll in meinem CGI-Skript einen eigenen/neuen Header implementieren? Hat dieser überhaupt etwas mit 'normalen' Headern zu tun oder? Für Details oder etwas mehr Infos wäre ich echt dankbar.
Ich glaube eine Lösung gefunden zu haben: Die open methode eines XMLHttpRequests http://www.w3.org/TR/XMLHttpRequest/#the-open()-method open(method, url, async, username, password) Kann genutzt werden, um die logindaten mit basic auth zu senden und zu prüfen. Die login daten können im cgi-script aus dem auth header feld extrahiert werden. Das cgi script updatet eine von apache genutzte .htpasswd datei. Bei einer Seite die eine Authenthizierung erfordert konfiguriert man apache zum senden eines weiterleitungsheaders auf das login cgi script. Durch den referer header, der dadurch generiert wird, weiss das cgi script, zu welcher seite nach der Anmeldung gewechselt werden muss. Um nach überprüfen des Passworts auf die seite zu wechseln müssen die properties location.username, location.passwort, und location.href gesetzt werden. Dabei sollte sich der origin nicht ändern, damit sich browser die location.passwort nicht unterstützen an die logindaten des letzten xmlhttprequest errinnern können. Also rein theorethisch.
Langsam aber sicher fällt der Groschen. Jetzt weiss ich auch, wovon Mladen in seinem ersten Post geschrieben hat. @Daniel Vielen Dank für die Beschreibung. Einiges war/ist mir nicht klar, deshalb habe ich gerade mal ein wenig geblättert... Zum Verständnis, WWW-Authenticate könnte man bspw. über Apache SSI implementieren (ich weiss, SSI veraltet) ... Nur für mich erst mal wichtig, dass dies serverseitig zu implementieren ist, korrekt? Konfigurationssache. Nachdem nun mein CGI-Skript an den Server meldet..."Ich hätte gerne Zugang" sendet dieser "401 - Not Authorized response code" Nun, ich habe vorher vergessen zu schreiben, dass die Seiten nur in HTML verfasst sind. Deine open()-Funktion stammt aber aus XML wie ich gesehen habe. Heisst das für mein Verständnis, dass ich die oben genannte 401 response in meinem CGI Skript auslese (u.a. die XML-Umgebungsvariablen) und dann über XML einen eigenen Antwort Header zurück sende?
Matthias schrieb: > Ich weiss wie TCP-Header aussehen und wie man sie implementieren kann. Falsche Abstraktionsebene ;) Matthias schrieb: > Wie gesagt...Programmieranfänger (mehr oder weniger) Gut, dann nochmal langsam. Der HTTP Header WWW-Authenticate wird genutzt um die HTTP Basic Authentifizierung umzusetzen. Ein HTTP Header (kein TCP Header) ist ein String im Header des HTTP Requests, dh. dieser String wird immer vom Client (Browser) zum Server (Apache) uebertragen, bei jedem HTTP Request, (auch) der Apache nutzt diesen um die HTTP Basic Implenetierung umzusetzen. Hier mal eine Liste von moeglichen HTTP Headern: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields Wenn dein CGI "Script" diesen Header auswerted anstat auf FOrm-based Authentification zu setzen, klappt das auch im ZUsammenspiel mit dem Apache HTTP Basic. Matthias schrieb: > Ich bin noch > Programmieranfänger und der Sinn des ganzen sollte eher darin bestehen > ein sinnvolles, praxisbezogenes Projekt unter Verwendung von C zu > programmieren, dass verschiedene APIs einschliesst, gerade oder auch um > die Zusammnhänge als solche besser zu verstehen. Wuesste nicht das man sinnvolle Beispiele fuer C Programme als CGI im Netz findet, CGI wird meist mit anderen Sprachen, frueher Perl, heutzutage mit PHP implementiert. C als low Level Sprache hat IMHO eher andere Einsatzbereiche, also wenn du C lernen willst dann eher nicht als CGI, und wenn du CGI lernen willst dann eher kein C. Nebebnbei, der apache untersuetzt eine vielzahl von Authentifizierungsmethoden, aber HTTP Basic ist eine der einfachsten. Nachtrag: Der Apache koennte auch selbst in der DB nach dem usernamen und Passwort suchen um nach HTTP Basic zu authentifizieren, d.h. du koenntest grundsaetzlich immer den Apache die Authentifizierung machen lassen (HTTP Header setzen), dein Programm liest zusaetzlich den Usernamen und das Passwort aus (aus dem HTTP Header) wenn es das braucht. Aber irgendwie ist das IMHO der falsche Weg um C oder CGI zu erlernen..
:
Bearbeitet durch User
Vielen Dank. Ja die Sache mit den Begrifflichkeiten (HTML-Header/TCP-Header), mea culpa. Ich muss mir das ganze in Ruhe ansehen und dann wird es was, nicht zuletzt aufgrund Eurer Tipps, Anregungen etc. Danke Warum ich C benutze ist relativ simpel. Du kannst damit nahezu alles programmieren. Willst Du etwas auf OS-Ebene/Kernel-Ebene machen kannst Du das in C... Willst Du mit TCP/IP-Protokollen arbeiten geht das mit C und was noch wichtiger ist, Du lernst dabei enorm viel, was ich super finde. Und man kann auch einen selbstgebastelten mysql-Client in ein CGI-Skript packen...:) was auch mit python und Co gegangen wäre. Ich habe vorher nur im/am oder um das OS herum programmiert. Internet, Websites, HTML, war nicht meins. Bis vor kurzem doch noch mein Interesse geweckt wurde Ersten Server aufgesetzt, erste Seiten eingerichtet und here we go. Als ich gelesen habe, dass ich in CGI auch mit C arbeiten kann, mysql ansteuern kann etc, habe ich nur fälschlicherweise gedacht, dass es einfacher, nein eine konventionellere Möglichkeit gäbe, dem Apache die Daten zu übermitteln.
Matthias schrieb: > Warum ich C benutze ist relativ simpel. Du kannst damit nahezu alles > programmieren. Willst Du etwas auf OS-Ebene/Kernel-Ebene machen kannst > Du das in C... Willst Du mit TCP/IP-Protokollen arbeiten geht das mit C > und was noch wichtiger ist, Du lernst dabei enorm viel, was ich super > finde. Schon klar, C ist unversell, aber nur Masochisten schreiben damit dyn. Webseiten m.E. ;) Matthias schrieb: > Und man kann auch einen selbstgebastelten mysql-Client in ein CGI-Skript > packen...:) Gibt es doch schon, warum das Rad eckig neu erfinden? Matthias schrieb: > Ich habe vorher nur im/am oder um das OS herum programmiert. Dafuer ist C sehr gut geeignet, zumindest wenn die Aufgabenstellung "low level" genug ist. Matthias schrieb: > Internet, > Websites, HTML, war nicht meins. Dann ist C die falsche Sprache! Jede Problemdomaene hat so seine eigenen etablierten Sprachen, im Netz sind PHP, Ruby, Java etc. pp. etabliert. Matthias schrieb: > Als ich gelesen habe, dass ich in CGI auch mit C arbeiten kann, mysql > ansteuern kann etc, habe ich nur fälschlicherweise gedacht, dass es > einfacher, nein eine konventionellere Möglichkeit gäbe, dem Apache die > Daten zu übermitteln. HTTP Header, Cookies etc. pp. gehoeren bei dyn. Webseiten nunmal dazu, aber wie gesagt, ist eher nicht die Domaene von C. PHP koennte vielleicht etwas fuer dich dund dyn. Webseiten sein, das HTTP Protokoll, HTML, CSS und JavaScript gehoeren aber auch zu dyn. Webseiten. Nebenbei, nicht einschuechtern lassen, da prasselt am Anfang viel auf einen ein (HTTP, HTML, CSS, JS, PHP, verschiedene Browser und deren Eigenheiten, etc. pp.), auch ganz ohne ein RDBMS wie MySQL, mit der Zeit bekommt ma den Ueberblick.
:
Bearbeitet durch User
>Wenn dein CGI "Script" diesen Header auswerted anstat auf FOrm-based >Authentification zu setzen, klappt das auch im ZUsammenspiel mit dem >Apache HTTP Basic. Und wo gibt der User die Daten ein, in der MessageBox des Apaches? Weil ueber Formulardaten würde es dann ja nicht mehr gehen. Und wieso sollte ich dann noch HTTP-Header auswerten? >Nachtrag: >Der Apache koennte auch selbst in der DB nach dem usernamen und Passwort >suchen um nach HTTP Basic zu authentifizieren, d.h. du koenntest >grundsaetzlich immer den Apache die Authentifizierung machen lassen >(HTTP Header setzen), dein Programm liest zusaetzlich den Usernamen und >das Passwort aus (aus dem HTTP Header) wenn es das braucht. Das hatte ich schon. Ueber das mysql Modul des Servers. Lief toll, nur halt versteckt hinter den Kulissen und das wollte ich selber machen um es zu verstehen.
Matthias schrieb: > Und wo gibt der User die Daten ein, in der MessageBox des Apaches? Ja. Matthias schrieb: > Und wieso sollte > ich dann noch HTTP-Header auswerten? Falls das CGI "Ding" den Usernamen braucht, sei es nur zur Willkommenanzeige.. Matthias schrieb: > Das hatte ich schon. Ueber das mysql Modul des Servers. Lief toll, nur > halt versteckt hinter den Kulissen und das wollte ich selber machen um > es zu verstehen. Nun das Konzept solte ja klar sein, die Implementierung ist ja nicht so interessant behaupte ich mal. Die Sourcen vom Apache und seinen Modulen kannst du dir ja ansehen weil es Open Source ist, und auch in C gerschrieben ;) https://github.com/apache/httpd Allerdingsm macht man das eigentlich nie wenn man dyn. Webseiten schreibt, man nutzt das Zeug und hat hoffentlich ein konzeptionelles Verstaednis.
@ Mladen Du hattes Recht. Ich bin an mehreren Stellen im Netz darauf gestoßen, dass Dein theoretischer Weg realisierbar sein soll. Nun habe ich, bevor ich das Ganze in mein ohnehin überfülltes CGI-Skript schreibe, erst einmal einen kleinen TCP-Client gebastelt, der selbiges tun soll. Siehe hierzu die Fkt. HTTPRequest. Egal wie ich den Header bearbeite, er will einfach nicht. Nach dem ersten Aufruf kommt logischerweise eine HTTP 401 zurück und nach der zweiten dann die HTTP 501 -Method not implemented- Und ich habe nicht die blasseste Ahnung warum... Hier mal mein TcpClient.
1 | #include <stdio.h> |
2 | #include <stdlib.h> |
3 | #include <errno.h> |
4 | #include <netinet/in.h> |
5 | #include <arpa/inet.h> |
6 | #include <netdb.h> |
7 | |
8 | //-------------------------------------------------------------------------
|
9 | char *Namensaufloesung(const char *dns){ |
10 | char *ipString; |
11 | struct hostent *hostData; |
12 | struct in_addr **adressPointer; |
13 | |
14 | if(gethostbyname(dns) == NULL){perror("[GETHOSTBYNAME]"); exit(1);} |
15 | hostData = gethostbyname(dns); |
16 | adressPointer = (struct in_addr **)hostData->h_addr_list; |
17 | ipString = inet_ntoa(**adressPointer); |
18 | return ipString; |
19 | }
|
20 | |
21 | //-------------------------------------------------------------------------
|
22 | int CreateSocket(char *ip, int portnummer){ |
23 | int sockfd, conValue; |
24 | struct sockaddr_in adress; |
25 | |
26 | sockfd = socket(AF_INET, SOCK_STREAM, 0); |
27 | adress.sin_family = AF_INET; |
28 | adress.sin_port = htons(portnummer); |
29 | adress.sin_addr.s_addr = inet_addr(ip); |
30 | conValue = connect(sockfd, (struct sockaddr *)&adress, sizeof(adress)); |
31 | printf("[CONVALUE %d]\n",conValue); |
32 | if(conValue == 0)printf("Verbindung steht...\n"); |
33 | else perror("[CONNECT]"); |
34 | return sockfd; |
35 | }
|
36 | |
37 | //-------------------------------------------------------------------------
|
38 | void HttpRequest(int socketNummer){ |
39 | char befehl[] = "GET /secret/webpage_2.html HTTP/1.1\r\nHost: localhost\r\n\r\n"; |
40 | char befehl2[] = "GET /secret/webpage_2.html HTTP/1.1\r\nHost: localhost\r\nAuthorization: Basic 'mein base64 kodiertes BN:PW'\r\n\r\n"; |
41 | char empfangen[10000]; |
42 | |
43 | write(socketNummer, befehl, sizeof(befehl)); |
44 | read(socketNummer, empfangen, sizeof(empfangen)); |
45 | printf("%s\n",empfangen); |
46 | write(socketNummer, befehl2, sizeof(befehl2)); |
47 | read(socketNummer, empfangen, sizeof(empfangen)); |
48 | printf("%s\n",empfangen); |
49 | }
|
50 | |
51 | //-------------------------------------------------------------------------
|
52 | int main(int argc, char *argv[]){ |
53 | char *ip; |
54 | int socketNr, port; |
55 | |
56 | if(argc != 3){printf("[USAGE] ./client <DomainName> <Port>\n"); exit(1);} |
57 | ip = Namensaufloesung(argv[1]); |
58 | port = atoi(argv[2]); |
59 | socketNr = CreateSocket(ip, port); |
60 | HttpRequest(socketNr); |
61 | return 0; |
62 | }
|
Ergaenzend zu dem obigen Quelltext, hier mal die Ausgabe des Apache Error Logs, welche darauf hindeutet, dass es tatsaechlich am HTTP Header zu liegen scheint. [Sat Jan 31 03:03:29 2015] [error] [client 127.0.0.1] malformed header from script. Bad header=<p>[fill_data_structs()] "stri: search_db.cgi, referer: http://localhost/webpage_main.html
Vielleicht hilft http://de.wikipedia.org/wiki/HTTP-Authentifizierung Hast du den Base64-Teil in (einfachen) Hochkommas? Oder war das nur zur Illustration? Sind bei Dir am Schluss eigentlich auch 2 mal "="? Hast du mal Wireshark probiert? Vielleicht mal verglichen mit einer funktionierenden Seite?
> Hast du den Base64-Teil in (einfachen) Hochkommas? Nein, dass war nur zur Demonstration. Der base64 kodierte Part steht so im Header, ohne Klammern. > Sind bei Dir am Schluss eigentlich auch 2 mal "="? Nur einmal. > Hast du mal Wireshark probiert? Das habe ich gemacht. Wireshark sieht gut aus. Allerdings gibt es einen kleinen Unterschied. Diese Ausgabe basiert darauf, dass ich nach Aufruf der 'geheimen' Seite meine Daten in eine Messagebox eingebe, AuthBasic innerhalb der Apache Konfig eben. Bei meinem Programm werden die Benutzerdaten via HTML-Form und CGI verarbeitet und dann via HTTP-Header mit 'Authorization' uebermittelt. So der Plan, bzw. so 'soll' es ja prinzipiell auch gehen, steht ja ueberall im Netz so. Einfach den Header ergaenzen, fertig. Ich bekomme aber immer 501 'Method not implemented'. Also mir scheint es so, als wuerde das vom Apache kommen, aber wenn der das nicht kann, welcher Server dann?!
Wenn man sein Authentifikator nutzen will, dann setzt man Ihn i.d.R vor alle seine Scripte, so das er jedesmal aufgerufen wird, wenn eine Seite geladenn wird. Er Prüft dann ob es eine gültige Session gibt und lässt den Benutzer weiter oder erzeugt eine entsprechende Fehlermeldung! Ansonsten kannst Du eventuell so deine Lösung an Apache ranflanschen, ist aber sicher sehr aufwendig https://code.google.com/p/mod-auth-external/wiki/ConfigApache24
@ Sven L. Du beziehst Dich eingangs lediglich auf die Reihenfolge der Authentifizierung. Wie sieht denn Deine Einschätzung bezogen auf meine bisherige Vorgehensweise aus? Ich sende die Authentifizierung ja mittels meines HTTP-Headers direkt mit dem HTTP-Request, also er ja im Prinzip die Möglichkeit im Vorfeld auf einen gültigen User/Zugriff zu prüfen.
@Sven L. ES FUNKTIONIERT!!!!!!!!!!!!!!!!!!!! Thema Reihenfolge. Ich habe einmal ueberprueft, was passieren wuerde, wenn ich statt meines Beispiels aus dem obigen Quellcode, Deinen Tipp bezueglich der Reihenfolge beachte und direkt den Auth-Header sende. ERFOLG. Der einfache TcpClient gibt mir die "verborgene" Seite aus. NEUES PROBLEM. Mache ich das gleiche in einem CGI Skript, bekomme ich im ErrorLog die Nachricht, das mein CGI Skript vorzeitig abgebrochen wurde. Zwei Fragen hierzu...Kann ich in einem CGI Skript ueberhaupt einen TcpSocket aufbauen und zweites, was passiert, wenn ich ueber das CGI-Skript einen Socket aufbaue, via write() meinen HTTP-Header sende, wird die Ausgabe dann an den Socket oder den Browser geschickt? Falls ersteres eintritt, wie bekomme ich letzteres dann hin?
Matthias schrieb: > ES FUNKTIONIERT!!!!!!!!!!!!!!!!!!!! Das ist doch schon mal Klasse > > Thema Reihenfolge. Ich habe einmal ueberprueft, was passieren wuerde, > wenn ich statt meines Beispiels aus dem obigen Quellcode, Deinen Tipp > bezueglich der Reihenfolge beachte und direkt den Auth-Header sende. Irgendwie versteh ich nicht ganz wie Du das meinst... Ich habe sowas halt mal in php gemacht, und in allen Scripten einfach meine login-Klasse mit require_once vorrangestellt. Die hat dann geprüft ob es eine Sitzung gibt oder niht. > > ERFOLG. Der einfache TcpClient gibt mir die "verborgene" Seite aus. Ist das gut oder schlecht? Man kann einen Apache so konfigurieren, das er kein Verzeichnislisting aus gibt, wenn man den Pfad zu einer Datei kennt bekommt man Sie meist trotzdem. > > NEUES PROBLEM. Mache ich das gleiche in einem CGI Skript, bekomme ich im > ErrorLog die Nachricht, das mein CGI Skript vorzeitig abgebrochen wurde. Vielleicht hilft es einen entsprechenden Exit-Code zu übergeben? > > Zwei Fragen hierzu...Kann ich in einem CGI Skript ueberhaupt einen > TcpSocket aufbauen und zweites, was passiert, wenn ich ueber das > CGI-Skript einen Socket aufbaue, via write() meinen HTTP-Header sende, > wird die Ausgabe dann an den Socket oder den Browser geschickt? Soweit ich mich an CGI erinnere, kannst Du damit so ziemlich alle Schweinereien machen, die Du dir vorstellen kannst, entsprechende Rechte vorausgestezt. Nicht selten wurden Webserver über CGI gehackt. > > Falls ersteres eintritt, wie bekomme ich letzteres dann hin? ? Aber nochmal, da ich denke wir haben uns etwas falsch verstanden, das was ich meinte ist eine Lösung im Script selber, HTTP-Auth-Header sind auf Webserverebene, kommen also vor allem Content. Mein 1. Hinweis bezog sich auf eine Lösung im Script, mein 2. Hinweis meinte, das Du dem Apache sagst, das er zur Authentifizierung ein von dir geschriebenes CGI Aufrufen soll und damit was macht. Also Form senden -> CGI Script -> das gibt True oder False Zurück. Je nach Umgebung lässt man den Apache ja gerne mal gegen ein anderes System authentifizieren, eben dahin, wo man die Benutzer schon hat! Das was Du vorhast, mit mysql, dafür gibt es übrigend auch ein fertiges Modul. Ich weiß ja nicht in welchem Umfeld Du das ganze einsetzen willst, wenn es im Internet ist, nimm das fertige Modul wegen der Sicherheit!
@ Sven L. >Irgendwie versteh ich nicht ganz wie Du das meinst... Stichwort Reihenfolge. Das obige Codebeispiel...Ich habe zwei Header nacheinander gesendet, erst den normalen ohne Auth und den zweiten, als Reaktion auf die 401 Server Meldung, dann mit Auth. >Ist das gut oder schlecht? Gut, wenn Du meine Eingangsposts liest habe ich das ja so realisiert, es scheiterte immer am Zugriff, aber dazu am Ende <dieses Posts> mehr, DENN ALLES LÄUFT JETZT PERFEKT >Das was Du vorhast, mit mysql, dafür gibt es übrigend auch ein fertiges Modul. Nicht das was ich vorhabe, sondern was alles schon fertig gebaut war/ist, in C. Einzig und allein mit der Athentifizierung hat es gehapert. Das war ja auch der Sinn des Ganzen. Nicht via Fertigmodule, sondern selbst gebaut in C, weil ich etwas Lernen wollte. Ich habe jetzt das, was ich wollte und das sieht wie folgt aus UND LÄUFT. Eine einfache HTML-Website zur Begrüßung. Ein <form>-Tag bei dem sich der User authentifizieren kann/muss. Wofür? Für die Website, welche ich eine Sperrung via AuthType Basic in der Apache Konfiguration angelegt habe. Diese gesperrte Seite und deren Verzeichnis sind für den User unsichtbar, werden im Listing nicht angezeigt. Nachdem der User dem <form>-Tag seine Daten gegeben hat, werden diese innerhalb des CGI-Skripts extrahiert, geparst und in Strings kopiert. Diese Strings werden ueber die C-API mit einer mysql-Datenbank verglichen und bei einem Erfolg, baut sich ein TCP-Socket auf, der die "geheime" Seite durch Senden eines eigenen HTTP-Auth-Headers aufruft. Davor werden die BN-Daten auch noch in einem selbstgebastelten base64-Converter kodiert, für die Übertragung. Alles in allem ist die Bezeichnung Skript etwas tiefgestapelt, aber es dürfte auch klar werden weshalb ich das Ganze so und nicht anders gemacht habe. Man lernt extrem viel. Klar, ein Javaskript und etwas Magie hätten es auch getan, aber ohne Lerneffekt eben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.