Du solltest Dich mit den Dev-Tools Deines Browsers bekannt machen. Gerade wenn du mit AJAX-Requests programmieren willst, ist das ensentiell.
Ich weiss nicht was du für einen Browser verwendest aber unter Netzwerk oder Network sieht man das recht schnell.
Hast du die Punkte in meinem Beitrag behoben? Vor allem den Zweiten?
In den Entwicklertools siehst du was Dein Request zurückgibt. Wenn der Status nicht 200 ist springt er nicht in den Success-Teil.
Hast du mal in die Konsole der Entwicklertools geschaut ob ein JavaScript-Fehler vorliegt?
Hast du geprüft ob der Click-Handler funktioniert (z.b. ein einfaches Alert)?
Hast du in den Entwicklertools geschaut ob ein Request abgeschickt wird?
Hast du im PHP-Script mit einer Debugausgabe geschaut ob die Werte ankommen?
Hast du in den PHP-Errorlog geschaut?
Was mir auffällt:
- Das <form>-Element ist an sich unnötig.
- Dein <button> braucht ein type="button". Default ist submit, was die Seite gleich mal abschickt.
- Der Click-Handler für den Button muss nicht in die document.ready-Funktion.
- Im PHP-Teil ist das umkopieren von $_POST in eine Variable absolut unnötig. POST ist superglobal, du kannst das im ganzen Script benutzen.
Dann versuchst du das über Dein custom-css zu überschreiben.
.ui-state-focus {
border: none !important;
}Schon mal in den Dev-Tools nachgeschaut woher denn dieser Rahmen kommt?
Das ist natürlich ein sehr, sehr theoretisches Problem. 
So in die Richung ja, auch wenn ein Cookie natürlich auch auf dem Client gespeichert wird.
Stateless Session nennt man das. Wenn du Seiten per PHP renderst und dort eine Loginprüfung hast machen JWT keinen Sinn.
Weshalb willst du denn keine Session basierte Authentifizierung, wenn ich fragen darf?
Die Library generiert nur Token (und holt die Daten wieder raus), das Abspeichern und das anschliessende Lesen musst du selbst machen. Z.b. in der Session. Dann brauchst du aber auch kein JWT, in die Session kannst du auch eine Benutzer-ID und andere Informationen speichern.
JWT benutze ich z.b. wenn Frontend/Backend getrennt ist. Nach einem Login schickt der Server den JWT zurück an mein (z.b. Angular)Applikation in welcher ich den JWT im Browser abspeichere, z.b. in der LocalStorage und dann mit jedem Request an den Server schicken, der mich dann so authentifiziert.
Das Script ist nur Frontend, gespeichert wird da nix. Geht mit JavaScript auch nicht.
Meistens ist der z-index dafür verantwortlich was vor was steht (https://www.w3schools.com/cssref/pr_pos_z-index.asp).
Evtl. kannst du den manuell manipulieren in diesem speziellen Fall. Aber ohne die Seite zu sehen ist das schwer zu sagen.
Zusammenbasteln sollte man in dem Zusammenhang eh nie was, man sollte schon wissen was man tut. Oder es jemanden machen lassen, der weiss was er tut.
Die Konzepte zum Thema Passwortsicherheit machen schon Sinn. Da haben sich intelligente Leute Gedanken gemacht. Wenn dann Dein FTP-Passwort 1234 lautet bist du natürlich selbst Schuld.
Zitat
Durch Passwörter geschützte Seiten sind, oftmals, viel gefährlicher als Seiten ohne Passwörter.
Diese Aussage ist natürlich sehr grober Unfug.
Ich hoff irgendwann kommt die Zeit wo sich die Browser weigern so etwas darzustellen.
An der mail()-Funktion ist per se nichts falsch. Nur sollte man, um auch garantieren zu können, dass ein Mail ankommt, dieses korrekt versenden, d.h. mit den korrekten Headern, etc. Wenn du fähig bist Dich durch die ganzen RFC's durchzuwühlen kannst du gerne mit mail() verschicken. Ansonsten würd ich einfach zu einem fertigen Mailer greifen, da hat einer schon die Arbeit für Dich getan und du bist auf der sicheren Seite. Wenn man ein Mail einfach so mit mail() verschickt, wie das viele Tutorials und so tun, ist es durchaus möglich, dass es nicht ankommt. Oder im SPAM-Ordner verschwindet.
Diese Lösung ist in der Tat eher bescheiden ...
Bei mir läuft:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ $1.html [L,QSA]Bei der Fehlersuche würde es allerdings helfen wenn beschrieben würde, was nicht geht. Allerdings ist der Thread jetzt doch auch schon ein Zeitchen online un der TE hat entweder aufgegeben oder eine Lösung gefunden.
$("[name='checkbox1']").bootstrapSwitch({Du willst eine checkbox mit dem attribut name='checkbox1' umwandeln. So eine Checkbox hast du aber gar nicht. D.h. du musst Deiner Checkbox diesen Namen geben.
Ich hab für den exakt selben Anwendungsfall eine PWA im Einsatz, mit Angular geschrieben, dazu ein PHP-Backend. Wird eigentlich sehr gut angenommen und läuft halt fast überall problemlos.
Edit: Der ganz grosse Vorteil bei PWAs gegenüber nativen Apps ist das Updaten, welches viel einfacher ist.
Korrekt war es auch davor nicht. Und alles vor PHP7 ist eh nicht mehr unterstützt, von dem her ist das eh irrelevant.
Würdest du Dir etwas Mühe geben beim Programmieren, z.b. auch sprechende Variablennamen verwenden, so das man weiss was gemeint ist, wäre Dir dieser Fehler erst gar nicht passiert.
Um zu helfen muss man Code lesen und verstehen können. So wie du ihn gepostet hast ist das nicht machbar.