Anmeldeformular

…für meine Webseite.

Hallo erstmal,
ich weiß, das dieses Thema in sehr vielen Foren aufgegriffen wird. Dennoch komme ich nicht ganz klar, da ich in diesem Gebiet mich überhaupt nicht auskenne.

Also, ich benötige für meine Webseite erstens, ein Formular wo man sich registrieren kann. Zweitens, ein Formular zur Anmeldung auf der Webseite.

Und dann noch, wenn man nicht angemeldet ist, kommt man auch nicht auf die und die Seite.

Ersteinmal, wird so ein Script per PHP gemacht oder mit einer anderen Sprache ?
Und dann, unterstützen manche Provider so etwas ??? oder viele ???
Und zu guter letzt, wie macht man sowas ???

Also, ich bitte darum, das mir mal bitte jemand ne Anleitung schreibt, wie man so was macht. Oder ne Webseite.

Sollt ich vielleicht gleich ein Experten holen, der das für mich schreibt ?

Ich habe mir nähmlich gedacht, das das ja gar nicht so schwer sein kann, wenn fast jede 2. Webseite eine Anmeldung erfordert.

Danke für die hoffentlich kommenden zahlreichen Antworten und für jeden, der sich für meine Frage Zeit nimmt.

wissensfreak

Hi,

such mal per google danach. Da gibt es jede Menge Scriptbeispiele im Netz.
Im Prinzip funktioniert das ganze so:

Ein Formular sendet die Daten an einen Server mit Benutzername und Passwort.
Das Serverscript (PHP, ASP oder was auch immer) prüft ob Benutzername und Passwort harmonieren. Üblicherweise über eine Datenbankabfrage.
Sprich die User liegen in einer Datenbank (MySQL, MSsql, Access, …)
…schliesslich wollen die user ja auch Ihr passwort ändern können.
Wenn user und password passen, dann setzt man eine servervariable.

Bei jedem einzelnen Seitenaufruf prüft man jetzt am anfang der seite wieder per script ob die variable gesetzt ist oder nicht.
wenn ja, seite anzeigen, wenn nein, zum login redirecten.

Sorry, dass ich dir hier kein Script schreibe, aber erstens gibt es tausen möglichkeiten das zu tun (z.B. auch AJAX) und es kommt auch drauf an welche technischen Vorraussetzungen du hast und auch auf deine Seite selbst.

MySQL und einen serverbasierte Scriptsprache sind auf jeden Fall mal eine gute Vorraussetzung.

Gruß
Proteus

Sorry,
natürlich gibts noch einen Link, wenn ich schon sage, dass es im Netz viel gibt…

http://www.administrator.de/index.php?content=40282

Gruß
Proteus

Hallo Proteus,
ich bin immer fasziniert, das ich so schnell und sehr gute und ausführliche Antworten bekomme.

vielen Dank, wissensfreak

hallo wissensfreak,

für solche Interaktion braucht man cgi = Common Gateway Interface = Allgemeine Vermittlungsrechner-Schnittstelle

Also brauchst Du einen Provider, der Dir dieses zur Verfügung stellt. Immer noch :smile:)

Ansonsten nutzen Dir diese scripte überhaupt nichts!!!
Ich verstehe überhaupt nicht, warum Du noch einen Artikel ähnlichen Inhaltes einstellst.

gruß
klaus

Hallo KKO,
Sorry, das ich das nochmal mache. Aber, ich hoffe auf Links zu einem Script oder einer Webseite, die mir alles ganz genau erklärt.

Sorry, wissensfreak

Moin,

für solche Interaktion braucht man cgi = Common Gateway
Interface = Allgemeine Vermittlungsrechner-Schnittstelle

Das ist falsch!
Es ist eine Möglichkeit, das über die CGI-Schnittstelle zu machen, dann kann man theoretisch jede Programmiersprache dazu verwenden, aber ein Muss ist das nicht.
PHP läuft z.B. in den Webservern in der Regel als Apache-Modul. Das ist dann eine Möglichkeit ohne die CGI-Schnittstelle.

Grüße,
-Efchen

1 „Gefällt mir“

