Beiträge von Arne Drews

Das % findest Du eher in SQL, als bei PHP. In PHP wäre für Dein Vorhaben Regular Expressions sinnvoll.

Zitat von CuzImCloud

Session wird abgefragt und Text wird ausgegeben.

Nun ist es ja so das dieser Text jedesmal da steht wenn man die Seite neu aufruft und neu lädt.

Aber doch nur für die Session, also den einen Benutzer bzw. Client. Das ist doch der Sinn von Sessions.

Befolge bitte den Rat von m.scatello

Hat trotzdem nichts mit JavaScript zu tun. Du bindest das Stylesheet nur über JavaScript ein, warum verstehe ich gerade sowieso nicht.

Was sagt denn die Browserkonsole zu dem dynamischen DOM?

Das hat weniger mit JavaScript, als mit grundlegendem Verständnis zu tun.

Dein CSS erhält bereits das Attribut rel="stylesheet", ändere das und gut is, oder wo ist genau das Problem?

Wenn es eine Aufgabe ist, solltest Du es allein lösen können, ich hoffe, hier kommt nicht gleich wieder einer der Dir das fertig postet!

Zeig mal Deine Versuche, dann können wir vielleicht helfen, wie Du es selber lösen kannst.

Die Frage lautet eher: Was rechnet er?

Je nach Nutzen, könnte man es evtl. auch anders lösen?

Zitat von Stef

Ich könnte auch überprüfen ob über den Request Daten vorhanden sind - wenn nein wurde die Datei so aufgerufen und ich kann die Person wieder auf die index.php umleiten?

Halte ich für keine gute Idee. Daten sendest Du per POST oder GET, beide Fälle kann ich simulieren.

Mache ich laufend, wenn ich mir meine Logins automatisiere. Ich speichere keine Daten/Passwörter im Browser, sondern rufe das Formularziel mit den entsprechenden Parametern direkt auf. Die meisten lassen das zu, aber das ist eigentlich genau der Punkt, den Du nicht willst.

Eine Session-Variable ist aus meiner Sicht die sinnvollste Variante.

Zitat von CuzImCloud

Wenn ich den Submit Button drücke, werde ich mittels Window.Location auf die gleiche Seite weitergeleitet um die Änderungen zu aktualisieren.

Klingt sinnlos... Das ist doch das Standardverhalten eines Affenformular. Ausgehend von HTML5 einfach das action-Attribut leer lassen und es wird auf die gleiche Seite geleitet bei einem Submit. Mehr JavaScript als nötig macht es nicht besser.

Zitat von CuzImCloud

Hat jemand eine Idee? Bin ich gerade definitiv zu blöd dafür.

Ich tendiere zu Punkt 2 von m.scatello

Zitat von dsaZeus

Das mit einem Login mit Password ist so eine Sache ich weiß ganz genau das sie das Password wieder vergessen usw. und dann wieder nichts eintragen.

Das kann aber unmöglich ein Contra gegen einen sauberen Login sein?!

Der Login ist die beste Lösung für Dein Problem, daran solltest Du festhalten. Alles andere führt nur dazu, dass versehentlich oder bewußt falsche Daten angezeigt werden könnten.

Dir geht es doch darum, dass man die kontaktformular.php nicht direkt aufrufen kann, oder habe ich Dich falsch verstanden?

Wenn ich es richtig verstanden habe, ist das ein Weg, der funktioniert.

Die entsprechende Session-Variable muss ja auch nicht in der index.php direkt gesetzt werden, sondern erst, wenn das Formular aufgerufen wird.

Und wenn Du dann in der kontaktformular.php nach Verarbeitung der Daten die Session-Variable wieder entfernst, ist doch alles gut.

Wo ist denn genau das Verständnisproblem?

Beispiel:

Da es ziemlich viele Möglichkeiten gibt, wie so eine Website aufgebaut sein kann, versuche das mal nur schematisch darzustellen.

session_start();

/*
    ... some actions
*/


// $requestedContent : called uri, here 'mein-formular' e.g.
$_SESSION['is_valid_form_request'] = ( $requestedContent == 'mein-formular' );

Damit ist die Variable in diesem Falle zwar auf allen Seiten gesetzt, aber nur auf der Formular-Seite true!

Für Deine Struktur musst Du die Bedingung natürlich entsprechend anpassen.

Aber die Abfrage in der kontaktformular.php sieht nun relativ simpel aus:

if ( !$_SESSION['is_valid_form_request'] ) {

    header ( 'location: https://www.example.com' );
    exit;

}


$_SESSION['is_valid_form_request'] = false;


/*
    ... your actions by valid request
*/

Zitat von Arne Drews

API Calls per JavaScript, wo die API Credentials einsehbar sind ( wenn vielleicht nicht direkt, aber doch relativ problemlos )?

Das ist hoffentlich nur eine Übung und geht nicht online...

API Calls per JavaScript, wo die API Credentials einsehbar sind ( wenn vielleicht nicht direkt, aber doch relativ problemlos )?

Das ist hoffentlich nur eine Übung und geht nicht online...

Nö, viel zu kompliziert.

