nicht angemeldet
wiki: PHP/Anwendung und Praxis/Loginsystem
Camping_RIDER
TSMoin!
Also. Ich habe im Wiki-Artikel PHP/Anwendung und Praxis/Loginsystem ein paar Kleinigkeiten geändert. Und der Status der Downloadversion ist jetzt nicht mehr Alpha, sondern Beta.
Behobene Fehler:
- läuft jetzt auch auf Strato (habe extra ein Testsystem "verstratot")
- kommt nun auch mit Ports jenseits des Standards klar
Beta
Wäre nett wenn diejenigen, die seltsame Konfigurationen (z.B, xampp) haben, das testen und Fehler melden würden.
Jörg Reinholz
-
Moin!
Beta
Wäre nett wenn diejenigen, die seltsame Konfigurationen (z.B, xampp) haben, das testen und Fehler melden würden.
Und wenn sich noch jemand mit mobilem Windows, dem Apfelzeug oder anderer skurrilen Geräten finden würde, der nach einer Anmeldung mit Benutzer: "adm" und dem Passwort "GeHeim" das Frontend der Benutzerverwaltung testet (und die eventuellen Fehler/Unzulänglichkeiten meldet) - dann wäre ich geradezu glücklich.
Jörg Reinholz
-
Aloha ;)
Und wenn sich noch jemand mit mobilem Windows, dem Apfelzeug oder anderer skurrilen Geräten finden würde, der nach einer Anmeldung mit Benutzer: "adm" und dem Passwort "GeHeim" das Frontend der Benutzerverwaltung testet (und die eventuellen Fehler/Unzulänglichkeiten meldet) - dann wäre ich geradezu glücklich.
Skurrile Geräte? Challenge Accepted. Soeben liegt der Nintendo 3DS meiner Frau neben mir. Dann schauen wir doch mal.
Testprotokoll:
Testlinks auf der Login-Seite: Tun was sie sollen.
Eingeloggt.
Die Testlinks funktionieren auch hier wie gewollt.
Administrationswerkzeuge:
Alert: Es ist ein Fehler aufgetreten: [object XMLHttpRequestProgressEvent]Alert: Es ist ein Fehler aufgetreten: {"users":["adm","bar", ...} [object XMLHttpRequestProgressEvent]Anlegen eines neuen Benutzers schlägt fehl (wird nicht angelegt).
Anlegen einer neuen Gruppe - beim Klick auf "Speichern":
Browserfehler: 012-1032 - Diese Datei kann nicht geladen werden.Die Gruppe wurde dennoch angelegt.
Löschen einer Gruppe: Beim Bestätigungsfenster löst ein Klick auf "Ja" keine Aktion aus, der Klick auf "Nein" verfrachtet einen wieder auf die Überblick-Seite.
Vorweg: Natürlich ist eine Unterstützung durch den 3DS nicht unbedingt zu erwarten ;) Trotzdem ist die Analyse testweise interessant, weil sie evtl. besondere Schwachstellen aufdeckt, die bei normalen Konfigurationen nicht auftauchen.
Der Nintendo 3DS benutzt einen von Nintendo selbstgebastelten Browser.
Das Problem mit XMLHttpRequest... würde ich direkt dem unzulänglichen Nintendo-Browser zuschieben; da besteht kein Anpassungsbedarf.
Interessant für mich ist, dass das Benutzer anlegen nicht funktioniert hat (nicht unbedingt verwunderlich, wenns XHR-Probleme gibt), das Gruppe anlegen aber wohl schon (Ich habe das nochmal getestet, es funktioniert tatsächlich.
Auch die Meldung, die mir da erscheint, ist etwas schleierhaft - das ist die Fehlermeldung, wenn irgendeine Datei heruntergeladen werden soll, die das System nicht akzeptiert. Das einzige was da nach dem Klick auf den Button aber kommen sollte, ist HTML. Etwas merkwürdig, vielleicht hat sich an dieser Stelle noch ein Bug versteckt?
Weiter im Text. Gibt es einen Grund, warum der Ja-Button nicht funktioniert, der Nein-Button aber schon? Werden die intern anders angesteuert? Auch hier vielleicht nochmal drüberschauen.
Alles in allem ist das natürlich jammern auf hohem Niveau, im Browser funktioniert ja (fast, siehe unten) alles; auch auf dem kleinen Display des Nintendo ist die Bedienbarkeit super.
Während ich das geschrieben habe, sind mir noch zwei weitere Dinge aufgefallen (diesmal im Google Chrome / Windows 7):
1.: Ich habe mal Testweise mein Browserfenster klein gezogen. Das flackert beim Ziehen ganz ungut. Das ist nicht weiter tragisch (wer zieht schon die ganze Zeit sein Fenster groß und klein), aber doch nicht normal - deshalb die Erwähnung.
2.: Es gibt in den devtools ein Warnung: "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/."
3.: Der "Daten neu laden"-Button hat zwischendurch nicht funktioniert und bei jeder Betätigung Fehlermeldungen in den devtools geworfen. Da ich leider zwischendurch ausgeloggt wurde ist die Fehlermeldung verloren. Die Meldung war irgendwas mit dem unerwarteten Zeichen "<" in (index):1, aber frag mich nicht, wie genau die Formulierung war. Jedenfalls ist die Sache nicht ohne weiteres reproduzierbar, selbst wenn ich gleichzeitig weitere Benutzergruppen mit dem DS erstelle...
So weit so gut von mir, ich stehe für weitere Tests gerne zur Verfügung ;)
Grüße,
RIDER
--
Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter: # Facebook # Twitter # Steam # YouTube # Self-Wiki # ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[-
Danke!
[Nintendo 3DS]
Interessant für mich ist, dass das Benutzer anlegen nicht funktioniert hat (nicht unbedingt verwunderlich, wenns XHR-Probleme gibt), das Gruppe anlegen aber wohl schon (Ich habe das nochmal getestet, es funktioniert tatsächlich.
Es gibt da tatsächlich einen Unterschied. Bei einem neuen Benutzer wird Name und Passwort übertragen, bei der Gruppe nur der Name... scheinbar steigt da schon aus:
new FormData(formular)
auf dem Nintendo aus, was beim Anlegen einer Gruppe eben nicht ausgeführt wird. XMLHttpRequest indes scheint er zu können. Nur nicht ganz komplett, worauf die Antwort mit der Datei hinweist. Der Browser kann offenbar mit mit dem mimetyp 'text/json; charset=utf-8' nichts anfangen.
[Crome, Windows 7]
2.: Es gibt in den devtools ein Warnung: "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/."
Hatte ich gesehen und die Lösung aber auf Version 2 verschoben. Hintergrund, war, dass die Oberfläche bei asynchronen Requests zunächst den alten Stand wieder anzeigte - was noch viel mehr "detrimental effects to the end user's experience" ist.
Wahrscheinlich muss ich die gesamte Oberfläche von JS "re-painten" lassen und kann nicht mit in HTML vorgefertigten sections arbeiten.
3.: Der "Daten neu laden"-Button hat zwischendurch nicht funktioniert und bei jeder Betätigung Fehlermeldungen in den devtools geworfen. Da ich leider zwischendurch ausgeloggt wurde ist die Fehlermeldung verloren.
Das ist wahrhaftig, etwas was mir Sorge bereitet. Ich werde es mit dem Chrome unter Windows mal durchtesten. Unter Linux passiert das scheinbar nicht. Aber wenn danach die verbleibende Zeit bis zum Zwangs-Logout zurückgesetzt wird hat eigentlich alles funktioniert...
Jörg Reinholz
-
Moin!
3.: Der "Daten neu laden"-Button hat zwischendurch nicht funktioniert und bei jeder Betätigung Fehlermeldungen in den devtools geworfen.
Den konnte ich nicht nachvollziehen, habe aber einen anderen gefunden, bei der Benutzer -> Gruppenzuordnung. Schlicht und einfach eine Zeile zu viel, die stehen blieb, als ich merkte, dass ich mich konzeptionell verrannt hatte.
Kommt heute Nacht ins "build".
Jörg Reinholz
-
-
-
Hallo Jörg,
Wäre nett wenn diejenigen, die seltsame Konfigurationen (z.B, xampp) haben
wenn Du mir verrätst, was Xampp mit seltsamer Konfiguration zu tun haben soll und was Du Dir davon versprichst, kann ich es heute Abend evtl. für Dich testen.
Gruß Dennis
-
Moin!
wenn Du mir verrätst, was Xampp mit seltsamer Konfiguration zu tun haben soll und was Du Dir davon versprichst, kann ich es heute Abend evtl. für Dich testen.
Ich kann nicht auszuschliessen, dass
- das Windows-Dateisystem Ärger macht
- PHP unter Windows sich generell merkwürdig aufführt.
Behoben habe ich:
- Mit einem MAC gab es Ärger, der Safari kam mit der Beschränkung der Cookies nicht klar.
- Es gab ebenso Probleme wenn der Port verbogen war (z.B. http auf 8888)
Jörg Reinholz
-
Hallo Jörg,
wenn Du mir verrätst, was Xampp mit seltsamer Konfiguration zu tun haben soll und was Du Dir davon versprichst, kann ich es heute Abend evtl. für Dich testen.
Ich kann nicht auszuschliessen, dass
- das Windows-Dateisystem Ärger macht
- PHP unter Windows sich generell merkwürdig aufführt.
ok, also interessiert Dich Xampp überhaupt nicht sondern PHP unter Windows!?
Ist "generell merkwürdig" gleich "anders als Du es gerne hättest"?
Zu Deinem zweiten Posting: Sind "skurrile Geräte" solche, die Du nicht verwendest?
Das alles nicht "um Dich von der Seite" anzumachen, ich kenne Deinen Schreibstil ja mittlerweile und nehm's Dir auch nicht übel. Manch anderer aber eventuell nicht und ich glaube, Du würdest Deine Chancen auf Mithilfe drastisch erhöhen, wenn nicht gleich schon Deine Bitte so negativ formuliert wäre.
Das alles hat natürlich nichts mit Deiner fachlichen Kompetenz zu tun und das ich vielen Deiner Kritikpunkte an so manchem Gerät oder System durchaus zustimmen würde.
Gruß Dennis
Ps: Xampp gibt's, wie Du sicher weißt, für mehrere Systeme, unter anderem auch für Linux.
-
Moin!
Ist "generell merkwürdig" gleich "anders als Du es gerne hättest"?
Anders als ich es gewohnt bin.
Zu Deinem zweiten Posting: Sind "skurrile Geräte" solche, die Du nicht verwendest?
Äh. Ja. Aber nicht nur. Android halte ich, wenn ich's recht betrachte, auch für "skurril, suspekt" - ebenso wie Windows in jeder Inkarnation. Was Mobilgeräte betrifft wäre ich eigentlich auf sowas scharf.
Ps: Xampp gibt's, wie Du sicher weißt, für mehrere Systeme, unter anderem auch für Linux.
Xampp für Linux. Weia. Das ist tatsächlich skurril, merkwürdig.
Jörg Reinholz
-
-
Hallo Jörg,
Wäre nett wenn diejenigen, die seltsame Konfigurationen (z.B, xampp) haben, das testen und Fehler melden würden.
hab's Sonntag leider nicht mehr geschafft. Ich hab jetzt mal wieder nen alten Rechner reaktiviert und das in folgenden Varianten getestet:
Betriebssystem:
- Windows 7 SP1 32bit [Windows NT PC 6.1 build 7601 (Windows 7 Home Premium Edition Service Pack 1) i586]
Xampp:
- Version 1.7.7 (PHP 5.3.8) [vermutlich Standard-Konfiguration]
- Version 5.5.24 (PHP 5.5.24) [Standard-Konfiguration]
Browser:
- Chrome 43.0 [Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36]
- Firefox 38.0.5 [Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0]
- Internet Explorer 9.0 [Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)]
- Internet Explorer 11.0 [Mozilla/5.0 (IE 11.0; Windows NT 6.1; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko]
- Opera 12.17 [Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.17]
- Opera 30.0 [Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36 OPR/30.0.1835.59 (Edition Campaign 67)]
- Safari 5.1.7 [Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2]
Hier ein paar Anmerkungen, die Dir (hoffentlich ein bisschen) weiterhelfen (alles hier nicht aufgezählte funktioniert):
** Browser **
Beim Opera 12.17 (zu erwarten) und Firefox 38.0.5 (nicht zu erwarten) kann man sich nicht einloggen (bessere Fehlerbeschreibung nicht vorhanden) und daher konnte ich das auch nicht weiter testen.
Möglicher Grund: Das Formular wird an
/selfhtml_login/%5Cselfhtml_login/login.phpbzw./selfhtml_login/\selfhtml_login/login.phpgesendet.** Zeichenkodierung **
In allen Browsern ist die Zeichenkodierung im Admin-Bereich kaputt.
Beispiele:
- /selfhtml_login/selfAdmin/#menu:
Wählen Sie im Menü (links) aus, was Sie tun wollen. - /selfhtml_login/selfAdmin/#useradd:
Neuen Benutzer hinzufügen: Gültig sind alle Buchstaben [...] - /selfhtml_login/selfAdmin/#showUser:
löschen - usw.
** PHP Notice **
Beim Aufruf von
/selfhtml_login/tests/pics_verwalter/erscheint die Meldung:Notice: Undefined index: REQUEST_SCHEME in \selfhtml_login\sendFile.php on line 7.** Passwörter **
Beim Ändern des Passworts erscheinen die Meldungen
Das Passwort muss mindestens 8 Zeichen lang sein und Buchstaben, Ziffern sowie Sonderzeichen enthalten, es darf nicht mit einem Leerzeichen beginnen oder enden.bzw.Das Passwort genügt den Anforderungen nicht!. Scheinbar müssen Groß- und Kleinbuchstaben sowie Zahlen und "Sonderzeichen" verwendet werden.** Info **
Der Benutzer "denni" ist - entgegen des Startseiten-Texts - nicht gesperrt.
Wie gesagt, ansonsten funktioniert's und ich hoffe, Dir helfen die Anmerkungen etwas. Getestet hab ich das mit den Benutzern foo, bar, adm, test, denni und selbsterstellten Benutzern mit unterschiedlichen Rechten.
Gruß, Dennis
-
Moin!
hab's Sonntag leider nicht mehr geschafft. Ich hab jetzt mal wieder nen alten Rechner reaktiviert und das in folgenden Varianten getestet:
Vielen Dank!
Xampp:
- Version 1.7.7 (PHP 5.3.8) [vermutlich Standard-Konfiguration]
- Version 5.5.24 (PHP 5.5.24) [Standard-Konfiguration]
Hier ein paar Anmerkungen, die Dir (hoffentlich ein bisschen) weiterhelfen (alles hier nicht aufgezählte funktioniert):
Möglicher Grund: Das Formular wird an
/selfhtml_login/%5Cselfhtml_login/login.phpbzw./selfhtml_login/\selfhtml_login/login.phpgesendet.Muhaha. Das sieht nach "kompliziert" aus und erfüllt meine schwärzesten Befürchtungen hinsichtlich XAMPP auf Windows - weil da irgendwoher ein Backslash kommt. Da werde ich wohl doch selbst XAMPP installieren müssen.
- Noch nicht gefixt. Grund: Ich muss nachsehen, was PHP unter Windows mit den magic-constants treibt. Das könnte richtig Aufwand verursachen, weil ich die "oft" verwende.
** Zeichenkodierung **
In allen Browsern ist die Zeichenkodierung im Admin-Bereich kaputt.
Offenbar verwendet XAMPP WINDOWS-1252 oder ISO8859-15 (oder sowas) als Default-Charset.
- Gefixt, charset=utf8 wird jetzt gesendet, kommt ins Build.
** PHP Notice **
Beim Aufruf von
/selfhtml_login/tests/pics_verwalter/erscheint die Meldung:Notice: Undefined index: REQUEST_SCHEME in \selfhtml_login\sendFile.php on line 7.- Gefixt, kommt ins Build.
** Passwörter **
Beim Ändern des Passworts erscheinen die Meldungen
Das Passwort muss mindestens 8 Zeichen lang sein und Buchstaben, Ziffern sowie Sonderzeichen enthalten, es darf nicht mit einem Leerzeichen beginnen oder enden.bzw.Das Passwort genügt den Anforderungen nicht!. Scheinbar müssen Groß- und Kleinbuchstaben sowie Zahlen und "Sonderzeichen" verwendet werden.- Gefixt: Text wie folgt in der Konfiguration angepasst, kommt ins Build.
define ( 'PASSWORD_PATTERN_DESCR','Das Passwort muss mindestens ' . MIN_PASSWORD_LENGTH . ' Zeichen lang sein, muss kleine und große Buchstaben, Ziffern sowie Sonderzeichen (oder Umlaute) enthalten, es darf nicht mit einem Leerzeichen beginnen oder enden.' );** Info **
Der Benutzer "denni" ist - entgegen des Startseiten-Texts - nicht gesperrt.
- Ich werde beim nächsten Build besser darauf achten, dass der "Normzustand" eingehalten wird.
Nochmal: Danke!
Jörg Reinholz
-
Hallo und guten Morgen,
Xampp:
- Version 1.7.7 (PHP 5.3.8) [vermutlich Standard-Konfiguration]
- Version 5.5.24 (PHP 5.5.24) [Standard-Konfiguration]
Hier ein paar Anmerkungen, die Dir (hoffentlich ein bisschen) weiterhelfen (alles hier nicht aufgezählte funktioniert):
Möglicher Grund: Das Formular wird an
/selfhtml_login/%5Cselfhtml_login/login.phpbzw./selfhtml_login/\selfhtml_login/login.phpgesendet.Muhaha. Das sieht nach "kompliziert" aus und erfüllt meine schwärzesten Befürchtungen hinsichtlich XAMPP auf Windows - weil da irgendwoher ein Backslash kommt. Da werde ich wohl doch selbst XAMPP installieren müssen.
** Zeichenkodierung **
In allen Browsern ist die Zeichenkodierung im Admin-Bereich kaputt.
Offenbar verwendet XAMPP WINDOWS-1252 oder ISO8859-15 (oder sowas) als Default-Charset.
- Gefixt, charset=utf8 wird jetzt gesendet, kommt ins Build.
Nur für Zugriffe aufs Filesystem. Sonst verwendet XAMPP die Kodierung, die du vorschreibst.
Das ist aber mMn kein Mangel von Xampp, sondern einer von PHP. Da kann man mWn nicht einstellen, mit welcher Kodierung es auf das Filesystem zugreifen soll. Das ist immer dann lustig, wenn man mittels PHP Files von Windows nach Linux kopiert oder verschiebt.
Hast Du denn den Apachen und PHP auch schon "lose" auf einem Windows installiert? Dann solltest Du es dir auch damit noch angucken.
Grüße
TS-
Moin!
Das ist aber mMn kein Mangel von Xampp, sondern einer von PHP.
Da magst Du sogar Recht haben.
Jörg Reinholz