tach,

für solche Interaktion braucht man cgi = Common Gateway
Interface = Allgemeine Vermittlungsrechner-Schnittstelle

Das ist falsch!
Es ist eine Möglichkeit, das über die CGI-Schnittstelle zu
machen, dann kann man theoretisch jede Programmiersprache dazu
verwenden, aber ein Muss ist das nicht.
PHP läuft z.B. in den Webservern in der Regel als
Apache-Modul. Das ist dann eine Möglichkeit ohne die
CGI-Schnittstelle.

falsch ist falsch!!

es ist aber im grunde egal, ob als modul oder cgi-binary.
(das perl-modul wird auch im apache eingebunden)

denn das cgi ist die vermittlungsstelle zwischen webserver und einem programm auf dem server. und ohne cgi könnten z.b. die umgebungsvariablen nicht übergeben werden.

du ruftst ja nicht das programm direkt auf, sondern der server leitet ist mittels cgi an das programm weiter.

und einfacher webspace hat eben kein cgi … und so verhält es sich bei wissensfreak :smile:)

gruß
klaus

für solche Interaktion braucht man cgi = Common Gateway
Interface = Allgemeine Vermittlungsrechner-Schnittstelle

Das ist falsch!

falsch ist falsch!!

Nein. So wie Du es geschrieben hast („man braucht dafür CGI“) ist es falsch. Man kann CGI verwenden, muss aber nicht.

es ist aber im grunde egal, ob als modul oder cgi-binary.

Das sollte meine Antwort aussagen.

(das perl-modul wird auch im apache eingebunden)

Nicht zwingend. Ich persönlich habe Perl bisher mehr im CGI-Umfeld gesehen. Aber man kann ja auch PHP über CGI benutzen.

denn das cgi ist die vermittlungsstelle zwischen webserver und
einem programm auf dem server. und ohne cgi könnten z.b. die
umgebungsvariablen nicht übergeben werden.

Wenn die Sprache als Servermodul eingebunden ist, eben schon.

du ruftst ja nicht das programm direkt auf, sondern der server
leitet ist mittels cgi an das programm weiter.

Bei CGI ja, als Modul nicht.

und einfacher webspace hat eben kein cgi … und so verhält es
sich bei wissensfreak :smile:)

Kommt drauf an, was man unter „einfach“ versteht. Arcor bietet anscheinend auch kostenfreien Webspace mit PHP an. Wenn die kein CGI anbieten, lässt sich das Problem aber eben doch noch lösen.

für solche Interaktion braucht man cgi = Common Gateway
Interface = Allgemeine Vermittlungsrechner-Schnittstelle

Das ist falsch!

falsch ist falsch!!

Nein. So wie Du es geschrieben hast („man braucht dafür CGI“)
ist es falsch. Man kann CGI verwenden, muss aber nicht.

auch wenn es als modul eingebunden ist es cgi
wie willst du an die formulardaten kommen, wenn sie nicht über cgi zu verfügung gestellt werden?

es ist kein cgi nötig, wenn du php- oder perlscripte direkt über den interpreter laufen oder in einer shell ausführen lässt. aber dann arbeitest du mit übergabeparametern und nicht mit cgi-umgebungsvariablen

so …
und mehr werde ich zu dem thema nicht mehr schreiben :smile:)

auch wenn es als modul eingebunden ist es cgi

Das ist mir neu. Kannst Du mich anhand eines Links erleuchten?

und mehr werde ich zu dem thema nicht mehr schreiben :smile:)

Das finde ich schade. Warum auf Deinem Wissen sitzen bleiben, wenn sogar ich noch was lernen kann?

Grüße,
-Efchen

CGI
Moin.

Womöglich ein Missverständnis; ich zitiere Wikipedia:
Das Common Gateway Interface (CGI) – in etwa Allgemeine Vermittlungsrechner-Schnittstelle – ist ein Standard für den Datenaustausch zwischen einem Webserver und dritter Software, die Anfragen bearbeitet.
und weiter unten:
Ein Nachteil der CGI-Ausführung ist ihre relativ geringe Geschwindigkeit, da für jeden CGI-Aufruf ein neuer Prozess ausgeführt wird. Auf hochfrequentierten Seiten wird CGI daher heutzutage nicht mehr so oft eingesetzt, denn selbst Ansätze wie FastCGI, welches gewisse Nachteile von CGI aufhebt, konnten sich zumindest nicht auf breiter Front durchsetzen.