Ich öffne einfach eine Session und hinterlege einen Hashwert/Token, kann auch ein ordinärer bool sein, bspw.:

session_start();
$_SESSION['is_valid_request'] = true;

Wenn Du mit dem XmlHttpRequest auf die Server-Datei gehst, musst Du ja nur prüfen, ob die Session Variable vorhanden ist:

session_start();

if ( !isset($_SESSION['is_valid_request']) || !$_SESSION['is_valid_request'] )
    exit;

Bei einem Direktaufruf der Serverdatei ist diese Variable nicht vorhanden, da keine Session existiert. Dann springt er raus oder Du leitest auf Deine root-index um.

Du kannst wenn Du willst auch noch den Token prüfen, wenn Du bspw. einen Hash verwendest, halte ich dafür aber nicht für notwendig.

Zitat von Sempervivum

Einfach das PHP-Skript außerhalb des application-Ordners legen?

Was soll das bringen? Er möchte das PHP-Script per XmlHttpRequest aufrufen, d.h., jeder der in der Lage ist in den Quelltext zu schauen, wird das Zielscript sehen und direkt aufrufen können, vollkommen egal, wo es liegt.

Zitat von m.scatello

Lege einfach eine leere index.html in den Ordner, dann kann keiner mehr was sehen, es sei denn, er kennt den genauen Dateinamen.

Genau den kennt man ja, wenn man in den Browserquelltext schaut

Stef: In so einem Fall arbeite ich mit Sessions, die sind auch aus einem XmlHttpRequest gültig. Einfach in die Session einen Token setzen und im PHP-Script verifizieren. So kannst Du auf einfache Weise feststellen, ob es ein gültiger Aufruf ist oder nicht.

Zitat von MarcelDE

und ich meine wenn ich jetzt in im head den link auf v1.1 ändern muss, dann muss ich es ja auch allen 30 html seiten machen, wenn man soviel hat ist nur ein beispiel!

Deswegen schrieb ich ja: Clever aufbauen die Website. Nur HTML und CSS ist halt ausreichend für Layout und Design, aber Server seitig sollte man schon dynamischen Content erstellen, dann hast Du einen Header(!), den Du immer einbindest. Daraus folgt: Du brauchst die Angabe nur einmal ändern, fertig!

Mit HTML und CSS allein kommst Du halt nicht weiter.

Du kannst dem Browser auf die Art nicht mitteilen, dass er die Seite nicht aus dem Cache laden soll.

Der Verzeichnisschutz der .htaccess verhält sich erstmal rekursiv.

Theroetisch kannst Du mit einer .htaccess im Unterverzeichnis, das nicht geschützt werden braucht mit Satisfy Any den Schutz für das Verzeichnis aufheben. Ich meine, das verhält sich auch rekursiv, bin mir aber grad nicht sicher.

Aber im Endeffekt, ist das nur mal so in den Raum geworfen, weil ich irgendwie noch nicht ganz verstanden habe, um welche Szenarien es Dir wirklich geht.

PHPMailer 6 - Einbinden ohne Composer

PHPMailer 6 - PreComposed Package ( Das Windows Bordmittel-ZIP scheint damit Probleme zu haben, am besten WinRAR, WinZIP, 7ZIP, o.ä. verwenden )

Man kann den Cache des lokalen Client nicht löschen, aber ihn zwingen, die Seite nicht aus dem Cache zu holen.

Das geht aber mit reinem HTML nicht sehr clever, dazu muss man Header Informationen mitsenden, das geht nur über eine Scriptsprache, wie PHP.

Es gibt aber eine Möglichkeit, das CSS zu versionieren:

<link rel="sytlesheet" href="style.css?v1.0">

<link rel="sytlesheet" href="style.css?v1.1">

Dann ist es für den Browser eine neue Datei, die er nicht im Cache hat.

Nicht sehr schick, funktioniert aber.

Zitat von MarcelDE

und wenn man 30 HTML seiten hat müsste man das jedesmal in 30 dateien ändern

Wenn Du beim Cache clever sein willst, solltest Du beim Aufbau Deiner Website damit anfangen, dann brauchst Du das nur in einer einzigen Datei genau einmal ändern.

Zitat von slapwinston

nur das hinzufügen funktioniert nicht da ich nicht weiß wie ich das machen soll.

Zitat von slapwinston

Registrierung Login usw hab ich alles schon fertig. Mir fehlt nur diese eine Sache.

Ganz ehrlich, ich will keinen entmutigen. Ganz im Gegenteil, ich finde es klasse, wenn man sich an sowas rantraut.

Dass das eine Hausnummer selbst für erfahrene Entwickler ist, wurde ja bereits angedeutet.

Was mir eher Sorgen macht , ist die Qualität der Dinge, die Du bereits umgesetzt hast ( Registrierung, Login, usw. ).

Wenn Du aber beim Zufügen in den Warenkorb an Deine Grenzen stößt, wirft das doch einige Fragen auf...

Zitat von basti1012

Dafür habe ich dir einen Daumen hoch gegeben, weil nicht jeder hat es verstanden

Deinen Beitrag habe ich nicht verstanden... Warum soll das nicht jeder verstanden haben?