Ankündigung

Einklappen
Keine Ankündigung bisher.

Formularverarbeitung, Sicherheit

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Formularverarbeitung, Sicherheit

    Diskussionsbeitrag zum Wiki Eintrag: Formularverarbeitung, Sicherheit.

    Die Diskussionsplattform des PHP.de Wiki wurde ins Forum integriert. Durch Klicken des Buttons "Antwort" kannst du an diesem Thema teilnehmen.
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --


  • #2
    Ich erlaube mir mal, Artikel in die Wahrnehmung von Co-Autoren zu pushen. Kritik willkommen.
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Einige hauptsächlich stilistische Anmerkungen (subjektiv gefärbt ):
      • im Fließtext Abkürzungen nach Möglichkeit ausschreiben ("bspw.")
      • weniger häufig Wörter wie "auch" verwenden (gerade am Satzanfang)
      • Überschriften nicht klein beginnen ("fehlende Elemente")
      • Wörter wie "Browserback" sind etwas seltsam
      • Kleinkram: etliche Tippfehler, fehlende Auslassungsstriche, ...


      Insgesamt liest sich der Artikel primär informativ auf theoretischer Ebene. Von praktischen Beispielen wird bis auf wenige Ausnahmen (Hinweis auf Funktionen wie isset()) abgesehen. Denke, es geht darum, einen Überblick zu schaffen und gegebenenfalls auf spezielle Artikel zu linken?

      Teilweise würde ich anders gliedern. Die Unterabschnitte "Submit-Buttons" und "Image-Buttons" gehören für mich in einen Abschnitt "Abweichendes Browserverhalten" oder "Browserunterschiede". "Register Globals" wäre vielleicht was für "Servereinstellungen", falls sich da weitere Beispiele finden lassen (XSS? Angriffe über Charset-Unterschiede?). Okay, die Einteilung ist wohl nicht immer trennscharf. Eventuell wäre eine Unterteilung in Client-, Server-, HTTP-, PHP-Aspekte denkbar? Vielleicht wäre das aber schon zu kleinschrittig.

      Wenn du nichts dagegen einzuwenden hast, würde ich mich heute Abend so ab 23 Uhr an behutsamen Änderungen versuchen. Kann im Zweifel ja zurückgesetzt werden.

      Offtopic:

      Ich habe mir ehrlichgesagt noch immer keinen Überblick verschafft, wie ihr genau im Wiki arbeitet. Da ich auch noch auf phpforum.de aktiv bin und die eben auch ein Wiki haben, sehe ich zudem wechselseitig sofort Redundanzen, was in der Sache irgendwie nicht so schön ist. Gibt's irgendwo 'nen allgemeinen Diskussionsthread zum Wiki? (Sorry, gerade etwas suchfaul, bin auf dem Sprung. )

      Kommentar


      • #4
        Kein Problem, tu dir keinen Zwang an.
        Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

        Kommentar


        • #5
          Danke, @ mermshaus.

          Einige hauptsächlich stilistische Anmerkungen (subjektiv gefärbt ):

          * im Fließtext Abkürzungen nach Möglichkeit ausschreiben ("bspw.")
          * weniger häufig Wörter wie "auch" verwenden (gerade am Satzanfang)
          Bin leider der Floskelkönig. Bemühe mich schon immer, sowas zu vermeiden. Konkrete Satzvorschläge wären toll. Ich versuche eigentlich, im Wiki eine Ursache-Folge-Argumentation aufzubauen.
          * Überschriften nicht klein beginnen ("fehlende Elemente")
          Werde ich ändern
          * Wörter wie "Browserback" sind etwas seltsam
          Stimmt. Vorschlag? Eigentlich würde ich Browser-Back schreiben.
          * Kleinkram: etliche Tippfehler, fehlende Auslassungsstriche, ...
          Möglich Ist ja die erste Version.


          Insgesamt liest sich der Artikel primär informativ auf theoretischer Ebene. Von praktischen Beispielen wird bis auf wenige Ausnahmen (Hinweis auf Funktionen wie isset()) abgesehen. Denke, es geht darum, einen Überblick zu schaffen und gegebenenfalls auf spezielle Artikel zu linken?
          Ja, erstens das, zweitens merke ich immer wieder, dass zuviel Codebeispiele und God-Artikel im Wiki nicht funktionieren. Als Vergleich - habe ich gerade geschrieben - ein Artikel eines sehr speziellen Themas: Formularverarbeitung, Textfelder - PHP.de Wiki. Vorher hatte ich einen Gesamtartikel für Formularverarbeitung geplant, den ich selbst nicht lesen mochte, weil man da vom Hundersten ins Tausendste kommt und alles durch die diversen Codebeispiele - meistens ja gleich 2 bis drei (HTML, PHP, Dump) - kaum noch lesbar ist.

          Teilweise würde ich anders gliedern. Die Unterabschnitte "Submit-Buttons" und "Image-Buttons" gehören für mich in einen Abschnitt "Abweichendes Browserverhalten" oder "Browserunterschiede".
          Das würde IMHO dann aber nicht in dieses Lemma gehören. Mein Ansatz war, zu zeigen, dass Sicherheit nicht immer „Angriff“ bedeutet, sondern dass auch anderweitig problematische Situationen entstehen können. Die aber trotzdem zu berücksichtigen sind.
          Das Verhalten für Enter habe ich ja woanders nochmal ausgewalzt und konkret beschrieben. Ob es unter diesem Lemma bleicht (oder besser bei Formulare allgemein) weiß ich noch nicht.

          "Register Globals" wäre vielleicht was für "Servereinstellungen", falls sich da weitere Beispiele finden lassen (XSS? Angriffe über Charset-Unterschiede?). Okay, die Einteilung ist wohl nicht immer trennscharf.
          Naja, wir haben ja einen Hauptartikel. Ohne diesen Abschnitt wird die Relevanz von „unbekannte Elemente“ nicht wirklich klar. Denn RG ist ja das Wirkprinzip, das in diesem Fall zuschlägt. Ansonsten wird sehr schwer zu erklären, warum jetzt zusätzliche Eingaben gefáhrlich sind.
          Ähnlich verhält es sich mir fehlenden Angaben. Würde man das ausweiten wollen, müsste man dort anreißen, was eine Notice ist o.ä.

          Grundsätzlich halte ich es trotzdem für sinnvoll, das Thema zumindest im gegebenen Kontext immer anzureißen. Ähnlich tue ich es in Einzelartikeln (siehe Link oben) auch mit Themen wie XSS. Im Zweifel ist mir wichtiger, dass Leute nicht blind etwas aus dem Artikel kopieren und dabei unter XSS micht mehr weitergelesen haben. Immer vollständige Codebeispiele unter allen Aspekten machen auf der anderen Seite IMHO auch nicht immer Sinn, weil darunter das Lehrprinzip deutlich leidet.

          Eventuell wäre eine Unterteilung in Client-, Server-, HTTP-, PHP-Aspekte denkbar? Vielleicht wäre das aber schon zu kleinschrittig.
          Halte ich für nicht machbar. Klappt ja selbst hier im Forum nicht. Themen sind halt übergreifend.

          Wenn du nichts dagegen einzuwenden hast, würde ich mich heute Abend so ab 23 Uhr an behutsamen Änderungen versuchen. Kann im Zweifel ja zurückgesetzt werden.
          Versuch Dein Glück. Bist Du schon Wikiautor?


          Ich habe mir ehrlichgesagt noch immer keinen Überblick verschafft, wie ihr genau im Wiki arbeitet. Da ich auch noch auf phpforum.de aktiv bin und die eben auch ein Wiki haben, sehe ich zudem wechselseitig sofort Redundanzen, was in der Sache irgendwie nicht so schön ist. Gibt's irgendwo 'nen allgemeinen Diskussionsthread zum Wiki? (Sorry, gerade etwas suchfaul, bin auf dem Sprung. )
          Hatte ich mal angefangen (Namespace Autoren:). Da wir aber nur eine Handvoll Autoren sind, hats bisher auch so gut geklappt. Für das Thema Formularverarbeitung habe ich so eine kleine eigene Vorstellung vom Gesamtkomplex, der sich vielleicht schon in den Lemmas abzeichnet.

          Grob:
          Forms allgemein - Wozu, Übersicht über Elemente und Datentypen
          Forms, jeweilige Elemente - Verarbeitung und Vorbelegung, Spezialitäten wie bei Checkboxes
          Forms, Komplettbeispiel mit
          - Code
          - Screenshot Browserdarstellung
          - Listing eines entstehenden Requeststreams
          - Affenformular - Prinzip, Prozess, Einzelbeschreibungen entschlacken/raus
          --

          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


          --

          Kommentar


          • #6
            Änderungen gefallen mir gut.
            --

            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


            --

            Kommentar

            Lädt...
            X