nicht angemeldet
Robert
0 loginscript tutorial, problem
0 0 0 0 0 0 0 
MudGuard
Robert
Hallo liebe Gemeinde, vielleicht kann mir jemand sagen, was falsch gemacht wurde bzw. wie ich es ändern muus. Ich arbeite gerade ein Tutorial zu Loginscript, Register, Profil und Adminbereich durch (siehe: Workshop login). Soweit so gut, die Registerierung, sowie das Login funktionieren bereits erfolreich. Leider gibt es ein Problem mit den Profiländerungen. Ich denke es liegt am folgedem Teil:
echo "<form ".
" name=\"Passwort\" ".
" action=\"".$_SERVER['PHP_SELF']."\" ".
" method=\"post\" ". [...]
Wenn ich das alles so stehen lasse, geht er auf click bei Daten ändern direkt zur index.php und keine Änderungen finden statt. Wenn ich bei action="" den direkten Link einsetze, geht er natürlich wieder auf die myprofil.php, allerdings natürlich ohne Änderungen. Die komplette myprofil.php findet ihr auf myprofil.php
Falls es noch wichtig ist, wie die Seiten bei mir aufgerufen werden:
<?php
if (isset($_GET['page']))
$page = $_GET['page'];
else
$page = '';
if($page=="")
{
include"start.php"; [...]
}[/code]
Ein Link sieht dann so aus: index.php?page=start.php
-
Hello Robert,
steigst Du denn da überhaupt durch?
Die Strukturierung des ganzen Systems könnte sehr verbessert werden.Und was nun wirklich Deine Frage war, habe ich jetzt nicht verstanden, außer dass Du sinngemäß fragst "warum funktioniert das nicht?"
Durch Einsatz von streng abgegrenzten Funktionen kann man solch ein Projekt viel leichter lesbar machen und außerdem auch besser wartbar.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
steigst Du denn da überhaupt durch?
Die Strukturierung des ganzen Systems könnte sehr verbessert werden.»»
Ja, das geht schon - verstehe das zwar noch nicht 100%ig, allerdings bin ich auch noch in Lernphase, weshalb ich auch dieses Tutorial mitmache.Und was nun wirklich Deine Frage war, habe ich jetzt nicht verstanden, außer dass Du sinngemäß fragst "warum funktioniert das nicht?"
Meine Frage ist, wie ich es hinbekomme - dass die Seite nicht einfach neu lädt, sondern die Daten übernimmt. So wie der Code jetzt ist, geht er auf die index.php nachdem man submit macht, ohne Änderungen zu übernehmen. Wenn ich statt dem $Server[...] die Adresse einfüge, auf welche weitergeleitet werden soll (also ..../myprofil.php, lädt er nur die Seite neu, ohne speichern der geänderten Daten.
Durch Einsatz von streng abgegrenzten Funktionen kann man solch ein Projekt viel leichter lesbar machen und außerdem auch besser wartbar.
Das glaube ich auch, aber ich habe dieses Tutorial nicht gemacht, ich möchte nur daraus lernen und keinen produktiven Einsatz mit dem System machen. Daher möchte ich es mal zum laufen bekommen und dann ggf. umschreiben.
Gruß
Robert-
Hello,
steigst Du denn da überhaupt durch?
Die Strukturierung des ganzen Systems könnte sehr verbessert werden.
»»
Ja, das geht schon - verstehe das zwar noch nicht 100%ig, allerdings bin ich auch noch in Lernphase, weshalb ich auch dieses Tutorial mitmache.Und was nun wirklich Deine Frage war, habe ich jetzt nicht verstanden, außer dass Du sinngemäß fragst "warum funktioniert das nicht?"
Meine Frage ist, wie ich es hinbekomme - dass die Seite nicht einfach neu lädt, sondern die Daten übernimmt. So wie der Code jetzt ist, geht er auf die index.php nachdem man submit macht, ohne Änderungen zu übernehmen. Wenn ich statt dem $Server[...] die Adresse einfüge, auf welche weitergeleitet werden soll (also ..../myprofil.php, lädt er nur die Seite neu, ohne speichern der geänderten Daten.
Dann suche dir zuerst ein einfacheres Tutorial. Das passende Thema wäre mMn "Affenformular". Da kannst Du bei Wikipedia anfangen
http://de.wikipedia.org/wiki/AffenformularDas ist allerdings noch etwas "sparsam". Also such dir noch weitere Webseiten zu dem Thema und versuche, erst einmal das Wechselspiel von Request und Response zu verstehen.
Dann kannst Du als nächstes versuchen, eine Kontrollstruktur ins Affenformular einzubauen, sodass z.B. ein Blog daraus wird mit unterschiedlichen Funktionen, wie:
- Einträge anzeigen
- Formular für Neueintrag anzeigen
- Neueintrag überprüfen und Vorschau anzeigen
- Neueintrag eintragen und Bestätigungsseite anzeigen
- Eintrag auswählen
- ausgewählten Eintrag bearbeiten
- ausgewählten Eintrag kommentieren
- ausgewählten Eintrag sperren/freigeben/löschen
usw.
Das geht im Prinzip noch alles ohne Session. Dann darf aber jeder alles.
Wenn Du das hinbekommen hast, kannst Du ein Rechtesystem einbauen und entscheiden, welcher User welche der Funktionen nutzen darf. Dazu beachte, dass Du diese Funktionen auch nur demjenigen Benutzer anzeigst, der sie benutzen darf, aber auch bei der Benutzung nochmals prüfen musst, ob der Benutzer dazu berechtigt ist, denn HTTP ist Zustandslos. Zwischen Anzeige und neuerlichem Request (Benutzung) besteht also kein Zusammenhang.
Und trenne von vornherein Kontrollstrukturen, Datenverarbeitung und Anzeige sauber voneinander
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Dann suche dir zuerst ein einfacheres Tutorial. Das passende Thema wäre mMn "Affenformular". Da kannst Du bei Wikipedia anfangen
http://de.wikipedia.org/wiki/AffenformularDies habe ich so ziemlich am Anfang mal etwas angetestet.
Das ist allerdings noch etwas "sparsam". Also such dir noch weitere Webseiten zu dem Thema und versuche, erst einmal das Wechselspiel von Request und Response zu verstehen.
Die vers. Aufrufe etc. von dem was ich gepostet habe verstehe ich schon, nur ich verstehe nicht - wie ich die geänderten Daten speichern kann. Da mit $Server auf die index.php gewechselt wird und wenn ich die myprofil.php angebe sich die Seite nur neu lädt (was auch klar ist). Ich würde da gerne wissen, wie ich das machen kann, dass er zur eigentlich nächsten Seite springt und mir anzeigt, dass es erfolgreich war oder nicht (entsprechende messages sind ja hinterlegt, dreht sich nur um den submit).
Wenn Du das hinbekommen hast, kannst Du ein Rechtesystem einbauen und entscheiden, welcher User welche der Funktionen nutzen darf. Dazu beachte, dass Du diese Funktionen auch nur demjenigen Benutzer anzeigst, der sie benutzen darf, aber auch bei der Benutzung nochmals prüfen musst, ob der Benutzer dazu berechtigt ist, denn HTTP ist Zustandslos. Zwischen Anzeige und neuerlichem Request (Benutzung) besteht also kein Zusammenhang.
Habe sowas schon gemacht, quakenet tutorial, da hat alles geklappt - war allerdings mit alles mit templates und das fand ich nicht so toll.
Und trenne von vornherein Kontrollstrukturen, Datenverarbeitung und Anzeige sauber voneinander
Werde ich tun, sobald ich die myprofil.php zum laufen bekommen habe. Hat vorerst mal keinen Sinn, da ich sonst in x Stunden wieder vor dem selben Problem stehe.
Gruß
-
-
-
moin,
echo "<form ".
" name="Passwort" ".
" action="".$_SERVER['PHP_SELF']."" ".
" method="post" ". [...]> > Wenn ich das alles so stehen lasse, geht er auf click bei Daten ändern direkt zur index.php und keine Änderungen finden statt. Wenn ich bei action=\"" den direkten Link einsetze, geht er natürlich wieder auf die myprofil.php, Vielleicht solltest Du mal ins Serverlog schauen, welcher URI bei einem Submit, was ein POST sein soll, requestet wird. > Ein Link sieht dann so aus: index.php?page=start.php Ein Klick auf diesen "Link" erzeugt einen GET-Request. Relative Pfadangabe: Der Request an index.php ist dann auch relativ zum URI der Seite, in welcher solch ein Link notiert ist. Blick ins Log. Hotti-
Ein Link sieht dann so aus: index.php?page=start.php
Ein Klick auf diesen "Link" erzeugt einen GET-Request. Relative Pfadangabe: Der Request an index.php ist dann auch relativ zum URI der Seite, in welcher solch ein Link notiert ist. Blick ins Log.
Hallo danke für deine Antwort... Hier der Auszug aus dem Log:
::1 - - [28/Apr/2011:22:13:55 +0200] "POST /schach/index.php?page=myprofil.php HTTP/1.1" 200 4942 "http://localhost/schach/index.php?page=myprofil.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
::1 - - [28/Apr/2011:22:14:05 +0200] "POST /schach/index.php HTTP/1.1" 200 3145 "http://localhost/schach/index.php?page=myprofil.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
-
moin,
::1 - - [28/Apr/2011:22:13:55 +0200] "POST /schach/index.php?page=myprofil.php HTTP/1.1" 200 4942 "http://localhost/schach/index.php?page=myprofil.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
::2 - - [28/Apr/2011:22:14:05 +0200] "POST /schach/index.php HTTP/1.1" 200 3145 "http://localhost/schach/index.php?page=myprofil.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
Dein Formular hat im Request_Uri den Path /schach (in diesem path wird das Formular aufgerufen)
der Post (Submit) hat in beiden Fällen den Status: 200 OK und geht in beiden Fällen an /schach/index.php
in beiden Fällen hat die Antwortseite den URI /index.php?page=myprofil.php (scheme, auth unbetrachtet)
im Fall ::1 gibt es beim Submit zusätzlich zu POST- auch GET-Parameter
in beiden Fällen müssen POST-Parameter in /schach/index.php verarbeitet werden
Die Antwortseite wird in beiden Fällen von /schach/index.php erzeugt.
Da es in der Antwortseite GET-Parameter gibt, sind diese von der Antwortseite zu verarbeiten, in Deinem Fall von /schach/index.php
Hotti
-
in beiden Fällen hat die Antwortseite den URI /index.php?page=myprofil.php (scheme, auth unbetrachtet)
Korrektur; Path ist /schach/index.php
in beiden Fällen hat die Antwortseite den URI /schach/index.php?page=myprofil.php (scheme, auth unbetrachtet)
-
Hallo Hotti,
was bedeutet das nun für mich? Was muss ich den ändern, damit es funktioniert? Habe es mit SERVER Php Self versucht, sowie das Formular erneut aufzurufen (was natürlich nicht funktionieren kann)...
-
hi Robert,
was bedeutet das nun für mich? Was muss ich den ändern, damit es funktioniert? Habe es mit SERVER Php Self versucht, sowie das Formular erneut aufzurufen (was natürlich nicht funktionieren kann)...
Eigentlich musst Du nur die richtigen Parameter(=Values) im Script, was in action="" steht verarbeiten. Der Post geht bei Dir an /schach/index.php Script. Wie Du schreibst, möchtest Du den URI in action="" variabel machen. Hierbei kommt es darauf an, unter welchem URI das Formular erzeugt wird. ['PHP_SELF'] wäre möglich, wenn das Script sowohl das Form erzeugt, als auch den Post verarbeitet, da gänge auch ['SCRIPT_NAME']. Beachte, dass diese Variablen der Server-Umgebung auf den Server bezogen sind und mit einem Slash beginnen.
Hotti
-
-
Moin!
moin,
::1 - - [28/Apr/2011:22:13:55 +0200] "POST /schach/index.php?page=myprofil.php HTTP/1.1" 200 4942 "http://localhost/schach/index.php?page=myprofil.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
::2 - - [28/Apr/2011:22:14:05 +0200] "POST /schach/index.php HTTP/1.1" 200 3145 "http://localhost/schach/index.php?page=myprofil.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
in beiden Fällen hat die Antwortseite den URI /index.php?page=myprofil.php (scheme, auth unbetrachtet)
Falsch, in beiden Fällen KOMMT der Request von dieser URL. Das ist der Referrer.
Ich hab es noch nie erlebt, dass im Server-Logfile die an den Client gesendeten Header mit aufgezeichnet werden - was ja hier passieren würde, wenn das Skript index.php einen Redirect auf diese "Antwortseite" ausgeben würde. Der einzige Header, der im Logfile verzeichnet wird, ist der HTTP-Statuscode. WENN es also einen Redirect gibt, kriegt man den Status im Logfile angegeben, aber man kriegt NICHT angegeben, wohin der Redirect führt.
Da du aber passend analysiert hast, dass Status 200 eben gerade kein Redirect ist, sondern die ganz normale Seitenauslieferung, wieso sprichst du dann von "Antwortseite"? Die für die Antwort verantwortliche URL steht direkt hinter dem "POST".
Deine Logfileanalysen waren auch schon mal besser.
- Sven Rautenberg
-
Hi,
::1 - - [28/Apr/2011:22:13:55 +0200] "POST /schach/index.php?page=myprofil.php HTTP/1.1" 200 4942 "http://localhost/schach/index.php?page=myprofil.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
::2 - - [28/Apr/2011:22:14:05 +0200] "POST /schach/index.php HTTP/1.1" 200 3145 "http://localhost/schach/index.php?page=myprofil.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
in beiden Fällen hat die Antwortseite den URI /index.php?page=myprofil.php (scheme, auth unbetrachtet)
Falsch, in beiden Fällen KOMMT der Request von dieser URL. Das ist der Referrer.Falsch. In beiden Fällen behauptet der Client (oder irgendein Proxy zwischen Client und Server) per Referer-Header, daß der Request von dieser URL kommt ... ;-)
Genauergenommen: daß der Client den Link für diesen Request in der Resource gefunden hat, die von dieser URL kommt.
Ich hab es noch nie erlebt, dass im Server-Logfile die an den Client gesendeten Header mit aufgezeichnet werden - was ja hier passieren würde, wenn das Skript index.php einen Redirect auf diese "Antwortseite" ausgeben würde. Der einzige Header, der im Logfile verzeichnet wird, ist der HTTP-Statuscode.
Content-Length wäre noch ein Kandidat - siehe die Zahl zwischen Statuscode und Referer.
Deine Logfileanalysen waren auch schon mal besser.
Wirklich?
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
-
-
-