Beiträge von Arne Drews

    Nur mal so nebenbei, ich tummele mich in unterschiedlichen Foren rum und das hier ist das einzige, das die Avatare nicht angezeigt, weil man aus Unwissenheit den vermeintlich sicheren Weg gehen wollte.


    Wie damals sage ich auch hier: Fehlentscheidung!

    Als Anfänger versteht man seinen Code eigentlich nie. Man will einfach etwas machen und kopiert dann sehr viel.


    Man kann als blutiger Anfänger auch kaum Code verstehen, selbst wenn es einem Schritt für Schritt erklärt. Wenn sie dann am Code ein wenig ändert, versteht man wieder nichts. Find das daher nicht so schlimm, Anfängern zu zeigen wie der fertige Code aussehen muss.

    Deshalb gibt es die neumodische Vorgehensweise mit Namen: "Lernen"!

    Natürlich ist der Anfang schwer, aber egal, ob Anfänger, Fortgeschritten oder Vollprofi, man sollte nie Code verwenden, den man nicht versteht!

    Wenn man ihn nicht versteht, befasst man sich mit der Materie, bis man ihn verstanden hat.

    Und dabei hilft es weniger komplette Codes zur Verfügung zu stellen, als darauf hinzuweisen, was man nachlesen sollte.

    Glückwunsch... näher gehe ich da wohl lieber nicht drauf ein, sonst geht's hier seitenweise weiter. Du weißt, was ich meine. ;)

    Nur als kleine Anmerkung noch: Durch solche Beispiele suggerierst Du manch Mitlesenden, dass das durchaus sinnvolle Anwendungsfälle sind.

    Ist der OnLoad-Handler also automatisch global?

    Nein, ist ein Listener, wie jeder andere auch. Aber mit ein wenig Überlegung kannst Du Dir das selbst erklären.


    Du bindest ein JavaScript, wie dieses ein:

    JavaScript
    1. document.addEventListener('DOMContentLoaded', function() {
    2.     var _foobar = 200;
    3. });
    4. console.log(_foobar);

    Das Ergebnis ist undefined.


    Warum? Weil Du Dich nicht im Scope des Listeners befindest. Die Variable wird zwar strukturell scheinbar zuvor deklariert, aber das greift erst, wenn der Content vollständig geladen ist. Bis dahin ist aber die Konsolenausgabe bereits erzeugt worden, weil die außerhalb des Listeners und i.d.R. vor dem vollständigen Laden des Content aufgerufen wurde.


    Da aber die onload-Events i.d.R. immer genutzt werden, um das Laden des Content abzuwarten, um dann die Scriptwelle zu fahren, wirst Du fast immer im Scope des onload-Scope sein und deshalb ist dann auch die Variable verfügbar. In äußere Methoden musst Du die dann übergeben:

    Wenn Du also wirklich globale Variablen benötigst, solltest Du die auch global deklarieren:

    Das ist aber alles nichts, was Du mit ein bisschen selber testen hättest herausfinden können.

    Ach so, sorry, dann habe ich das falsch gelesen.

    Kann man ja relativ leicht testen:

    Dadurch, dass die Methode im global scope aufgerufen wird, sollte die Variable in der Methode verfügbar sein und 201 ausgeben.

    Ich habs jetzt nicht getestet, aber das würde ich mal behaupten.


    Ach so, auf Deinen Listener bezogen, auch einfach zu testen:

    Sollte bei jedem Trigger um einen erhöht werden.

    var definiert eine Variable zwar global, aber innerhalb eines Listener wird der Scope nicht verlassen. Ein EventHandler wird immer bei einem bestimmten Event getriggert. Bei Ausführung eines solchen EventHandler wird der zuvor definierte Code verarbeitet.


    Der Listener kennt zwar die globalen Variablen von außen, aber der globale Scope kennt die Variablen aus dem Listener nicht.

    HTML
    1. <button id="a">HELP</button><div>Help me!!!</div>
    2. <button id="b">Force Rescue</button>

    Egal, was man klickt, die Variable _foobar kann außerhalb des EventHandler-Code nicht verändert werden!

    Wenn eine Variable mit var in einem EventHandler deklariert wird, wird sie das bei jedem Trigger aufs Neue.

    Bei PHP würde ich jetzt kein 10 Jahre altes Buch nehmen. Auch wenn die meisten Dinge noch funktionieren würden, sind sie noch lange keine BestPractice mehr.

    ;)


    Bei JavaScript von 2018 kannst Du nicht viel falsch machen, wenn es darum geht, JavaScript nativ und grundlegend zu verstehen.

    Wenn es ins Eingemachte geht, kann man über ein weiteres Themen spezifisches Buch nachdenken.

    Ich nutze bisher zum Beispiel auch die smtp.js Bibliothek für den E-Mailversand.

    Ok, habe mir das im Detail nicht angesehen, aber wenn ich das Beispiel auf der Homepage sehe

    , kann ich wieder mal nur hoffen, dass das am Ende nicht den Weg ins öffentliche Netz findet. =O

    Warum will man das?!


    Muss ja jeder selber wissen, ich bin raus...

    :sleeping:

    Wenn ich das Projekt aus den anderen Beiträgen richtig verstanden habe, soll es eine rein JS basierte Lösung sein ( kein Framework oder Library ).

    Wenn Server seitige Datenspeicherung erlaubt wäre, kann man das auch mit bereits verfügbaren Mitteln ( i.d.R. PHP o.ä. ) machen.

    Naja, einen möglichen Lösungsweg habe ich Dir bereits genannt, komplette Lösungen/Scripte poste ich im allgemeinen nicht, das machen andere.

    Meistens dann zwar umständlicher, aber die Erfahrung hat gezeigt, dass dann lieber das genommen wird, was einem fertig zugeworfen wird, anstatt sich damit zu befassen.


    Kurz nochmal zusammengefasst:

    Man legt keine Authentifizierungsdaten in JS ab, da hat jeder mit ein bisschen Browserkenntnis immer Zugriff drauf!

    Alternative: Serverseitig, bspw. PHP evtl. in Verbindung mit SQL, da sind den Möglichkeiten wenig Grenzen gesetzt.

    Selbst dann könntest Du per JS ( XmlHttpRequest ) Deine Anwendung aufbauen, wie in #6 bereits angedeutet.

    E V A - Prinzip


    Eingabe ( Datenbank, Formulareingaben, GET-Parameter, etc. )

    Verarbeitung ( bspw. PHP )

    Ausgabe ( HTML , CSS )

    JavaScript ist ein klein wenig Zwitter zwischen V und A, eigentlich verarbeitet man damit, aber man kann auch ausgeben und da es sich direkt im Browser abspielt, kann man es nicht eindeutig zuweisen.


    Wenn man aber das Grundprinzip E.V.A. verstanden hat, sollte klar sein, wie PHP zu nutzen ist.

    Nun ja wenn die seite privat ist . Aber wenn dir das Thema Sicherheit so gefällt kannste mir ja einen Code dazu schicken?!

    Na bei der Einstellung glaube ich nicht ernsthaft, dass Dich das Thema interessiert.

    Ich kann da nur hoffen, dass das wirklich privat ist und nicht öffentlich im Netz erreichbar sein wird.


    Denn mach halt, wie Du meinst.

    Das ist zu einer Grundsatzdiskussion geworden, die glaube ich keinem etwas bringt.

    Es ging im Grunde nur darum, dass die Aussage, man sollte escape_string Funktionen niemals ( O-Ton: nie mehr ) nutzen, einfach falsch ist.


    Keiner stellt in Frage, dass PreparedStatements i.d.R. die sinnvollere Wahl sind und man dann auf extra escaping verzichten kann, deshalb ist das escaping aber nicht perse überflüssig. Aber genau das wurde den "Anfängern", die hier im Forum lernen von Dir suggeriert.


    Um mehr ging es nicht.

    Aber ich bin keiner, der code kopiert. Ich will (so weit möglich) wissen wie und warum etwas funktioniert.

    Im Grunde schätze ich Dich auch so ein und denke auch, dass Du ausreichend Erfahrungen hast. Umso mehr hat es mich halt gewundert, wie Du reagierst, wenn man versucht darauf hinzuweisen, dass eine Aussage nicht ganz richtig ist.


    Das nur zur Klarstellung, mehr habe ich zu dem Thema jetzt nicht mehr zu sagen.

    ;)

    Dein Auszug aus SO ist willkürlich gewählt, es gibt haufenweise anderer Meinungen.

    Die die Du Dir gezogen hast ist warum die richtige?!


    Mal als Gegenbeispiel: https://stackoverflow.com/ques…mysqli-real-escape-string

    Antwort 1 ( als Antwort akzeptiert! ) sagt genau das, was ich geschrieben habe.

    Warum soll das also Quatsch sein, wenn Deins aus gleicher Quelle richtig sein soll?!


    Sorry, aber das ist viel Quatsch.

    Zu viel, um es hier richtig zu stellen.

    ...oder weil Du es nicht begründen kannst vielleicht?

    Bisher hast Du jedenfalls Deine Meinung noch nicht begründet, sondern nur gesagt, dass andere es nicht verstanden haben oder Quatsch schreiben.