Quelle: http://de.wikipedia.org/wiki/Common_Gateway_Interface

Grüße

Leo

Das bedeutet doch für mein Verständnis, dass ich recht habe, oder? Wenn PHP oder Perl per Modul genutzt werden, ist das NICHT die CGI-Schnittstelle, richtig?

na gut…

es darf nicht verwechselt werden zwischen cgi-binary oder modul und nutzen der cgi-umgebung.

cgi selbst wird als module (mod_cgi) eingebunden.
ebenso werden die tools, um cgi nutzen zu können vom server bereitgestellt. (perl, php, python)

Die CGI-Umgebungsvariablen (environment variables) sind festgelegte, namentlich nicht veränderbare Variablen, welche beim Aufruf eines CGI-Skripts in der CGI-Schnittstelle automatisch ihre entsprechenden Werten zugewiesen bekommen.
Die Umgebungsvariablen sind in Form eines Hashes namens %ENV organisiert und damit über die entsprechende Methodik in Perl auslesbar.
Sie sind aufgrund ihrer wichtigen Informationen beispielsweise zum Browser des Clients, zum Server, zum aufrufenden CGI-Skript, u.a. sehr nützlich. Des Weiteren werden als eines der wichtigsten Umgebungsvariablen auch Inhalte der Felder eines Formulars, welches das Skript via POST aufrief, in die CGI-Schnittstellen-Umgebung geschrieben. Sie sind aus dem STDIN mit Hilfe der Variable $ENV{„CONTENT_LENGTH“} auslesbar. Mehr Informationen dazu erhalten Sie im entsprechenden Abschnitt.
Bei einigen dieser Umgebungsvariablen ist es auch möglich selbst ihre Werte zu verändern.
Die Verfügbarkeit der Umgebungsvariablen hängt von der Konfiguration des Servers ab! So zum Beispiel ließe sich eine zeilenweise Auflistung der auf dem Server verfügbaren Umgebungsvariablen realisieren:

Übersicht wichtiger CGI-Umgebungsvariablen

