nicht angemeldet
Auge
Der Martin
Der Martin
Detlef G.
Der Martin
Der Martin
Auge
Der Martin
Auge
Hi,
gibts ne Möglichkeit, die Veränderung eines input-fields zu verhindern und den Inhalt dennoch per POST weiterzugeben (also ohne zusätzliche hidden-fields)??
Grüße, Lothar
gibts ne Möglichkeit, die Veränderung eines input-fields zu verhindern
Nein...
aber es gibt:
und den Inhalt dennoch per POST weiterzugeben (also ohne zusätzliche hidden-fields)??
readonly
Ob ein Feld dennoch geändert/gehackt wurde, hast du auf dem Server zu überprüfen.
mfg Beat
readonly
Danke.
Ich dachte, readonly würde genauso wie disabled behandelt.
Ob ein Feld dennoch geändert/gehackt wurde, hast du auf dem Server zu überprüfen.
Sicher. Ist bei diesem Script aber nicht nötig. Es soll nur keiner versehentlich das input-feld ändern.
Grüße, Lothar
Hallo
Ob ein Feld dennoch geändert/gehackt wurde, hast du auf dem Server zu überprüfen.
Sicher. Ist bei diesem Script aber nicht nötig. Es soll nur keiner versehentlich das input-feld ändern.
Wenn der Inhalt partout nicht geändert werden darf, muss es dann überhaupt ein Eingabefeld sein, in dem der Inhalt steht?
Tschö, Auge
Wenn der Inhalt partout nicht geändert werden darf, muss es dann überhaupt ein Eingabefeld sein, in dem der Inhalt steht?
Nein, muss nicht. Aber dann müsste ich die zu transportierenden Daten per hidden input transportieren und auch die serverseitige Programmierung passt dann nicht mehr... ;-)
Nächste Frage:
Wie mache ich Checkbox und Radiobutton unveränderbar und liefere dioe Werte dennoch beim Server ab (ohne zusätzliche hidden input felder)??
Grüße, Lothar
Nächste Frage:
Wie mache ich Checkbox und Radiobutton unveränderbar und liefere dioe Werte dennoch beim Server ab (ohne zusätzliche hidden input felder)??
Und was ist der Sinn einer Selektion, die nicht verändert werden kann?
Gib den aktuell selektierten Eintrag als input type=text readonly aus.
mfg Beat
Und was ist der Sinn einer Selektion, die nicht verändert werden kann?
Gib den aktuell selektierten Eintrag als input type=text readonly aus.mfg Beat
Aber das ist doch nicht dasselbe!
Stell Dir mal vor, dass ich ein und dasselbe Formular einmal als readonly und einmal als read/write darstellen will, damit der User immer DASSELBE sieht, egal zu welchem Zweck er das Formular öffnet.
Nur möchte ich, wenn er es bewußt nur zum lesen öffnet oder mit einem Account, der ein editieren nicht erlaubt, dass er dennoch immer DASSELBE Forumlar wiedererkennt!
Nur soll er eben nweder bewußt, noch versehentlich Änderungen in der "nur Ansicht"-Version vornehmen können.
Für mich ist das ein echter Bug in HTML, das das nicht möglich ist und ich über den Workarround gehen muß (und werde!), dass ich einfach den Submit-Button weglasse...
Nichts gegen Dich. Aber einfach nachzuplappern, was einem vorgegeben wird und was man auf jeder 2. Seite zu lesen bekommt (Welchen Zweck soll eine nicht veränderbare Selektion haben?), ist eher schwach...
Mir fallen neben den oben erwähnten auch weitere ein.
Z.B., dass ich auch in der serverseitigen Auswertung der Formulardaten NICHTS mehr ändern muss. Bei Deinem Vorschlag "input type=text readonly" stimmt auch der auswertende Teil des Formulares nicht mehr.
Grüße, Lothar
Hi,
Für mich ist das ein echter Bug in HTML, das das nicht möglich ist und ich über den Workarround gehen muß (und werde!), dass ich einfach den Submit-Button weglasse...
Dass das ein Formular nicht unabsendbar macht, ist dir bewusst?
Z.B., dass ich auch in der serverseitigen Auswertung der Formulardaten NICHTS mehr ändern muss. Bei Deinem Vorschlag "input type=text readonly" stimmt auch der auswertende Teil des Formulares nicht mehr.
Wenn du dich darauf verlässt, dass Formulardaten nicht verändert wurden, nur weil du das gerne so hättest - dann stimmt deine serverseitige Verarbeitung nicht.
MfG ChrisB
Dass das ein Formular nicht unabsendbar macht, ist dir bewusst?
Selbstverständlich. Die Menschen, die mein Formular benutzen, arbeiten nicht gegen mich, sondern mit mir zusammen!
Wenn du dich darauf verlässt, dass Formulardaten nicht verändert wurden, nur weil du das gerne so hättest - dann stimmt deine serverseitige Verarbeitung nicht.
s.o.
Grüße, Lothar
Hi,
Dass das ein Formular nicht unabsendbar macht, ist dir bewusst?
Selbstverständlich. Die Menschen, die mein Formular benutzen, arbeiten nicht gegen mich, sondern mit mir zusammen!
Na dann existiert ja eigentlich gar kein Problem.
Du sagst, "nichts verändern, ihr Schäfchen", und die Schäfchen folgen ... alles wunderbar.
Wenn du dich darauf verlässt, dass Formulardaten nicht verändert wurden, nur weil du das gerne so hättest - dann stimmt deine serverseitige Verarbeitung nicht.
s.o.
Trotzdem.
MfG ChrisB
Selbstverständlich. Die Menschen, die mein Formular benutzen, arbeiten nicht gegen mich, sondern mit mir zusammen!
Na dann existiert ja eigentlich gar kein Problem.
Du sagst, "nichts verändern, ihr Schäfchen", und die Schäfchen folgen ... alles wunderbar.
Es sind numal leider nicht alle Menschen so fehlerfrei und perfekt, wie Du, ChrisB. :-)
Ab und an habe ich bei Deinen Antworten den Eindruck, dass Du hier den Cheatah-Klon versuchst, zu geben... Nur... der hat echt Plan und gibt immer wieder hilfreiche Hinweise... :-)
Grüße, Lothar
Hi,
Nur... der hat echt Plan und gibt immer wieder hilfreiche Hinweise... :-)
Die hast du hier auch bekommen - was du draus machst, liegt an dir.
MfG ChrisB
Die hast du hier auch bekommen - was du draus machst, liegt an dir.
MfG ChrisB
Aber nicht von Klon-Cheat, ääh, ich meinte: Von ChrisB ;-)
Schlaf gut.. :-)
Hi,
Für mich ist das ein echter Bug in HTML, das das nicht möglich ist und ich über den Workarround gehen muß (und werde!), dass ich einfach den Submit-Button weglasse...
Dass das ein Formular nicht unabsendbar macht, ist dir bewusst?
Ich sag ja: Bug ;-)
hi,
Stell Dir mal vor, dass ich ein und dasselbe Formular einmal als readonly und einmal als read/write darstellen will, damit der User immer DASSELBE sieht, egal zu welchem Zweck er das Formular öffnet.
<start modul="Fantasie"/>
Nur möchte ich, wenn er es bewußt nur zum lesen öffnet oder mit einem Account, der ein editieren nicht erlaubt, dass er dennoch immer DASSELBE Forumlar wiedererkennt!
Das kannst du mit HTML/XHTML + CSS.
Nur soll er eben nweder bewußt, noch versehentlich Änderungen in der "nur Ansicht"-Version vornehmen können.
Das wäre unmöglich, wenn du die Inhalte, im Falle, dass sie nur gelesen werden sollen können, in einfachem Markup auslieferst, ohne das ganze unsinnigerweise in ein Formular zu packen.
Für mich ist das ein echter Bug in HTML, das das nicht möglich ist und ich über den Workarround gehen muß (und werde!), dass ich einfach den Submit-Button weglasse...
Das kannst du machen, nur, verlink die Seite, und ich kann dir vorführen, wie ich trotzdem ein Post absetze, egal ob du es willst oder nicht -- und egal, ob du sie auf readonly setzt oder nicht.
Nichts gegen Dich. Aber einfach nachzuplappern, was einem vorgegeben wird und was man auf jeder 2. Seite zu lesen bekommt (Welchen Zweck soll eine nicht veränderbare Selektion haben?), ist eher schwach...
Auf so eine frage wie deine was anderes zu schreiben wäre Schwach.
mfg
Das wäre unmöglich, wenn du die Inhalte, im Falle, dass sie nur gelesen werden sollen können, in einfachem Markup auslieferst, ohne das ganze unsinnigerweise in ein Formular zu packen.
Unsinn. Denn die Leser/Writer des Inhalts der Seite möchten gerne
1 einzige Ansicht
Mal editierbar, mal nicht...
Und nu? ;-)
hi,
Das wäre unmöglich, wenn du die Inhalte, im Falle, dass sie nur gelesen werden sollen können, in einfachem Markup auslieferst, ohne das ganze unsinnigerweise in ein Formular zu packen.
Unsinn. Denn die Leser/Writer des Inhalts der Seite möchten gerne
1 einzige Ansicht
Mal editierbar, mal nicht...
Das per se als Unsinn hinzustellen ist Arm.
Den User interessiert nicht, wie er die Daten vorgesetzt bekommt ...
Und wie schon von mir und nun auch von Beat erwähnt, kannst du mittels CSS es so aussehen lassen, wie ein Formular -- ein Formular ist dafür gemacht, Dateneingaben entgegenzunehmen, nicht um Inhalte anzuzeigen.
Und nu? ;-)
Dein Markup anpassen und entsprechend stylen oder dir noch mehr Argumente einfallen lassen, warum deine Variante Sinn macht, bis du es selber glaubst.
mfg
hi,
Das wäre unmöglich, wenn du die Inhalte, im Falle, dass sie nur gelesen werden sollen können, in einfachem Markup auslieferst, ohne das ganze unsinnigerweise in ein Formular zu packen.
Das per se als Unsinn hinzustellen ist Arm.
Unsinn. Denn die Leser/Writer des Inhalts der Seite möchten gerne
1 einzige Ansicht
Mal editierbar, mal nicht...
Das per se als Unsinn hinzustellen ist Arm.
Meine Rede ;-)
Den User interessiert nicht, wie er die Daten vorgesetzt bekommt ...
Hallo???!!!???
Wer entscheidet das?
DU oder der User?
In meinem Fall hat sich der User das so gewünscht!
Und er würde mich wohl als ziemlich arrogant bezeichnen, wenn ich ihm als Antwort gäbe, das ihn das nicht zu interessieren hat!
Und wie schon von mir und nun auch von Beat erwähnt, kannst du mittels CSS es so aussehen lassen, wie ein Formular -- ein Formular ist dafür gemacht, Dateneingaben entgegenzunehmen, nicht um Inhalte anzuzeigen.
Es ist mir ja inzwischen klar, dass es technisch nicht geht. Aber das ist eben ein BUG. Wäre ein Formular nämlich immer und ausschließlich dazu gedacht, Dateneingaben entgegenbzunehmen, gäbe es Features wie "disabled" und "readonly" ja erst gar nicht!
Und nu? ;-)
Dein Markup anpassen und entsprechend stylen oder dir noch mehr Argumente einfallen lassen, warum deine Variante Sinn macht, bis du es selber glaubst.
...oder bis Menschen wie Du auch in der Lage sind, über den Tellerrand dessen zu schauen, was ihnen einfach so vorgesetzt wird ;-)
Hallo,
Den User interessiert nicht, wie er die Daten vorgesetzt bekommt ...
Hallo???!!!???
Wer entscheidet das?
DU oder der User?
In meinem Fall hat sich der User das so gewünscht!
soso, und *was genau* hat "der User" sich gewünscht? Vermutlich, dass er den Datensatz in einer Weise angezeigt wird, die genau so aussieht wie das Formular, aber keine Änderungen erlaubt. Meinst du wirklich, "der User" interessiert sich dafür, wie das technisch realisiert ist? Für ihn ist das Look&Feel wichtig, nicht der Quellcode dahinter, also würde sicher auch eine mit CSS gut gemachte Imitation eines Formulars genügen.
Und er würde mich wohl als ziemlich arrogant bezeichnen, wenn ich ihm als Antwort gäbe, das ihn das nicht zu interessieren hat!
Das kommt auf die Formulierung der Vorgaben an. Ich informiere meine Kunden zwar gern über technische Interna, wenn sie danach fragen; meistens wollen sie das aber so genau gar nicht wissen oder würden die Einzelheiten auch nicht verstehen. Daher ist es IMHO legitim zu sagen, es gehe den Kunden, geschweige denn den späteren Nutzer, nichts an, wie eine bestimmte Sache *jenseits der vereinbarten Schnittstellen* realisiert ist.
Und wie schon von mir und nun auch von Beat erwähnt, kannst du mittels CSS es so aussehen lassen, wie ein Formular -- ein Formular ist dafür gemacht, Dateneingaben entgegenzunehmen, nicht um Inhalte anzuzeigen.
Es ist mir ja inzwischen klar, dass es technisch nicht geht. Aber das ist eben ein BUG. Wäre ein Formular nämlich immer und ausschließlich dazu gedacht, Dateneingaben entgegenbzunehmen, gäbe es Features wie "disabled" und "readonly" ja erst gar nicht!
So absolut würde ich das nicht sagen. Diese Attribute sind dazu gedacht, einzelne Formularfelder dem Einfluss des Benutzers zu entziehen. Überhaupt verstehe ich dein Problem nicht: Wenn ich ein Formularelement auf disabled setze, dann wird es beim Absenden des Formulars nicht mit übertragen. Na prima! Da hättest du doch schon ein Erkennungsmerkmal: Schreib dein serverseitiges Script, das die Daten entgegennimmt, so um, dass es die Verarbeitung übergeht, wenn die Formulardaten unvollständig sind.
Alternativ: Ein hidden-Feld einsetzen, dessen Inhalt den readonly-Status des gesamten Formulars anzeigt. Oder das action-Attribut des Formulars auf ein entsprechend "abgespecktes" Script zeigen lassen ...
Du hast ja selbst schon gesagt, deine User kooperieren mit dir. Das ist auch gut, denn wenn jemand dein Formular wirklich manipulieren *will*, kann er das immer tun.
So long,
Martin
Hi,
soso, und *was genau* hat "der User" sich gewünscht? Vermutlich, dass er den Datensatz in einer Weise angezeigt wird, die genau so aussieht wie das Formular, aber keine Änderungen erlaubt. Meinst du wirklich, "der User" interessiert sich dafür, wie das technisch realisiert ist? Für ihn ist das Look&Feel wichtig, nicht der Quellcode dahinter, also würde sicher auch eine mit CSS gut gemachte Imitation eines Formulars genügen.
Selbstverständlich. Da hast Du völlig recht.
Und genau hier hätte ich erwartet, dass ich alle Eingabefelder auf "readonly" stellen kann (ähnlich "text" und "textarea") und dafür keinen Workaround auf Backendseite und zudem eine Änderung auf Serverseite benötige. Insofern spreche ich von einem BUG in HTML.
Und er würde mich wohl als ziemlich arrogant bezeichnen, wenn ich ihm als Antwort gäbe, das ihn das nicht zu interessieren hat!
Das kommt auf die Formulierung der Vorgaben an. Ich informiere meine Kunden zwar gern über technische Interna, wenn sie danach fragen; meistens wollen sie das aber so genau gar nicht wissen oder würden die Einzelheiten auch nicht verstehen. Daher ist es IMHO legitim zu sagen, es gehe den Kunden, geschweige denn den späteren Nutzer, nichts an, wie eine bestimmte Sache *jenseits der vereinbarten Schnittstellen* realisiert ist.
So würde je nachdem ein Schuh draus. Davon war aber meinerseits nie die Rede.
Und "je nach dem", weil auch jenseits der vereinbarten Schnittstelle der Kunde ein Recht darauf hat, bestimmte Lösungen zu erhalten. Stichworte: Sicherheit, Performance, usw.
Das hat wenig mit dem Verständniss des Kunden für diese Dinge zu tun.
So absolut würde ich das nicht sagen. Diese Attribute sind dazu gedacht, einzelne Formularfelder dem Einfluss des Benutzers zu entziehen.
Und hier sage ich nochmals:
Es wäre hilfreich, diese Attribute auch anderen Formularfeldern zugute kommen zu lassen. Würde auf Programmiererseite Arbeit ersparen.
Überhaupt verstehe ich dein Problem nicht: Wenn ich ein Formularelement auf disabled setze, dann wird es beim Absenden des Formulars nicht mit übertragen. Na prima! Da hättest du doch schon ein Erkennungsmerkmal: Schreib dein serverseitiges Script, das die Daten entgegennimmt, so um, dass es die Verarbeitung übergeht, wenn die Formulardaten unvollständig sind.
Würde ich machen. Wenns nur darum ginge den eingelesenen Datensatz zu behandeln. Es werden aber die Angaben benötigt, um einen weiteren zu erzeugen.
Sicher, an die Daten komme ich natürlich immer ran. Aber es wird umständlicher, als wenn "disabled" einfach wie readonly behandelt werden würde. Stimmts?
Alternativ: Ein hidden-Feld einsetzen, dessen Inhalt den readonly-Status des gesamten Formulars anzeigt.
s.o.
Oder das action-Attribut des Formulars auf ein entsprechend "abgespecktes" Script zeigen lassen ...
Auch ne gute Idee. Nicht für jetzt und heute, aber überhaupt.
Du hast ja selbst schon gesagt, deine User kooperieren mit dir. Das ist auch gut, denn wenn jemand dein Formular wirklich manipulieren *will*, kann er das immer tun.
So long,
Martin
Sehe ich auch so.
Grüße, Lothar
Mahlzeit Lothar,
Und genau hier hätte ich erwartet, dass ich alle Eingabefelder auf "readonly" stellen kann (ähnlich "text" und "textarea")
<http://de.selfhtml.org/html/referenz/attribute.htm#input@title=Kannst Du doch>.
und dafür keinen Workaround auf Backendseite und zudem eine Änderung auf Serverseite benötige.
Was hat irgendein Skript, dass auf dem Server liegt und Daten per GET oder POST entgegennimmt, mit irgendeinem HTML-Formular zu tun? Richtig: gar nichts.
Insofern spreche ich von einem BUG in HTML.
Es existiert kein entsprechende Bug in HTML. Es existiert lediglich ein Verständnisproblem auf Deiner Seite.
Wenn Änderungen an Daten nicht erfolgen sollen, kommt man nicht darum herum, in dem serverseitigen Skript genau dann, wenn es Daten "von irgendwo da draußen" erhält, abzufragen, ob diese Daten geändert werden dürfen. Sich dabei auf irgendwelche Informationen, die "von irgendwo da draußen" kommen, zu verlassen, ist in höchstem Maße fahrlässig - merke: ALL INPUT IS EVIL!
MfG,
EKKi
Wenn Änderungen an Daten nicht erfolgen sollen, kommt man nicht darum herum, in dem serverseitigen Skript genau dann, wenn es Daten "von irgendwo da draußen" erhält, abzufragen, ob diese Daten geändert werden dürfen. Sich dabei auf irgendwelche Informationen, die "von irgendwo da draußen" kommen, zu verlassen, ist in höchstem Maße fahrlässig - merke: ALL INPUT IS EVIL!
MfG,
EKKi
Hallo EKKi,
Es ist aber doch ein rechtliches Problem. Daten ausspähen, Server hacken, Formulardaten faken, usw. sind strafrechtlich relevante Dinge. Der Kunde muß mit seinen Mitarbeitern vertraglich fixieren, was sie dürfen und was nicht.
Darüber hinaus fixiert unser Rechtssystem, was man darf und was nicht.
Als Programmierer muß (!) ich zwingend die Dinge ausschalten, die versehentlich oder grob fahrlässig vom User falsch gemacht werden können. Aber bin ich auch verpflichtet, die Dinge auszuschalten, die er vorsätzlich und in strafrechtlich relevanter Weise "falsch" macht?
Ist der Hersteller eines Autos in der Pflicht, wenn ein Autofahrer vorsätzlich in eine Menschenmenge fährt?
Interessantes Thema. Bis zu einem gewissen Grad sehe ich mich hier auch durchaus in der Pflicht, aber wo hört Sicherheitsverständnis auf und wo fängt Paranoia an?
Jedenfalls von grob fahrlässig zu sprechen, weil Formulare nahezu immer gefaked werden können, ist weit aus dem Fenster gelehnt.
Grüße, Lothar
Mahlzeit Lothar,
Es ist aber doch ein rechtliches Problem. Daten ausspähen, Server hacken, Formulardaten faken, usw. sind strafrechtlich relevante Dinge. Der Kunde muß mit seinen Mitarbeitern vertraglich fixieren, was sie dürfen und was nicht.
Darüber hinaus fixiert unser Rechtssystem, was man darf und was nicht.
Das mag sein. Andererseits sollte es Deine Pflicht als Programmierer sein, sauberen und sicheren Code abzuliefern, den man überhaupt gar nicht manipulieren *kann*.
Es wäre durchaus denkbar, dass Dir eine eventuelle Mitschuld angelastet wird, wenn ein findiger Mitarbeiter eines Kunden es z.B. geschafft hat, ein von Dir geschaffenes System zu überlisten und z.B. größere Datenbestände zu vernichten. Schließlich kostet so etwas ... und der Kunde wird sicherlich alle Möglichkeiten ausschöpfen, den ihm entstandenen Schaden ansatzweise wieder auszugleichen.
Abgesehen natürlich davon, dass derart "schlampig" programmierte Anwendungen normalerweise *NIEMALS* irgendeine Form von Zertifikat erhalten werden und demzufolge in Unternehmen, die z.B. aus rechnungslegungsrelevanten Gründen nur zertifizierte Software verwenden dürfen, nichts zu suchen hat.
Als Programmierer muß (!) ich zwingend die Dinge ausschalten, die versehentlich oder grob fahrlässig vom User falsch gemacht werden können. Aber bin ich auch verpflichtet, die Dinge auszuschalten, die er vorsätzlich und in strafrechtlich relevanter Weise "falsch" macht?
IMHO ja. Das würde ich als Kunde zumindest erwarten.
Ist der Hersteller eines Autos in der Pflicht, wenn ein Autofahrer vorsätzlich in eine Menschenmenge fährt?
Juchuuuhhh - der erste unpassende Vergleich (klassischerweise mit Autos) in diesem Thread ... mal schauen, wann Godwins Gesetz erfüllt ist.
Interessantes Thema. Bis zu einem gewissen Grad sehe ich mich hier auch durchaus in der Pflicht, aber wo hört Sicherheitsverständnis auf und wo fängt Paranoia an?
Was hat Paranoia mit einer sauberen Anwendung zu tun, die nur vernünftige und korrekte Daten verarbeitet?
Jedenfalls von grob fahrlässig zu sprechen, weil Formulare nahezu immer gefaked werden können, ist weit aus dem Fenster gelehnt.
Nein. Definitiv nicht. Da "Webanwendungen" genau auf diesem Prinzip (es gibt keine dauerhafte Verbindung) basieren, ist es ein absolutes *MUSS*, alle Daten, die zwischen Client und Server hin- und hergeblasen werden, auf Integrität zu prüfen.
Sich darauf zu verlassen, "dass die User schon alles richtig machen (weil sie sich ja sonst strafbar machen)" ist mehr als grob fahrlässig. Anwendungen, die von Programmierern stammen, die derart nachlässig und faul sind, sind nicht einen halben Pfifferling wert und haben dort, wo ich zu entscheiden habe, absolut nichts zu suchen.
MfG,
EKKi
Das mag sein. Andererseits sollte es Deine Pflicht als Programmierer sein, sauberen und sicheren Code abzuliefern, den man überhaupt gar nicht manipulieren *kann*.
Und wenn doch? Dann Arschkarte oder wie?
Jder Code kann gehackt werden, wußtest Du das nicht?
Es wäre durchaus denkbar, dass Dir eine eventuelle Mitschuld angelastet wird, wenn ein findiger Mitarbeiter eines Kunden es z.B. geschafft hat, ein von Dir geschaffenes System zu überlisten und z.B. größere Datenbestände zu vernichten.
In good old G. sicher. Muß ich Dir zustimmen. Aber in einem Rechtsstaat auch?
Abgesehen natürlich davon, dass derart "schlampig" programmierte Anwendungen normalerweise *NIEMALS* irgendeine Form von Zertifikat erhalten werden
Was denn? Kein Jodeldiplom? Kein Gar nix? Oweia... *g*
Juchuuuhhh - der erste unpassende Vergleich (klassischerweise mit Autos) in diesem Thread ... mal schauen, wann Godwins Gesetz erfüllt ist.
Auch wenn ich der Ansicht bin, dass Du das jetzt nur mal loswerden wolltest, weil Du es zuvor irgendwo selber gelesen hast... (und eh ein anderer das vor Dir tut, ne? ;-) )... finde ich den Link klasse. Und gebe der Theorie als solcher recht :-))))
Was hat Paranoia mit einer sauberen Anwendung zu tun, die nur vernünftige und korrekte Daten verarbeitet?
Wie war das? All Input is Evil oder so? DAS ist Paranoia pur ;-)
Sich darauf zu verlassen, "dass die User schon alles richtig machen (weil sie sich ja sonst strafbar machen)" ist mehr als grob fahrlässig.
Du meinst sicher: Sich darauf berufen, dass User nicht straftätig werden...
Ich schließe auch meine Haustüre ab. Aber ich mache nicht noch zusätzlich nen tonnenschweren Stein vor die Türe und installiere 3 Kameras und eine Selbstschussanlage, obwohl das technisch machbar wäre.
Und so wehre ich SQL-Injections ab, habe ein sicheres Login-System, und prüfe auch Formulare uind deren Inhalt. Aber irgendwo muss auch mal Schluss sein. Auch wenn sich, wie ich nun von Dir gelernt habe, hinter jeder Tastatur der Teufel verbirgt. ;-)
Grüße, Lothar
Mahlzeit Lothar,
Das mag sein. Andererseits sollte es Deine Pflicht als Programmierer sein, sauberen und sicheren Code abzuliefern, den man überhaupt gar nicht manipulieren *kann*.
Und wenn doch? Dann Arschkarte oder wie?
Nein. Wenn Du belegen kannst, dass Du z.B. alle üblichen, sich im Rahmen des (finanziell) Vertretbaren befindlichen Sicherheitsvorkehrungen getroffen hast, wieso solltest Du dann die Arschkarte haben?
Dummerweise gehört dazu aber IMHO z.B. auch, prinzipielle Gefahren wie "ich mache von manipulierbaren Benutzereingaben abhängig, ob und wie Daten geändert werden können" abzuwenden. Wenn sich ein Datensatz auf dem Server in einem definierten Zustand des "Nicht-geändert-werden-dürfens" befindet, dann muss vollkommen egal sein, was irgendwelche Benutzer oder Schlitzohren irgendwo eintippen bzw. irgendwie manipulieren ... der Datensatz wird einfach deshalb nicht geändert, weil auf dem Server die Information vorhanden ist, dass er nicht geändert werden darf.
Jder Code kann gehackt werden, wußtest Du das nicht?
Schon. Aber darum geht es gerade nicht. Es geht darum, einfachste und grundlegende Prinzipien der Formularverarbeitung mittels Webtechnologien, die schon vor 15 Jahren galten, zu verstehen und umzusetzen.
Es wäre durchaus denkbar, dass Dir eine eventuelle Mitschuld angelastet wird, wenn ein findiger Mitarbeiter eines Kunden es z.B. geschafft hat, ein von Dir geschaffenes System zu überlisten und z.B. größere Datenbestände zu vernichten.
In good old G. sicher. Muß ich Dir zustimmen. Aber in einem Rechtsstaat auch?
Definiere "Rechtsstaat".
Abgesehen natürlich davon, dass derart "schlampig" programmierte Anwendungen normalerweise *NIEMALS* irgendeine Form von Zertifikat erhalten werden
Was denn? Kein Jodeldiplom? Kein Gar nix? Oweia... *g*
Du magst darüber schmunzeln ... das zeigt mir allerdings auch, dass Du noch nie in einem wirklich "professionellen Umfeld" (und das meine ich jetzt im eigentlich Sinn des Wortes) Software entwickelt hast. Je größer das Unternehmen ist und je direkter die verwendete Software mit rechnungslegungsrelevanten Vorgängen wie z.B. finanzbuchhalterischen Buchungen, desto stärker spielt eine Zertifizierung bzw. die Sicherheit der durch das Programm verarbeiteten Daten sowie der verarbeitenden Vorgänge an sich eine Rolle.
Mir persönlich sind Fälle bekannt, in denen Kapitalgesellschaften das Testat des prüfenden Wirtschaftsprüfers unter dem Jahresabschlusses verweigert bzw. nur mit Einschränkungen gegeben wurde - weil die verwendete Software nicht den Anforderungen der Grundsätzen ordnungsmäßiger DV-gestützter Buchführungssysteme entsprach. Wenn Dir das etwas sagt, weißt Du, dass so etwas einem Unternehmen das Genick brechen kann.
Was hat Paranoia mit einer sauberen Anwendung zu tun, die nur vernünftige und korrekte Daten verarbeitet?
Wie war das? All Input is Evil oder so? DAS ist Paranoia pur ;-)
Nein. Das ist - insbesondere im Fall des Internets - das Mindestmaß an Sorgfalt, das man als Programmierer beachten muss. Ich weiß ja nicht, was Du die letzten Jahre so getan hast, aber die ganz großen (Sicherheits-)Probleme verbreiteter Browser, Systeme und Anwendungen scheinst Du verschlafen zu haben.
Sich darauf zu verlassen, "dass die User schon alles richtig machen (weil sie sich ja sonst strafbar machen)" ist mehr als grob fahrlässig.
Du meinst sicher: Sich darauf berufen, dass User nicht straftätig werden...
Es ist immer besser, seine Sache vernünftig zu machen, als sich darauf zu verlassen, dass andere brav sein werden (weil sie sonst auf die Finger bekommen) ... und anschließend nachträglich in Beweisnot zu geraten. Warum willst Du Dir das Leben unöntig schwer machen?
Ich schließe auch meine Haustüre ab. Aber ich mache nicht noch zusätzlich nen tonnenschweren Stein vor die Türe und installiere 3 Kameras und eine Selbstschussanlage, obwohl das technisch machbar wäre.
Uiii, schon wieder ein unpassende Vergleich ...
Du überprüfst doch aber z.B. Deine Unterlagen, wenn Dir jemand schreibt, er hätte noch 5.000 € von Dir zu bekommen und Du möchtest das doch bitte sofort daundda hin überweisen, oder? Siehst Du - von nichts anderem spreche ich: die Informationen, die von außen kommen, verifizieren ... und sich nicht blind auf alles verlassen, was in den Briefkasten (bzw. das Server-Skript) reintrudelt.
Und so wehre ich SQL-Injections ab, habe ein sicheres Login-System, und prüfe auch Formulare uind deren Inhalt.
Genau darum geht es doch. Du überprüfst also die Werte, die ein (angebliches) Formular an Deinen Server schickt? Prima - davon rede ich die ganze Zeit.
Aber irgendwo muss auch mal Schluss sein. Auch wenn sich, wie ich nun von Dir gelernt habe, hinter jeder Tastatur der Teufel verbirgt. ;-)
Wann habe ich das behauptet?
MfG,
EKKi
Hi EKKI,
Nein. Wenn Du belegen kannst, dass Du z.B. alle üblichen, sich im Rahmen des (finanziell) Vertretbaren befindlichen Sicherheitsvorkehrungen getroffen hast, wieso solltest Du dann die Arschkarte haben?
Frage ist trotzdem. Wo fängst an und wo hörst auf? Ich hab Dir ja schon beschrieben, was ich absichere. Aber wer weiß schon, ob das ausreicht oder nicht?
Dummerweise gehört dazu aber IMHO z.B. auch, prinzipielle Gefahren wie "ich mache von manipulierbaren Benutzereingaben abhängig, ob und wie Daten geändert werden können" abzuwenden. Wenn sich ein Datensatz auf dem Server in einem definierten Zustand des "Nicht-geändert-werden-dürfens" befindet, dann muss vollkommen egal sein, was irgendwelche Benutzer oder Schlitzohren irgendwo eintippen bzw. irgendwie manipulieren ... der Datensatz wird einfach deshalb nicht geändert, weil auf dem Server die Information vorhanden ist, dass er nicht geändert werden darf.
Nur, darum ging es in diesem Thread nie. Änderung der Daten war ohnehin ausgeschlossen, es ging lediglich darum, dass der User das identische Formular zu sehen bekommt und aus diesem ein weiterer Datensatz generiert wird. Und hierfür hätte ich mir ein "readonly" für einige Formularelemente gewünscht.
Jder Code kann gehackt werden, wußtest Du das nicht?
Schon. Aber darum geht es gerade nicht. Es geht darum, einfachste und grundlegende Prinzipien der Formularverarbeitung mittels Webtechnologien, die schon vor 15 Jahren galten, zu verstehen und umzusetzen.
Nein, genau DARUM geht es gerade nicht. Es geht um die Einstellung zu diesem Thema.
Es wäre durchaus denkbar, dass Dir eine eventuelle Mitschuld angelastet wird, wenn ein findiger Mitarbeiter eines Kunden es z.B. geschafft hat, ein von Dir geschaffenes System zu überlisten und z.B. größere Datenbestände zu vernichten.
Wie krank ist die Denkweise hier?
Es gelingt mir doch in 1000 anderen Bereichen auch, funktionierende Systeme zu zerstören oder "zu überlisten". Und auch da wird nicht zwingend die (Mit)schuld beim Hersteller gesucht.
Mein Problem hierbei ist: Ich setze genau gem. dieser kranken Denkweise um. Aber mir stinkt sie, diese Art zu denken.
In good old G. sicher. Muß ich Dir zustimmen. Aber in einem Rechtsstaat auch?
Definiere "Rechtsstaat".
Definiere Grundgesetz.
Abgesehen natürlich davon, dass derart "schlampig" programmierte Anwendungen normalerweise *NIEMALS* irgendeine Form von Zertifikat erhalten werden
Was denn? Kein Jodeldiplom? Kein Gar nix? Oweia... *g*
Du magst darüber schmunzeln ...
Mir persönlich sind Fälle bekannt, in denen Kapitalgesellschaften das Testat des prüfenden Wirtschaftsprüfers unter dem Jahresabschlusses verweigert bzw. nur mit Einschränkungen gegeben wurde - weil
Mir persönlich sind unzählige Fälle bekannt, wo sich Entscheidungsträger sich hinter irgendwelchen "Vorschriften" verschanzen und diese für ihre Entsheidungen anführen. Diese werden dadurch nicht zwingend richtig.
Nein. Das ist - insbesondere im Fall des Internets - das Mindestmaß an Sorgfalt, das man als Programmierer beachten muss.
Ich mache keine Internetanwendung.
Es ist immer besser, seine Sache vernünftig zu machen, als sich darauf zu verlassen, dass andere brav sein werden (weil sie sonst auf die Finger bekommen) ... und anschließend nachträglich in Beweisnot zu geraten. Warum willst Du Dir das Leben unöntig schwer machen?
Ich mache beides. Die Sache vernünftig (weils weniger Arbeit macht, das gleich zu tun, als eventuell mal nacharbeiten zu müssen) und verlasse mich darauf, dass andere sich an die Gesetze halten.
Und so wehre ich SQL-Injections ab, habe ein sicheres Login-System, und prüfe auch Formulare uind deren Inhalt.
Genau darum geht es doch. Du überprüfst also die Werte, die ein (angebliches) Formular an Deinen Server schickt? Prima - davon rede ich die ganze Zeit.
Ich auch.
Aber ich finde es, im Gegensatz zu Dir und anderen, nicht in Ordnung, dass ich unter Beweisnot geraten soll, wenn ich meinen Usern zu wenig kriminelle Energie (und wir reden hier tatsächlich von Kriminalität und nicht von Kavaliersdelikten!) unterstelle.
Grüße, Lothar
Hallo,
Nur, darum ging es in diesem Thread nie. Änderung der Daten war ohnehin ausgeschlossen, ...
offensichtlich nicht: Wenn es so wäre, hättest du weder disabled noch readonly gebraucht - dann wäre es nämlich egal gewesen, wenn der User Formulardaten ändert und wieder absendet (egal ob mutwillig oder versehentlich). Offensichtlich war die Änderung der Daten aber *NICHT* ausgeschlossen, und deshalb hast du nach Maßnahmen gesucht, um eben das zu erreichen.
Es geht um die Einstellung zu diesem Thema.
Richtig, und die Einstellung ist nun einmal, dass man sich nicht auf die Ehrlichkeit seiner Mitmenschen (Kunden, Kollegen, Lieferanten) verlassen darf. Tut man es doch, wird einem das als "fahrlässig" vorgeworfen, wenn dadurch ein Sach-/Vermögens- oder gar Personenschaden entsteht.
Wie krank ist die Denkweise hier?
Es gelingt mir doch in 1000 anderen Bereichen auch, funktionierende Systeme zu zerstören oder "zu überlisten". Und auch da wird nicht zwingend die (Mit)schuld beim Hersteller gesucht.
Oh doch: Das nennt sich Produkthaftung. In der Technik gibt es, wenn es um die Sicherheit von Einrichtungen geht, sogar den Begriff der "vorhersehbaren Fehlanwendung". Beispiel: Ein kleiner Unterschrank ist nicht dazu gedacht, dass jemand draufsteigt. Die Versuchung ist aber groß, das Teil als "Leiter-Ersatz" zu verwenden. Tut das jemand, und bricht das Schränkchen dabei entzwei, und verletzt sich gar derjenige, der das Teil missbraucht hat, ist der Hersteller mit in der Haftung. Aber sowas von!
Mein Problem hierbei ist: Ich setze genau gem. dieser kranken Denkweise um. Aber mir stinkt sie, diese Art zu denken.
Das wird dir aber nichts nützen.
Mir persönlich sind unzählige Fälle bekannt, wo sich Entscheidungsträger sich hinter irgendwelchen "Vorschriften" verschanzen und diese für ihre Entsheidungen anführen. Diese werden dadurch nicht zwingend richtig.
Das ist nur allzu wahr ...
Das ist - insbesondere im Fall des Internets - das Mindestmaß an Sorgfalt, das man als Programmierer beachten muss.
Ich mache keine Internetanwendung.
Erstens schrieb EKKi "insbesondere im Fall des Internets", also nicht ausschließlich; zweitens sind die verwendeten Techniken im Inter- oder Intranet die gleichen: Eine Client/Server-Kommunikation über HTTP, und ein Server, der irgendeine HTTP-Anfrage erhält, die er zunächst völlig kontextfrei betrachten und analysieren muss.
[...] und verlasse mich darauf, dass andere sich an die Gesetze halten.
Und genau das ist leichtsinnig oder fahrlässig. Irgendjemand hat's in diesem Thread schon angedeutet: Das unbefugte Eindringen in fremde Wohnungen ist auch gesetzwidrig. Lässt du also die Wohnungstür offen, weil's bequemer und einfacher ist?[*]
Aber ich finde es, im Gegensatz zu Dir und anderen, nicht in Ordnung, dass ich unter Beweisnot geraten soll, wenn ich meinen Usern zu wenig kriminelle Energie (und wir reden hier tatsächlich von Kriminalität und nicht von Kavaliersdelikten!) unterstelle.
Wir reden nicht automatisch von Kriminalität!
Ein Datenpaket zusammenzustellen und per HTTP-POST an einen Webserver zu schicken, ist an sich noch nicht kriminell. Was jemand damit erreichen will, *kann* kriminell sein; der Vorgang an sich ist es definitiv nicht. Der könnte nämlich sogar durch Fehlfunktionen oder Fehlkonfiguration irgendeiner Software ausgelöst werden - und dann wären wir wieder bei der Pflicht, die Plausibilität und Zulässigkeit der eintreffenden Anforderung zu überprüfen.
Schönen Tag noch,
Martin
[*] Die oft gesehene Gepflogenheit, den Hausschlüssel im Geranientopf oder unter der Fußmatte zu deponieren, kommt eigentlich auch einer einladend geöffneten Tür gleich.
Hallo Martin
… Lässt du also die Wohnungstür offen, weil's bequemer und einfacher ist?[*]
Nein, er befestigt außen an der Haustür eine Tasche, die den Schlüssel enthält und dazu einen Zettel, auf dem steht, dass dieser nicht benutzt werden soll. (HTML-Formular mit readonly-Feldern bzw. ohne Submit-Button)
[*] Die oft gesehene Gepflogenheit, den Hausschlüssel im Geranientopf oder unter der Fußmatte zu deponieren, kommt eigentlich auch einer einladend geöffneten Tür gleich.
Ja, weil da der Hinweis fehlt, dass der Schlüssel nicht benutzt werden soll. ;-)
Auf Wiederlesen
Detlef
Hi Martin,
offensichtlich nicht: Wenn es so wäre, hättest du weder disabled noch readonly gebraucht - dann wäre es nämlich egal gewesen, wenn der User Formulardaten ändert und wieder absendet (egal ob mutwillig oder versehentlich). Offensichtlich war die Änderung der Daten aber *NICHT* ausgeschlossen, und deshalb hast du nach Maßnahmen gesucht, um eben das zu erreichen.
2 Punkte dazu:
Es geht um die Einstellung zu diesem Thema.
Richtig, und die Einstellung ist nun einmal, dass man sich nicht auf die Ehrlichkeit seiner Mitmenschen (Kunden, Kollegen, Lieferanten) verlassen darf. Tut man es doch, wird einem das als "fahrlässig" vorgeworfen, wenn dadurch ein Sach-/Vermögens- oder gar Personenschaden entsteht.
Halte ich für einen Irrsinn und wundere mich zugleich, wie geschlossen einvernehmlich Ihr das alle seht. Liegt vielleicht wirklich daran, dass ich alle User der Software persönlich kenne.
Ich lasse übrigens auch meine Geldbörse auf meinem Schreibtisch liegen, wenn ich mal zum Parkplatz runter muss. Und meine Butterbrotdose ist auch jedem zugänglich. ;-)
Mir persönlich sind unzählige Fälle bekannt, wo sich Entscheidungsträger sich hinter irgendwelchen "Vorschriften" verschanzen und diese für ihre Entsheidungen anführen. Diese werden dadurch nicht zwingend richtig.
Das ist nur allzu wahr ...
Hat aber was von Lemming.
[...] und verlasse mich darauf, dass andere sich an die Gesetze halten.
Und genau das ist leichtsinnig oder fahrlässig. Irgendjemand hat's in diesem Thread schon angedeutet: Das unbefugte Eindringen in fremde Wohnungen ist auch gesetzwidrig. Lässt du also die Wohnungstür offen, weil's bequemer und einfacher ist?[*]
Ich sag ja. Das Maß ist entscheidend. Ziehe ich nur die Tür zu? Schließe ich ab? Drehe ich den Schlüssel 2 mal rum? Habe ich einen Sicherheitszylinder? Alarmanlage? Kameras? Wachdienst?
Ein Datenpaket zusammenzustellen und per HTTP-POST an einen Webserver zu schicken, ist an sich noch nicht kriminell. Was jemand damit erreichen will, *kann* kriminell sein; der Vorgang an sich ist es definitiv nicht.
Wenn Du das Datenpaket auf nicht vorgesehene Weise mit dem Ziel der Datenmanipulation zusammenstellst, ist das kriminell.
Der könnte nämlich sogar durch Fehlfunktionen oder Fehlkonfiguration irgendeiner Software ausgelöst werden - und dann wären wir wieder bei der Pflicht, die Plausibilität und Zulässigkeit der eintreffenden Anforderung zu überprüfen.
Nutzt ja nichts. Ich sehe das nicht als Pflicht, es wird aber dann zur Pflicht, wenn es die Allgemeinheit so sieht. So funktioniert "Gesellschaft". Im Positiven, wie im Negativen...
Grüße, Lothar
Hi Lothar,
- Ein readonly ist eine Interaktion zwischen GUI und User und darum gehts.
aha, dann habe ich dich die ganze Zeit missverstanden. Ich dachte, es ginge darum, das Zurückschicken veränderter Daten an deine Webapplikation zu verhindern.
Wenn also das Zurückschicken manipulierter Daten nicht das Problem ist, könntest du auf readonly oder ähnliche Maßnahmen ja auch ganz verzichten, weil es ja egal ist, wenn Daten userseitig verändert werden.
- Die Änderung der Ausgangsdaten war/ist ausgeschlossen. Der neu generierte Datensatz hingegen wird mit den Formulardaten erzeugt.
Nanu? Bisher bin ich davon ausgegangen, du wolltest dem User nur einen existierenden Datensatz mit dem "kastrierten" Formular zur Ansicht vorsetzen. Jetzt erwähnst du einen neu generierten Datensatz. .oO(?)
Dabei allerdings unterstelle ich wirklich den Usern ein hohes Maß an krimineller Energie, wie ich finde.
Nein, aber vielleicht Gedankenlosigkeit, Unaufmerksamkeit - oder aber Spieltrieb und sportlich-technischen Ehrgeiz.
Richtig, und die Einstellung ist nun einmal, dass man sich nicht auf die Ehrlichkeit seiner Mitmenschen (Kunden, Kollegen, Lieferanten) verlassen darf. Tut man es doch, wird einem das als "fahrlässig" vorgeworfen, wenn dadurch ein Sach-/Vermögens- oder gar Personenschaden entsteht.
Halte ich für einen Irrsinn und wundere mich zugleich, wie geschlossen einvernehmlich Ihr das alle seht. Liegt vielleicht wirklich daran, dass ich alle User der Software persönlich kenne.
Liegt vielleicht daran, dass du das immer nur auf deinen konkreten Einzelfall beziehst.
Ich lasse übrigens auch meine Geldbörse auf meinem Schreibtisch liegen, wenn ich mal zum Parkplatz runter muss.
Oha. Das würde ich nicht riskieren - außer ich kenne alle Leute, die vorbeikommen und in Versuchung geraten könnten, persönlich und weiß um ihre Vertrauenswürdigkeit. Ich wüsste aber außerhalb meiner Privatwohnung (oder der von persönlichen Vertrauten) keinen Ort, an dem diese Voraussetzung gegeben wäre.
Und meine Butterbrotdose ist auch jedem zugänglich. ;-)
Naja, kommt drauf an, was da Verlockendes drin ist. Banane, Leberwurstbrot, Müsliriegel, Lachsbrötchen ... ;-)
[...] und verlasse mich darauf, dass andere sich an die Gesetze halten.
Und genau das ist leichtsinnig oder fahrlässig. Irgendjemand hat's in diesem Thread schon angedeutet: Das unbefugte Eindringen in fremde Wohnungen ist auch gesetzwidrig. Lässt du also die Wohnungstür offen, weil's bequemer und einfacher ist?[*]
Ich sag ja. Das Maß ist entscheidend.
Ja, richtig. Dein Beispiel mit dem Formular sieht für mich so aus, dass die Tür offen steht und nur ein Schild daneben hängt, auf dem steht: "Kein Zutritt". Die allermeisten Menschen werden sich wohl dran halten, aber es wäre zu einfach, sich über die Beschränkung hinwegzusetzen. Vielleicht hat derjenige, der dann verstohlen trotzdem in die Wohnung schleicht, gar keine kriminellen Ambitionen, sondern will nur mal die Aussicht aus deinem Wohnzimmerfenster genießen? Oder einfach mal sehen, wie der Nachbar wohnt? Nur so aus Neugier?
Ziehe ich nur die Tür zu? Schließe ich ab? Drehe ich den Schlüssel 2 mal rum? Habe ich einen Sicherheitszylinder? Alarmanlage? Kameras? Wachdienst?
Hängt von dir und deiner Umgebung ab. Ich ziehe die Wohnungstür zumindest hinter mir zu, wenn ich nur mal schnell in den Keller, in die Garage oder an den Briefkasten gehe; wenn ich das Haus verlasse, schließe ich sogar ab.
Und es soll sogar Menschen geben, die sich in ihrer eigenen Wohnung einschließen, wenn sie zuhause sind.
Ein Datenpaket zusammenzustellen und per HTTP-POST an einen Webserver zu schicken, ist an sich noch nicht kriminell. Was jemand damit erreichen will, *kann* kriminell sein; der Vorgang an sich ist es definitiv nicht.
Wenn Du das Datenpaket auf nicht vorgesehene Weise mit dem Ziel der Datenmanipulation zusammenstellst, ist das kriminell.
Die Aussage lasse ich gelten - aber du schmeißt zwei Aspekte quasi gleichwertig zusammen:
1. Die Absicht, irgendwas zu manipulieren. Das ist IMHO der Punkt, der darüber entscheidet, ob die Tat als kriminel zu werten ist oder nicht.
2. Das gewählte Mittel. Wir reden von einer Web-Applikation, Internet oder Intranet, is' wurscht, jedenfalls HTTP. Die Schnittstelle ist also der TCP-Port 80 deines Webservers. Jenseits davon hast du keinen Einfluss (außer dass du freundlicherweise auch noch ein auf HTML basierendes GUI zur Verfügung stellst). Ob also der Nutzer seinen Request mit einem gewöhnlichen Browser absetzt, und dazu vielleicht sogar dein Formular verwendet, oder ob er nur die Daten analysiert und dann mit wget einen Request baut, oder ob er gar ein eigenes Programm schreibt, das mit deinem Datenformat harmoniert, kannst du nicht kontrollieren. Und es hat dir auch egal zu sein, solange die Daten an der Schnittstelle (also HTTP-Request und Response) deinen Vorgaben entsprechen. Daher hat es einem Mail-Provider auch egal zu sein, ob ich zum Versenden und Lesen meiner Mails Thunderbird, Outlook, Lotus Notes oder nur einen Telnet-Client verwende. Auch wenn aktuell von einem Fall die Rede ist, wo das anscheinend nicht so ist.
Der könnte nämlich sogar durch Fehlfunktionen oder Fehlkonfiguration irgendeiner Software ausgelöst werden - und dann wären wir wieder bei der Pflicht, die Plausibilität und Zulässigkeit der eintreffenden Anforderung zu überprüfen.
Nutzt ja nichts. Ich sehe das nicht als Pflicht, es wird aber dann zur Pflicht, wenn es die Allgemeinheit so sieht. So funktioniert "Gesellschaft". Im Positiven, wie im Negativen...
Du magst es negativ sehen - ich sehe es eher als die Pflicht eines (Web-)Programmierers, sein "Modul" als Blackbox, losgelöst von Eigenschaften des derzeit gewählten Umfelds, unter allen vorhersehbaren Fehlerbedingungen sicher zu machen. Mit anderen Worten: Diese Black Box darf sich nie auf Bedingungen verlassen, die nicht mit Sicherheit kontrollierbar sind.
So long,
Martin
Hi Martin,
Hi Lothar,
- Ein readonly ist eine Interaktion zwischen GUI und User und darum gehts.
aha, dann habe ich dich die ganze Zeit missverstanden.
Macht nichts. :-)
Wenn also das Zurückschicken manipulierter Daten nicht das Problem ist, könntest du auf readonly oder ähnliche Maßnahmen ja auch ganz verzichten, weil es ja egal ist, wenn Daten userseitig verändert werden.
Eben nicht. Der User soll ja bemerken, dass der Datensatz durch ihn nicht verändert werden soll. Trotz Formular. Genau hierfür ist readonly auch gedacht.
Nanu? Bisher bin ich davon ausgegangen, du wolltest dem User nur einen existierenden Datensatz mit dem "kastrierten" Formular zur Ansicht vorsetzen. Jetzt erwähnst du einen neu generierten Datensatz. .oO(?)
Hab ich vorher schon. Im Prinzip geht es darum, einen Datensatz über ein readonly-Formular zu duplizieren. Mache ich jetzt auch im Hintegrund, ganz egal, was der User abschickt. Dann hab ich Ruh' ;-)
Nein, aber vielleicht Gedankenlosigkeit, Unaufmerksamkeit - oder aber Spieltrieb und sportlich-technischen Ehrgeiz.
Klar. Und der Mopedfahrer, der mit 180km/h über die Landstrasse fegt, ist auch nicht kriminell, sondern von "sportlich-technischen Ehrgeiz" getrieben. Genau, wie der Jugendliche, der sich ein ein Pik Set kauft, nur um mal zu sehen, wo er überall damit hinein kommt. Sportlich-technisch-ergeizig. Ich sehe es einfach viel weniger als kavaliersdelikt an. Es ist kriminell.
Liegt vielleicht daran, dass du das immer nur auf deinen konkreten Einzelfall beziehst.
Stimmt.
Die Aussage lasse ich gelten - aber du schmeißt zwei Aspekte quasi gleichwertig zusammen:
- Die Absicht, irgendwas zu manipulieren. Das ist IMHO der Punkt, der darüber entscheidet, ob die Tat als kriminel zu werten ist oder nicht.
- Das gewählte Mittel. Wir reden von einer Web-Applikation, Internet oder Intranet, is' wurscht, jedenfalls HTTP. Die Schnittstelle ist also der TCP-Port 80 deines Webservers. Jenseits davon hast du keinen Einfluss (außer dass du freundlicherweise auch noch ein auf HTML basierendes GUI zur Verfügung stellst).
Nein. Auch falsch. Habe ich Einfluss drauf.
Und es hat dir auch egal zu sein, solange die Daten an der Schnittstelle (also HTTP-Request und Response) deinen Vorgaben entsprechen.
Ich glaube wirklich, wir reden von verschiedenen Dingen :-))
Daher hat es einem Mail-Provider auch egal zu sein, ob ich zum Versenden und Lesen meiner Mails Thunderbird, Outlook, Lotus Notes oder nur einen Telnet-Client verwende.
Richtig. Aber Dein Chef darf Dir das schon zwingend vorschreiben, stimmts?
So, aber auch für Dich: Ich bin raus aus dem Thread, werde meine Meinung beibehalten, aber letztlich (und leider) auch die Vorgehensweise, eingehende Daten zu verifizieren, um weder versehentlich, noch bewußt Schäden zu produzieren.
Grüße, Lothar
Mahlzeit Lothar,
- Das gewählte Mittel. Wir reden von einer Web-Applikation, Internet oder Intranet, is' wurscht, jedenfalls HTTP. Die Schnittstelle ist also der TCP-Port 80 deines Webservers. Jenseits davon hast du keinen Einfluss (außer dass du freundlicherweise auch noch ein auf HTML basierendes GUI zur Verfügung stellst).
Nein. Auch falsch. Habe ich Einfluss drauf.
Nein.
Und es hat dir auch egal zu sein, solange die Daten an der Schnittstelle (also HTTP-Request und Response) deinen Vorgaben entsprechen.
Ich glaube wirklich, wir reden von verschiedenen Dingen :-))
Dann lege doch bitte mal dar, von welchen Dingen Du redest ... so langsam werde ich nämlich auch verwirrt. Anscheinend bist Du ja doch in großen Teil meiner (bzw. in diesem Fall Martins) Meinung. Aber immer, wenn es konkret zu werden scheint, ist bei Dir alles anders als bei allen anderen, die in irgendeiner Form Formularverarbeitung mit Web-Technologien betreiben.
So, aber auch für Dich: Ich bin raus aus dem Thread, werde meine Meinung beibehalten, aber letztlich (und leider) auch die Vorgehensweise, eingehende Daten zu verifizieren, um weder versehentlich, noch bewußt Schäden zu produzieren.
Wieso leider? Das ist ein vollkommen normales Vorgehen im HTTP-Client-Server-Umfeld ... irgendwie habe ich echt das Gefühl, dass Du entweder extrem frisch in der Materie bist und/oder Dich noch nicht ausgiebig mit sicherheitstechnischen Frage- und Problemstellungen diesbezüglich beschäftigt hast.
MfG,
EKKi
Hallo,
aha, dann habe ich dich die ganze Zeit missverstanden.
Macht nichts. :-)
doch, dann war nämlich der ganze Aufwand und die Zeit, die ich dafür investiert habe, für die Katz'.
Nein, aber vielleicht Gedankenlosigkeit, Unaufmerksamkeit - oder aber Spieltrieb und sportlich-technischen Ehrgeiz.
Klar. Und der Mopedfahrer, der mit 180km/h über die Landstrasse fegt, ist auch nicht kriminell, sondern von "sportlich-technischen Ehrgeiz" getrieben.
Er ist leichtsinnig, gefährlich - aber nicht kriminell.
- Das gewählte Mittel. Wir reden von einer Web-Applikation, Internet oder Intranet, is' wurscht, jedenfalls HTTP. Die Schnittstelle ist also der TCP-Port 80 deines Webservers. Jenseits davon hast du keinen Einfluss (außer dass du freundlicherweise auch noch ein auf HTML basierendes GUI zur Verfügung stellst).
Nein. Auch falsch. Habe ich Einfluss drauf.
Ach? Wie sieht der aus?
Und es hat dir auch egal zu sein, solange die Daten an der Schnittstelle (also HTTP-Request und Response) deinen Vorgaben entsprechen.
Ich glaube wirklich, wir reden von verschiedenen Dingen :-))
Möglich. Du lässt ja immer nur Bruchstücke hören.
Daher hat es einem Mail-Provider auch egal zu sein, ob ich zum Versenden und Lesen meiner Mails Thunderbird, Outlook, Lotus Notes oder nur einen Telnet-Client verwende.
Richtig. Aber Dein Chef darf Dir das schon zwingend vorschreiben, stimmts?
Nö. Wenn er es ernsthaft versuchte, wäre er die längste Zeit mein Chef gewesen.
So, aber auch für Dich: Ich bin raus aus dem Thread
Schade - gerade jetzt, wo wir der Klärung der gegenseitigen Standpunkte allmählich näherkommen.
Ciao,
Martin
Mahlzeit Lothar,
Frage ist trotzdem. Wo fängst an und wo hörst auf? Ich hab Dir ja schon beschrieben, was ich absichere.
Leider nur in einem Nebensatz.
Aber wer weiß schon, ob das ausreicht oder nicht?
Richtig: wer weiß das schon. Deine Leser jedenfalls nicht, wenn Du entsprechend detaillierte Informationen nicht lieferst. :-)
der Datensatz wird einfach deshalb nicht geändert, weil auf dem Server die Information vorhanden ist, dass er nicht geändert werden darf.
Nur, darum ging es in diesem Thread nie.
Nicht?
Änderung der Daten war ohnehin ausgeschlossen,
Das habe ich aber ganz anders verstanden.
es ging lediglich darum, dass der User das identische Formular zu sehen bekommt und aus diesem ein weiterer Datensatz generiert wird. Und hierfür hätte ich mir ein "readonly" für einige Formularelemente gewünscht.
Du schriebst in Deinem ursprünglichen Beitrag:
gibts ne Möglichkeit, die Veränderung eines input-fields zu verhindern und den Inhalt dennoch per POST weiterzugeben
Und die Antwort darauf hast Du erhalten: ja, die gibt es. Und zwar <http://de.selfhtml.org/html/referenz/attribute.htm#input@title=besitzt das <input>-Element das Attribut "readonly">.
Was genau ist Deine Frage hierzu bzw. Dein Problem damit?
Schon. Aber darum geht es gerade nicht. Es geht darum, einfachste und grundlegende Prinzipien der Formularverarbeitung mittels Webtechnologien, die schon vor 15 Jahren galten, zu verstehen und umzusetzen.
Nein, genau DARUM geht es gerade nicht. Es geht um die Einstellung zu diesem Thema.
Das war aus o.g. Eröffnungsbeitrag nicht abzusehen. Dabei handelte es sich um eine ganz normale Frage.
Darüber hinaus behaupte ich mal, dass die Einstellung zum Thema "Formularverarbeitung und Absicherung von Formularen bei Verwendung von Webtechnologien" bei allen anwesenden "alten Hasen" nahezu deckungsgleich oder doch zumindest sehr ähnlich ist.
Wie krank ist die Denkweise hier?
Frag nicht mich - frag den Anwalt Deines geringsten Misstrauens.
Es gelingt mir doch in 1000 anderen Bereichen auch, funktionierende Systeme zu zerstören oder "zu überlisten". Und auch da wird nicht zwingend die (Mit)schuld beim Hersteller gesucht.
Nicht? Das denke ich schon ...
Abgesehen natürlich davon, dass derart "schlampig" programmierte Anwendungen normalerweise *NIEMALS* irgendeine Form von Zertifikat erhalten werden
Was denn? Kein Jodeldiplom? Kein Gar nix? Oweia... *g*
Du magst darüber schmunzeln ...
Du kennst den Unterschied zwischen Äpfeln und Birnen? Du hast angefangen, von kriminellen Benutzern und "Hackern" zu sprechen. Mir hingegen geht es einfach nur um eine vernünftige Absicherung einer offenbar webbasierten Anwendung. Und dazu gehört es eindeutig, die von "irgendwoher" stammenden Daten nicht einfach stumpf zu verarbeiten, sondern sie vorher auf Plausibilität zu überprüfen.
Nein. Das ist - insbesondere im Fall des Internets - das Mindestmaß an Sorgfalt, das man als Programmierer beachten muss.
Ich mache keine Internetanwendung.
Willst Du jetzt auch um Wortklauber werden? Du hast eindeutig von einem HTML-Formular gesprochen.
Es ist immer besser, seine Sache vernünftig zu machen, als sich darauf zu verlassen, dass andere brav sein werden (weil sie sonst auf die Finger bekommen) ... und anschließend nachträglich in Beweisnot zu geraten. Warum willst Du Dir das Leben unöntig schwer machen?
Ich mache beides. Die Sache vernünftig (weils weniger Arbeit macht, das gleich zu tun, als eventuell mal nacharbeiten zu müssen) und verlasse mich darauf, dass andere sich an die Gesetze halten.
Na, wenn Du die Sache vernünftig machst und alle "von außen" kommenden Daten auf dem Server bzw. in dem dort liegenden Skript auf Plausibilität überprüfst, hast Du doch gar kein Problem ... oder was habe ich nicht verstanden?
Genau darum geht es doch. Du überprüfst also die Werte, die ein (angebliches) Formular an Deinen Server schickt? Prima - davon rede ich die ganze Zeit.
Ich auch.
Interessant. Und welche Relevanz hat dann ein HTML-Formular, das *eine* Möglichkeit darstellt, Dein serverseitiges Skript mit Daten zu füttern? Richtig: nur bedingt.
Wenn es nur darum geht, dem Benutzer das gewohnte Formular auf den Bildschirm zu bringen: was genau ist Dein Problem mit dem "readonly"-Attribut?
Aber ich finde es, im Gegensatz zu Dir und anderen, nicht in Ordnung, dass ich unter Beweisnot geraten soll, wenn ich meinen Usern zu wenig kriminelle Energie (und wir reden hier tatsächlich von Kriminalität und nicht von Kavaliersdelikten!) unterstelle.
Nennst Du es kriminell, wenn durch einen Browserfehler falsche Daten an den Server abgeschickt werden und anschließend aufgrund fehlender Überprüfung der Daten anschließend alles Mögliche abraucht?
Überprüfung von Daten hat *IMMER* zu erfolgen - unabhängig von potentiell vorhandener Kriminalität irgendwelcher Benutzer.
Und die Darstellung auf der GUI (in diesem Fall im Browser) hat mit dieser Überprüfung absolut nichts zu tun.
MfG,
EKKi
Hi EKKi,
Und die Antwort darauf hast Du erhalten: ja, die gibt es. Und zwar <http://de.selfhtml.org/html/referenz/attribute.htm#input@title=besitzt das <input>-Element das Attribut "readonly">.
Womit dann die Frage hinreichend beantwortet war. Und, um kein Doppelpost zu erstellen, gings dann weiter. Warum kein readonly bei anderen Formularelementen. Und die Antwort darauf ergab die aktuelle Diskussion.
Das war aus o.g. Eröffnungsbeitrag nicht abzusehen. Dabei handelte es sich um eine ganz normale Frage.
Korrekt. Aber es ging ja weiter. Vielleicht hätte ich doch einen eigenen Thread aufmachen sollen? ;-)
Darüber hinaus behaupte ich mal, dass die Einstellung zum Thema "Formularverarbeitung und Absicherung von Formularen bei Verwendung von Webtechnologien" bei allen anwesenden "alten Hasen" nahezu deckungsgleich oder doch zumindest sehr ähnlich ist.
Behaupte ich auch.
Nicht? Das denke ich schon ...
Stimmt, hast recht. Ein Grund dafür, dass viele Fälle von Vergewaltigungen nicht angezeigt werden. Stichwort: Aufreizende Klamotten, aufreizende Verhaltensweise, u.v.m., nicht wahr? :-(
Ich mache keine Internetanwendung.
Willst Du jetzt auch um Wortklauber werden? Du hast eindeutig von einem HTML-Formular gesprochen.
Ist es Wortklauberei, wenn der Kreis der Anwender eindeutig selektiv, zuzuordnen und jederzeit nachvollziehbar ist????
Na, wenn Du die Sache vernünftig machst und alle "von außen" kommenden Daten auf dem Server bzw. in dem dort liegenden Skript auf Plausibilität überprüfst, hast Du doch gar kein Problem ... oder was habe ich nicht verstanden?
Doch. Ich ärgere mich über den Mehraufwand durch die Denkweise, dass alle User versuchen werden, mich und meine Arbeit zu linken, faken und zu untergraben. ;-)
Nennst Du es kriminell, wenn durch einen Browserfehler falsche Daten an den Server abgeschickt werden und anschließend aufgrund fehlender Überprüfung der Daten anschließend alles Mögliche abraucht?
Soll heißen, ich stehe nicht nur in der Verantwortung, die kriminelle Energie meiner User abzufangen, sondern auch die Fehler anderer Programmierer? Ach so... ;-))
Überprüfung von Daten hat *IMMER* zu erfolgen - unabhängig von potentiell vorhandener Kriminalität irgendwelcher Benutzer.
Ich sehe die Notwendigkeit ja ein. Allerdings halte ich das eher für ein freiwilliges Selbstverständnis, eine (früher hätte man gesagt) Berufsehre als eine seitens des Programmierers gerichtsverwertbare Verantwortung.
Und die Darstellung auf der GUI (in diesem Fall im Browser) hat mit dieser Überprüfung absolut nichts zu tun.
Jetzt drehen wir uns im Kreis. Die Frage ist und bleibt, wo fange ich an und wo höre ich auf, zu überprüfen.
Grüße, Lothar
MfG,
EKKi
Mahlzeit Lothar,
Und die Antwort darauf hast Du erhalten: ja, die gibt es. Und zwar <http://de.selfhtml.org/html/referenz/attribute.htm#input@title=besitzt das <input>-Element das Attribut "readonly">.
Womit dann die Frage hinreichend beantwortet war. Und, um kein Doppelpost zu erstellen, gings dann weiter. Warum kein readonly bei anderen Formularelementen.
Wo genau hast Du danach gefragt? Ich finde hier nur folgendes Zitat aus diesem Beitrag:
Wie mache ich Checkbox und Radiobutton unveränderbar und liefere dioe Werte dennoch beim Server ab (ohne zusätzliche hidden input felder)??
Was genau ist Dein Problem mit dem Attribut "readonly"? Es macht Formularelemente (wie der name schon vermuten lässt) "nur lesbar" ... der Browser sollte die Formularelemente aber natürlich trotzdem an den Server schicken - schließlich wurden sie ja nicht "disabled".
Nicht? Das denke ich schon ...
Stimmt, hast recht. Ein Grund dafür, dass viele Fälle von Vergewaltigungen nicht angezeigt werden. Stichwort: Aufreizende Klamotten, aufreizende Verhaltensweise, u.v.m., nicht wahr? :-(
Huiii, der nächste unpassende Vergleich ... Godwin ist nicht mehr weit! ;-)
Ich mache keine Internetanwendung.
Willst Du jetzt auch um Wortklauber werden? Du hast eindeutig von einem HTML-Formular gesprochen.
Ist es Wortklauberei, wenn der Kreis der Anwender eindeutig selektiv, zuzuordnen und jederzeit nachvollziehbar ist????
Ja. Schließlich geht es um die verwendeten Technologien. Die sind nämlich im Inter- und Intranet nahezu gleich. Und demzufolge sollte auch in *BEIDEN* Bereichen die *GLEICHE* Sorgfalt bei der Anwendungserstellung bzw. Oberflächengestaltung sowie der Datenverarbeitung an den Tag gelegt werden. Schließlich ist nie absehbar, was aus einem zur Zeit vielleicht noch überschaubaren und "nicht so kritischem" Bereich irgendwann in der Zukunft wird. Willst Du *DANN* alles nachträglich absichern?
Na, wenn Du die Sache vernünftig machst und alle "von außen" kommenden Daten auf dem Server bzw. in dem dort liegenden Skript auf Plausibilität überprüfst, hast Du doch gar kein Problem ... oder was habe ich nicht verstanden?
Doch. Ich ärgere mich über den Mehraufwand durch die Denkweise, dass alle User versuchen werden, mich und meine Arbeit zu linken, faken und zu untergraben. ;-)
Das ist kein Mehraufwand. Das ist bei HTTP-Client-Server-Architektur Teil des normalen Aufwands - und das liegt nicht an den "bösen Usern", sondern an der für die verwendeten Zwecke nicht perfekt geeigneten Technologie.
Überprüfung von Daten hat *IMMER* zu erfolgen - unabhängig von potentiell vorhandener Kriminalität irgendwelcher Benutzer.
Ich sehe die Notwendigkeit ja ein. Allerdings halte ich das eher für ein freiwilliges Selbstverständnis, eine (früher hätte man gesagt) Berufsehre als eine seitens des Programmierers gerichtsverwertbare Verantwortung.
Und reicht Dir ersteres nicht aus? Du bist also ein Programmierer ohne Ehre, soso ... ;-)
Sagen wir mal so: ich programmiere lieber "ehrenhaft" und habe nebenbei auch noch die Gewissheit, dass mir wahrscheinlich niemand gerichtlich ans Bein pinkeln kann - als dass ich mir einen faulen Lenz mache und mich darauf verlassen, "dass die User schon nichts Böses machen, ihre Finger bei sich behalten und auch keine Fehler passieren".
Jetzt drehen wir uns im Kreis. Die Frage ist und bleibt, wo fange ich an und wo höre ich auf, zu überprüfen.
Auf dem Server. Und zwar bei *JEDER* Anfrage an diesen. *IMMER*.
MfG,
EKKi
Moin,
Wie mache ich Checkbox und Radiobutton unveränderbar und liefere dioe Werte dennoch beim Server ab (ohne zusätzliche hidden input felder)??
Was genau ist Dein Problem mit dem Attribut "readonly"? Es macht Formularelemente (wie der name schon vermuten lässt) "nur lesbar" ... der Browser sollte die Formularelemente aber natürlich trotzdem an den Server schicken - schließlich wurden sie ja nicht "disabled".
readonly geht nicht für checkboxen und radio-button.
Nicht? Das denke ich schon ...
Stimmt, hast recht. Ein Grund dafür, dass viele Fälle von Vergewaltigungen nicht angezeigt werden. Stichwort: Aufreizende Klamotten, aufreizende Verhaltensweise, u.v.m., nicht wahr? :-(
Huiii, der nächste unpassende Vergleich ... Godwin ist nicht mehr weit! ;-)
Merkst Du was? Du benutzt Godwin als Godwin-Keule ;-) Machs bei irgendwem. Ich fall darauf nicht rein. Du lässt nicht einen einzigen Vergleich zu, immer mit dem Godwinargument. Dieses hast Du aber anscheinend nichtmal im Ansatz verstanden, sonst würdest Du das unterlassen.
Lies es Dir nochmal durch und stelle fest, dass Deine Godwin-Keule viel mehr zu Deiner Verwendung derselben passt, als meine Vergleiche.
Ist es Wortklauberei, wenn der Kreis der Anwender eindeutig selektiv, zuzuordnen und jederzeit nachvollziehbar ist????
Ja. Schließlich geht es um die verwendeten Technologien. Die sind nämlich im Inter- und Intranet nahezu gleich. Und demzufolge sollte auch in *BEIDEN* Bereichen die *GLEICHE* Sorgfalt bei der Anwendungserstellung bzw. Oberflächengestaltung sowie der Datenverarbeitung an den Tag gelegt werden.
Stimmt nicht. Es geht nicht um die Technologie, sondern um den Kreis der Verwender.
Schreibst Du z.B. für Dich höchstselbst ein Script, dass auch nur Du selber nutzt und das auch nur in einem Intranet, läuft Dein Argument doch schon ins Leere.
Schließlich ist nie absehbar, was aus einem zur Zeit vielleicht noch überschaubaren und "nicht so kritischem" Bereich irgendwann in der Zukunft wird. Willst Du *DANN* alles nachträglich absichern?
Nie? Sag niemals nie... (siehe mein Beispiel...oder liebäugelst Du schon wieder mit Godwin?)
Das ist kein Mehraufwand. Das ist bei HTTP-Client-Server-Architektur Teil des normalen Aufwands - und das liegt nicht an den "bösen Usern", sondern an der für die verwendeten Zwecke nicht perfekt geeigneten Technologie.
Falsch. Es liegt an den Usern. Denn auch die nicht perfekt geeignete Technologie erlangt einen Grossteil ihrer Nicht-Perfektion eben erst durch die "bösen User".
Überprüfung von Daten hat *IMMER* zu erfolgen - unabhängig von potentiell vorhandener Kriminalität irgendwelcher Benutzer.
Ich sehe die Notwendigkeit ja ein. Allerdings halte ich das eher für ein freiwilliges Selbstverständnis, eine (früher hätte man gesagt) Berufsehre als eine seitens des Programmierers gerichtsverwertbare Verantwortung.
Und reicht Dir ersteres nicht aus? Du bist also ein Programmierer ohne Ehre, soso ... ;-)
Würde mir ersteres nicht reichen, würd ichs lassen. Das prüfen...und das Programmieren.
Deshalb habe ich aber dennoch eine eigene Meinung zu diesem Thema. Kennst Du ja jetzt.
Sagen wir mal so: ich programmiere lieber "ehrenhaft" und habe nebenbei auch noch die Gewissheit, dass mir wahrscheinlich niemand gerichtlich ans Bein pinkeln kann - als dass ich mir einen faulen Lenz mache und mich darauf verlassen, "dass die User schon nichts Böses machen, ihre Finger bei sich behalten und auch keine Fehler passieren".
OK. Darin stimme ich jetzt wieder mit Dir überein.
Und da wir nun weitestgehend zwar nciht in der Sache selber, aber in deren Resultat übereinstimmen, bedanke ich mich für das heitere Gespräch bei Dir und verabschiede mich aus dem Thread.
Grüße, Lothar
Mahlzeit Lothar,
readonly geht nicht für checkboxen und radio-button.
"Geht nicht" geht nicht.
Falls Du damit meinst, dass Du das Attribut bei Radiobuttons und Checkboxen nicht benutzen kannst: <http://de.selfhtml.org/html/referenz/attribute.htm#input@title=doch, kannst Du>.
Falls Du damit meinst, dass der von Dir verwendete Browser Probleme damit hat: benenne den Übeltäter.
Ja. Schließlich geht es um die verwendeten Technologien. Die sind nämlich im Inter- und Intranet nahezu gleich. Und demzufolge sollte auch in *BEIDEN* Bereichen die *GLEICHE* Sorgfalt bei der Anwendungserstellung bzw. Oberflächengestaltung sowie der Datenverarbeitung an den Tag gelegt werden.
Stimmt nicht. Es geht nicht um die Technologie, sondern um den Kreis der Verwender.
Der spielt keine Rolle: wenn Du Software entwickelst, die durch bestimmte Schnittstellen Daten "von außen" entgegennimmt ohne dass diese Software die Art, Validität, Plausibilität usw. dieser Daten von vornherein beeinflussen kann, dann ist es Deine verdammte Pflicht als Programmierer, die Software so aufzubauen, dass sie sämtliche "von außen" kommenden Daten erst einmal überprüft, bevor sie mit ihnen arbeitet. Dabei ist es absolut egal, wieviele Leute diese Software nutzen, ob man sie gut kennt, ob man ihnen vertraut usw. ... mach es einmal sauber und richtig, dann hast Du anschließend nie Ärger - mach es unsauber und lasch, dann musst Du bei jeder Änderung des Nutzerkreises, der Vertrauensstufe, des Software-Umfangs, der Wichtigkeit usw. daran herumdoktorn. Was ist daran so schwer zu verstehen?
Es hat nichts aber auch absolut gar nichts damit zu tun, ob man paranoid ist, seinen Benutzern nicht vertraut oder sonst irgendetwas in der Richtung: es geht einfach nur darum, dass man es sinnvollerweise von Anfang an richtig macht. Und dazu gehört nun einfach mal eine Überprüfung der "von außen" kommenden Daten, wenn man sich nicht auf diese verlassen kann. Und das kann man bei HTTP-Client-Server-Architektur aus Prinzip nicht (egal wie lieb man die User hat).
Schreibst Du z.B. für Dich höchstselbst ein Script, dass auch nur Du selber nutzt und das auch nur in einem Intranet, läuft Dein Argument doch schon ins Leere.
Bedingt. Natürlich sichere ich ein derartiges Skript auch gegen etwaige Fehleingaben oder Flüchtigkeitsfehler meinerseits ab.
Und sobald auch nur *EIN* Anderer dieses Skript benutzen darf, muss ich sowieso eine vernünftige Validitätsprüfung usw. einbauen - und das hat *NICHTS* mit Paranoidität oder generellem Misstrauen allen anderen gegenüber zu tun, sondern schlicht und ergreifend mit Erfahrung und gesundem Menschenverstand ... jedem können aus Versehen Fehler passieren.
Das ist kein Mehraufwand. Das ist bei HTTP-Client-Server-Architektur Teil des normalen Aufwands - und das liegt nicht an den "bösen Usern", sondern an der für die verwendeten Zwecke nicht perfekt geeigneten Technologie.
Falsch. Es liegt an den Usern. Denn auch die nicht perfekt geeignete Technologie erlangt einen Grossteil ihrer Nicht-Perfektion eben erst durch die "bösen User".
Nein. Die User müssen gar nicht "böse" sein. Es können auch schlicht und ergreifend Fehler (bei der Eingabe, bei der Übertragung usw.) passieren.
Und nun erkläre mir bitte mal, wie Du es bei der aktuellen HTTP-Client-Server-Architektur auch nur ansatzweise schaffen willst, Dich (auf Serverseite) auf die vom Client kommenden Daten verlassen zu können (ohne irgendeine Form von Prüfung).
Deshalb habe ich aber dennoch eine eigene Meinung zu diesem Thema. Kennst Du ja jetzt.
Ja. Ich habe nur das Gefühl, dass Du mit dieser Meinung ziemlich allein dastehst. Weiterhin habe ich das Gefühl, dass diese Meinung in der heutigen Zeit mit den heutigen Technologien, Usern, Gesetzgebern und Rechtsanwälten doch etwas blauäugig ist. Darüber hinaus habe ich die Befürchtung, dass Du - solltest Du diese Meinung auch beruflich so vertreten - bei informierten Arbeit- bzw. Auftraggebern eher auf Unverständnis stoßen wirst.
Aber das ist ja alles Deine Sache ... :-)
Und da wir nun weitestgehend zwar nciht in der Sache selber, aber in deren Resultat übereinstimmen, bedanke ich mich für das heitere Gespräch bei Dir und verabschiede mich aus dem Thread.
Schade - gerade wurde es interessant. Außerdem ist IMHO immer noch nicht abschließend geklärt, wo nun eigentlich genau Dein Problem mit dem Attribut "readonly" ist ...
MfG,
EKKi
Hallo
Es ist aber doch ein rechtliches Problem. Daten ausspähen, Server hacken, Formulardaten faken, usw. sind strafrechtlich relevante Dinge. Der Kunde muß mit seinen Mitarbeitern vertraglich fixieren, was sie dürfen und was nicht.
Darüber hinaus fixiert unser Rechtssystem, was man darf und was nicht.
Man darf auch niemanden umbringen, trotzdem werden Menschen gesetzwidrig getötet. Dass etwas verboten ist, stellt nicht sicher, dass es nicht geschieht.
Als Programmierer muß (!) ich zwingend die Dinge ausschalten, die versehentlich oder grob fahrlässig vom User falsch gemacht werden können. Aber bin ich auch verpflichtet, die Dinge auszuschalten, die er vorsätzlich und in strafrechtlich relevanter Weise "falsch" macht?
Dass sollte, schon alleine in Verantwortung gegenüber deinem Arbeit- oder Auftraggeber, dein Anspruch sein.
Interessantes Thema. Bis zu einem gewissen Grad sehe ich mich hier auch durchaus in der Pflicht, aber wo hört Sicherheitsverständnis auf und wo fängt Paranoia an?
Jedenfalls von grob fahrlässig zu sprechen, weil Formulare nahezu immer gefaked werden können, ist weit aus dem Fenster gelehnt.
Hör bitte auf mit "gefakten Formularen" zu nerven. HTML hat in dieser Hinsicht keinen Bug. Es gibt dir nur nicht das, was du haben möchtest, weil das, was du möchtest, einfach nicht vorgesehen ist. Finde dich damit ab und suche eine Lösung innerhalb der bestehenden Möglichkeiten.
Für die Darstellung von Inhalten ohne Notwendigkeit ein Formular zu verwenden ist Unfug. Wenn du das schon tust (warum man das auch immer will), hast *du* auf der Seite der Verarbeitung zu verhindern, dass etwaig aus dieser Quelle stammende Daten gespeichert werden.
Tschö, Auge
Was hat irgendein Skript, dass auf dem Server liegt und Daten per GET oder POST entgegennimmt, mit irgendeinem HTML-Formular zu tun? Richtig: gar nichts.
Grins.
Ein Script (oder eine Komponente des Scripts) ist in der Regel für die Darstellung einer geeigneten GUI zuständig, welche die API einfach benutzbar gestaltet.
Es ist dir natürlich erlaubt, darauf zu verzichten, und den User darauf hinzuweisen, dass er die Kommandozeile seines Browsers verwenden soll.
Damit wäre dann der Beweis erbracht, dass die Windows Konsole nicht die schlechteste aller Kommandozeilen ist.
mfg Beat
Hi,
Und "je nach dem", weil auch jenseits der vereinbarten Schnittstelle der Kunde ein Recht darauf hat, bestimmte Lösungen zu erhalten. Stichworte: Sicherheit, Performance, usw.
Das hat wenig mit dem Verständniss des Kunden für diese Dinge zu tun.
Nein, aber mit deinem.
Und es ist lustig, dass du hier ausgerechnet das Merkmal Sicherheit erwähnst, wenn du offenbar nicht bereit bist, deine Anwendung diesbezüglich vernünftig aufzubauen.
Selbst wenn derzeit vielleicht davon ausgegangen werden kann, dass die Nutzer des Formulars nicht "gegen dich" arbeiten - ist noch lange nicht gesagt, dass das auch so bleiben wird. Irgendwann kann das Kundenunternehmen den jetzt noch nicht vorhandenen gelangweilten/frustrierten/"nur mal schauen, was geht"-Mitarbeiter bekommen - der dann solche Lücken in deiner Anwendung ausnutzt, sei es in bösartiger Absicht oder nicht.
Spätestens dann würde ich aus Kunden-Sicht dein Werk als Pfusch bezeichnen. Aus Programmierer-Sicht natürlich schon vorher, wenn dir die Risiken bekannt sind, und du sie aber mit untauglichen Argumenten beseite wischst.
MfG ChrisB
hi,
hilfreiche Antworten hast du ja mittlerweile zu genüge bekommen, nur noch mal kurz hierzu
Den User interessiert nicht, wie er die Daten vorgesetzt bekommt ...
Hallo???!!!???
Wer entscheidet das?
DU oder der User?
In meinem Fall hat sich der User das so gewünscht!
Und wie sah das aus? Haben dir die User gesagt, dass sie die Inhalte, die sie im Formular bearbeiten, auch beim Lesen in exakt dem selben Formular und Exakt den gleichen HMTL-Elementen vorfinden möchten?
Und mal neben bei, was unterscheidet mich denn von deinen Usern? Kommen die vom Mond? Wohl kaum, daher bleibt es dabei, mir (default User) ist es Wurscht, wie du mir die Inhalte vorsetzt -- es sei denn, ich wäre Blind, dann hätte ich gerne eine Barrierearme Seite.
...oder bis Menschen wie Du auch in der Lage sind, über den Tellerrand dessen zu schauen, was ihnen einfach so vorgesetzt wird ;-)
Ich abe keine Tellörand ...
mfg
Und mal neben bei, was unterscheidet mich denn von deinen Usern?
Nichts oder auch alles. Je nach dem.
Jedenfalls bist und wirst Du nicht mein User. So einfach ists. Oder so schwer.
Intranet sei dank, ok? ;-)
hi,
Jedenfalls bist und wirst Du nicht mein User.
Aha, also ist es eine 2 Mann anwendung unter Freunden, von der wir hier sprechen?
Intranet sei dank, ok? ;-)
Du kannst danken, wem du willst, würde ich in einem Unternehmen arbeiten, in der so Schlampig programmiert wird, würde der Verfasser des Programmes schneller fliegen als damals noch die Concorde ...
mfg
Hallo,
Du kannst danken, wem du willst, würde ich in einem Unternehmen arbeiten, in der so Schlampig programmiert wird, würde der Verfasser des Programmes schneller fliegen als damals noch die Concorde ...
das ist das eine - aber wenn ich jemand beschäftigen würde, der eben noch Lothar hieß und sich jetzt plötzlich Thomas nennt, würde ich mir auch überlegen, wie ich als Arbeitgeber schnellstmöglich aus dem Vertrag rauskomme, ohne Aufsehen zu erregen.
Ciao,
Martin
Hallo
Du kannst danken, wem du willst, würde ich in einem Unternehmen arbeiten, in der so Schlampig programmiert wird, würde der Verfasser des Programmes schneller fliegen als damals noch die Concorde ...
das ist das eine - aber wenn ich jemand beschäftigen würde, der eben noch Lothar hieß und sich jetzt plötzlich Thomas nennt, würde ich mir auch überlegen, wie ich als Arbeitgeber schnellstmöglich aus dem Vertrag rauskomme, ohne Aufsehen zu erregen.
Na nu komm, *ein Gehalt* für *zwei Leute*, das ist doch auch was. :-)
Tschö, Auge
hi,
das ist das eine - aber wenn ich jemand beschäftigen würde, der eben noch Lothar hieß und sich jetzt plötzlich Thomas nennt, würde ich mir auch überlegen, wie ich als Arbeitgeber schnellstmöglich aus dem Vertrag rauskomme, ohne Aufsehen zu erregen.
Na nu komm, *ein Gehalt* für *zwei Leute*, das ist doch auch was. :-)
Fällt das ganze dann unter Multiple Steuerklassen? ;)
mfg
Stell Dir mal vor, dass ich ein und dasselbe Formular einmal als readonly und einmal als read/write darstellen will, damit der User immer DASSELBE sieht, egal zu welchem Zweck er das Formular öffnet.
'Aussehen' geht html nichts an.
Im extremfall willst du also einen Screenshot von einer GUI ;)
Nur soll er eben nweder bewußt, noch versehentlich Änderungen in der "nur Ansicht"-Version vornehmen können.
Also willst du auch gar keine Daten entgegen nehmen.
Oder werden die Daten an einen fernen Server nicht in deiner Domain gesendet?
Nichts gegen Dich. Aber einfach nachzuplappern, was einem vorgegeben wird und was man auf jeder 2. Seite zu lesen bekommt (Welchen Zweck soll eine nicht veränderbare Selektion haben?), ist eher schwach...
Bitte.
Mir fallen neben den oben erwähnten auch weitere ein.
Z.B., dass ich auch in der serverseitigen Auswertung der Formulardaten NICHTS mehr ändern muss. Bei Deinem Vorschlag "input type=text readonly" stimmt auch der auswertende Teil des Formulares nicht mehr.
Du willst gar keine Daten entgegennehmen, denn es ist nicht notwendig.
Du hast die Daten ja bereits auf dem Server, bevor du sie dem User zur Ansicht auslieferst.
Für deine Zwecke sind Listen total ausreichend.
Der Rest macht CSS.
mfg Beat