Die nachfolgende Übersicht enthält die wichtigsten CGI-Umgebungsvariablen, deren Wert teilweise nur gespeichert wird, wenn es die Konfiguration des Servers zulässt:
Schlüsselname in %ENV Enthält
CONTENT_LENGTH Anzahl der übergebenen Zeichen nach Aufruf des CGI-Skripts mit POST
CONTENT_TYPE Mime-Type des Datenstroms bei Aufruf des CGI-Skripts mit POST
DOCUMENT_ROOT Pfadnamen des Wurzelverzeichnisses
GATEWAY_INTERFACE Version der auf dem Server installierten CGI-Schnittstelle
HTTP _ACCEPT Liste aller Mime-Types, welche der Browser des Clients unterstützt (*/* bedeutet, dass alle Mime-Types von ihm unterstützt werden)
HTTP _ACCEPT_ENCODING Kodierungsfähigkeiten des Client-Browsers (z.B.: gzip, deflate)
HTTP _ACCEPT_LANGUAGE Landessprache des Client-Browsers
HTTP _COOKIE Cookienamen und -werte, wenn vom Client-Browser gesendet; Durch @Cookies = split(/[;,]\s*/,$ENV{’ HTTP _COOKIE’}); lässt sich ein Array @Cookies mit Name-Wert-Paarungen (getrennt durch =) erzeugen
HTTP _HOST Domain oder IP des Servers auf dem das CGI-Skript ausgeführt wird
HTTP _REFERER URL, von der aus das CGI-Skript aufgerufen wurde
HTTP _USER_AGENT Name und Version des Client-Browsers (z.B.: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1))
PATH_INFO Teilzeichenkette nach Pfad des aufgerufenen CGI-Skripts und vor dem ersten Fragezeichen (?); von Interesse, wenn ein Pfadname direkt nachURLdes CGI-Skripts als Parameter mit GET übergeben wird
QUERY_STRING Zeichenkette, welche dem CGI-Skript mit GET übergeben wurde
REMOTE_ADDR IP des Rechners/Servers, über den das CGI-Skript aufgerufen wurde
REMOTE_HOST Hostname des Rechners/Servers, über den das CGI-Skript aufgerufen wurde
REMOTE_IDENT Protokollinformationen, wenn auf dem Server das Protokoll ident für geschützte Zugriffe installiert ist
REMOTE_PORT Port des Client-Rechners, über den das CGI-Skript aufgerufen wurde
REMOTE_USER Name des aufrufenden Users, welcher auf das CGI-Skript zugreifen möchte (nur bei Server-Authentifizierung, z.B. htaccess)
REQUEST_METHOD Information, ob das CGI-Skript mit POST oder GET aufgerufen wurde
REQUEST_URI HTTP-Pfad des CGI-Skripts inkl. übergebene Daten (z.B. /cgi-bin/ Perl test.cgi?new)
SCRIPT_NAME HTTP-Pfad des CGI-Skripts (z.B.: /cgi-bin/ Perl test.cgi)
SCRIPT_FILE_NAME physischen Pfad des CGI-Skript (z.B.: /usr/bin/cgi-bin/ Perl test.cgi)
SERVER_ADDR IP des Servers
SERVER_ADMIN Emaildresse des Server-Admins laut Serverkonfiguration
SERVER_NAME Name des Servers; i.d.R. Hostname des Servers
SERVER_PORT Post des Servers (Standard: 80)
SERVER_PROTOCOL Version des vom Server unterstützten HTTP-Protokolls
SERVER-SIGNATURE Signatur des Servers (z.B. Apache /2.0.39 Server at localhost Port 80)
SERVER_SOFTWARE Name und Version des Servers (z.B. Apache /2.0.39 (Win32))
SYSTEMROOT Wurzelverzeichnis des Server-Betriebssystems

* mod_php

Performant oder anders gesagt der Server kann auch etwas älter sein bzw. im shared Hosting Bereich können sich mehr Kunden einen Server teilen. Allerdings weniger sicher und komfortabel.

* PHP CGI (verwendet bevorzugt von „MassenServern“)

Benötigt mehr Ressourcen, für den Seitenbetreiber um einiges komfortabler und durch die Möglichkeit die Rechte restriktiver zu verteilen größere Sicherheit.

gruß
klaus

Sei mir nicht böse, aber das war mir jetzt nicht wirklich neu.

Aber Deine Aussage ging doch in die Richtung, dass eingebettetes PHP auch CGI sei. Die Aussage stimmt IMHO nicht, als „CGI“ bezeichnet man doch die Schnittstelle, die benutzt wird, wenn man beliebige externe Programme aufruft.

Ich möchte Deinen Standpunkt verstehen, möchte verstehen, wenn das wirklich so ist, aber wo ist mod_php denn CGI? Vertrittst Du die Meinung, dass alles CGI ist, und dass wenn man nur bei externen Programmen von CGI spricht, dass die Menschen sich da einfach falsch ausdrücken?

Kläre mich bitte auf. Ich veräppel Dich nicht :smile: Ich will, dass das, was ich anderen Leuten erkläre, richtig ist. Aber bis Du mich überzeugt hast, werde ich weiter sagen, dass PHP (als Modul) nicht CGI ist.

Danke,
-Efchen

Wenn ich google stoße ich auf solche Sätze:

„PHP gibt es als Server-Modul etwa für Apache, aber man wird relativ schnell darauf stoßen, dass es PHP auch auf CGI-Basis gibt.“

„Im Unterschied zu mod_php muss CGI bei jedem Zugriff aufgerufen werden welcher wiederum das PHP Binary aufruft.“

Sowas bekräftigt meine Aussagen und lässt Deine als falsch da stehen. Wobei mir natürlich klar ist, dass im WWW auch viel Mist steht.