Was ist an diesem Script falsch?

[David Hörpel]

Hi!

Kann mir einer sagen, was an diesem Script falsch ist? Immer wenn die Variablen gefüllt sind, kommt der Fehler "Syntaxfehler", wenn die Variablen leer sind, gibt das Script NAN heraus, obwohl es dann null herausgeben müsste.
Hier das Script:
<Script language="Javascript">
ergebnis1 = eval%

[Cheatah]

Hi,

Hier das Script:
<Script language="Javascript">

ERROR: Required attribute TYPE missing.

ergebnis1 = eval%

Äh... das ist doch hoffentlich nicht alles, oder? Ein Syntaxfehler ist bereits drin; und abgesehen davon sollte die Verwendung von eval() allgemein vermieden werden.

Cheatah

[Cyx23]

Hallo,

... und abgesehen davon sollte die Verwendung von eval() allgemein vermieden werden.

warum eigentlich?

Oder anders gefragt, wenn z.B. die Alternative der zusätzliche Aufruf einer neuen Funktion wäre, was wäre daran "besser"?

Grüsse

Cyx23

[Cheatah]

Hi,

warum eigentlich?

weil dabei Code ausgeführt wird, der augenscheinlich nicht der vollen Kontrolle des Programmierers unterliegt, weil er sonst nicht als String ausgeführt wurde.

Das Risiko bei JavaScript ist zugegebenermaßen gering, weil man mit dieser Sprache eh nichts schlimmes anstellen kann. Die Regel "eval is evil" gilt aber prinzipiell in allen Programmiersprachen. Du solltest schon mit _absoluter_ Gewissheit wissen, was Du tust, bevor Du eval() einsetzt - und wenn Du Dir der Risiken nicht bewusst bist, dann bin ich mir ziemlich sicher, dass Du diese Gewissheit gar nicht haben kannst.

Oder anders gefragt, wenn z.B. die Alternative der zusätzliche Aufruf einer neuen Funktion wäre, was wäre daran "besser"?

Die neue Funktion. Ich unterstelle aber, dass es nicht die einzige Alternative ist: JavaScript beherrscht Referenzen, und auf die meisten Objekte kann verschiedenartig zugegriffen werden, inklusive der Übergabe von Namen in Stringform.

Cheatah

[Cyx23]

Hallo,

weil dabei Code ausgeführt wird, der augenscheinlich nicht der vollen Kontrolle des Programmierers unterliegt, weil er sonst nicht als String ausgeführt wurde.

da kann ich mir allerdings schwerlich ein Risiko vorstellen.

Oder anders gefragt, wenn z.B. die Alternative der zusätzliche Aufruf einer neuen Funktion wäre, was wäre daran "besser"?

Die neue Funktion. Ich unterstelle aber, dass es nicht die einzige Alternative ist: JavaScript beherrscht Referenzen, und auf die meisten Objekte kann verschiedenartig zugegriffen werden, inklusive der Übergabe von Namen in Stringform.

Sicher wird eval auch aus Bequemlichkeit eingesetzt:

function nbg(nlx){eval("document."+nlx+".document.bgColor='blue'");}
function nbg(nlx){document.layers[nlx].document.bgColor='blue';}

Hier ist die Variante ohne eval evtl. auch noch schneller, ansonsten gibt es m.E. schonmal Situationen wo man mit eval Code spart oder seltener Variablen definieren muss.
Ich hatte auch schonmal Sachen die ohne eval nicht realisierbar schienen, oder wo es erheblich sparsamer gelang für verschiedene Browser gleichzeitig zu schreiben.
Auf die Schnelle hab ich jetzt nur das Beispiel location.href=eval("'"+parent.l1.document.title+Ziel+"'") gefunden, und weiss aber jetzt nicht mehr den Zusammenhang ob es nur eine Variable ersetzt oder ob z.B. Opera da sonst nicht wollte, Opera tut sich manchmal mit Variablen schwer und die 6.00 war dermassen buggy, schrecklich was da womöglich unnötig rumsumpft wenn nicht dokumentiert wird...

Grüsse

Cyx23

[Cheatah]

Hi,

weil dabei Code ausgeführt wird, der augenscheinlich nicht der vollen Kontrolle des Programmierers unterliegt, weil er sonst nicht als String ausgeführt wurde.

da kann ich mir allerdings schwerlich ein Risiko vorstellen.

ich formuliere es um: Der auszuführende String kommt irgendwo her, und augenscheinlich nicht aus der Feder des Programmierers. Also ist der User die wahrscheinlichste Quelle - und was _der_ eingibt, sollte nun wirklich nicht einfach so ausgeführt werden.

Sicher wird eval auch aus Bequemlichkeit eingesetzt:

Ja, oder aus Unkenntnis, mangelndem Sicherheitsbewusstsein usw. Ich kenne nur wenige Einsätze von eval() - egal in welcher Sprache - bei denen ich überzeugt bin, dass sie sinnvoll sind.

function nbg(nlx){eval("document."+nlx+".document.bgColor='blue'");}

document[nlx].document.bgColor existiert.

Ich hatte auch schonmal Sachen die ohne eval nicht realisierbar schienen,

Die Betonung liegt hier auf "schienen". Wenn es nicht Unkenntnis über grundlegende JavaScript-Mechanismen (auch z.B. 'this') ist, dann ist es meist ein Konzeptfehler, der durch eine günstigere Funktions- und Variablenstruktur sehr sauber zu lösen wäre.

Auf die Schnelle hab ich jetzt nur das Beispiel location.href=eval("'"+parent.l1.document.title+Ziel+"'") gefunden,

Je nach Browser ist jener document.title auch (vom User!) schreibbar; Du hast also nicht den leisesten Schimmer, was hiernach passieren mag. Missbrauch ist möglich.

Aus welchem Grund sollte in einem Title eigentlich etwas stehen, dass man als URL-Basis verwenden kann? Und warum eval()st Du auf eine String-Verknüpfung, um anschließend einen String zu erhalten, den Du schon bei der String-Verknüpfung selbst hattest?

Cheatah

[Cyx23]

Hallo,

document[nlx].document.bgColor existiert.

ist allerdings noch kompakter als .layers[..

Die Betonung liegt hier auf "schienen". Wenn es nicht Unkenntnis über grundlegende JavaScript-Mechanismen (auch z.B. 'this') ist, dann ist es meist ein Konzeptfehler, der durch eine günstigere Funktions- und Variablenstruktur sehr sauber zu lösen wäre.

wenn sich das Konzept etwas während der Entwicklung ändert, kommt ausser Unkenntnis auch schonmal der Kostenfaktor in Frage, der kurzfristige oder selbst der kursichtige Blick auf rasche Liquidität wird immer wieder mal den Vorrang haben.

Auf die Schnelle hab ich jetzt nur das Beispiel location.href=eval("'"+parent.l1.document.title+Ziel+"'") gefunden,

Je nach Browser ist jener document.title auch (vom User!) schreibbar; Du hast also nicht den leisesten Schimmer, was hiernach passieren mag. Missbrauch ist möglich.

der Missbrauch eine andere URL anzusteuern? Na ja, ich hab kein besseres Beispiel gefunden, offenbar verwende ich eval deutlich seltener als zuerst von mir vermutet, trotzdem möchte ich diese Möglichkeit nicht missen.

Aus welchem Grund sollte in einem Title eigentlich etwas stehen, dass man als URL-Basis verwenden kann?

es war die kompakteste Möglichkeit für ein Frame verschiedene gleiche Sprungziele bei verschiedenen alternativen Dateien zu ermöglichen. Wohl ein ähnliches Problem wie Werteübergabe bzw. hier die Ersparnis einer Variablen in top welche Datei gerade im Frame ist, wobei etwas wie nur "#+ziel" nicht ging.

Und warum eval()st Du auf eine String-Verknüpfung, um anschließend einen String zu erhalten, den Du schon bei der String-Verknüpfung selbst hattest?

ich müsste da nochmal testen was es sollte, wie gesagt nicht dokumentiert und schon was älter, ich vermutete ja gerade eine Besonderheit bei Opera600 (oder 5, oder Mozilla 09; vielleicht könnte es auch sein dass irgendwelche Objekte erstmal noch gar nicht existieren.

Aber ich hab noch was gefunden, soll jedoch kein Beispiel sein dass es ohne eval nicht ginge (und Details wie px oder pixelleft usw. werden hier bewusst "übersehen"):

if(document.layers)au="sz"; if(document.all)au="all.sz.style"; if(document.getElementById)au="getElementById('sz').style";
function dkr(){
abo=25;
eval("document."+au+".left="+abo+";");

... hier ist es halt angenehm, für alle Browser recht kompakt mit einer Anweisung auszukommen.
Oder geht es sogar ohne eval noch kürzer?

Grüsse

Cyx23

[Cheatah]

Hi,

document[nlx].document.bgColor existiert.
ist allerdings noch kompakter als .layers[..

ja; wobei auch letzteres ohne eval() funktioniert.

wenn sich das Konzept etwas während der Entwicklung ändert, kommt ausser Unkenntnis auch schonmal der Kostenfaktor in Frage, der kurzfristige oder selbst der kursichtige Blick auf rasche Liquidität wird immer wieder mal den Vorrang haben.

Ja, stimmt... Kurzsichtigkeit sollte meiner Liste auch noch hinzugefügt werden.

Je nach Browser ist jener document.title auch (vom User!) schreibbar; Du hast also nicht den leisesten Schimmer, was hiernach passieren mag. Missbrauch ist möglich.
der Missbrauch eine andere URL anzusteuern?

Nun, dass man mit JavaScript nicht wirklich schlimme Dinge tun kann, habe ich bereits erwähnt. Allerdings ist durchaus denkbar, dass ein findiger Hacker auf diese Weise einen Weg findet, die Same Origin Policy zu umgehen, und somit Einblicke in das Userverhalten auf _Deiner_ Site bekommt - oder ähnliches. Ich bin kein Hacker und kann daher nur befürchten, in welche Richtung es gehen kann.

trotzdem möchte ich diese Möglichkeit nicht missen.

Deshalb gibt es eval() in fast jeder Sprache - man sollte nur bei _jeder_ _einzelnen_ Verwendung äußerst gründlich geprüft haben, dass es _wirklich_ keine andere sinnvolle Alternative gibt. Alles andere wäre leichtfertig und ein u.U. hohes Risiko.

Sicherheit ist kein Ziel, sondern ein Weg. Man muss ihn stetig gehen.

Aus welchem Grund sollte in einem Title eigentlich etwas stehen, dass man als URL-Basis verwenden kann?
es war die kompakteste Möglichkeit für ein Frame verschiedene gleiche Sprungziele bei verschiedenen alternativen Dateien zu ermöglichen.

In anderen Frames lassen sich Variablen unterbringen, welche dafür verwendet werden können, ohne mögliche Seiteneffekte zu riskieren.

ich müsste da nochmal testen was es sollte, wie gesagt nicht dokumentiert und schon was älter,

Bei solchen Gelegenheiten sieht man, wie wichtig eine gute Dokumentation ist ;-)

Aber ich hab noch was gefunden, soll jedoch kein Beispiel sein dass es ohne eval nicht ginge

Wie kommst Du denn darauf?

if(document.layers)au="sz"; if(document.all)au="all.sz.style"; if(document.getElementById)au="getElementById('sz').style";

if (document.layers) au = document.sz;
if (document.all) au = document.all.sz.style;
if (document.getElementById) au = document.getElementById('sz').style;
...
au.left = abo

Geht meiner Ansicht nach ziemlich hervorragend.

Oder geht es sogar ohne eval noch kürzer?

Dem ist in aller Regel so. Kürzer, übersichtlicher, wartbarer, sicherer.

Cheatah

[Cyx23]

Hallo,

wenn sich das Konzept etwas während der Entwicklung ändert, kommt ausser Unkenntnis auch schonmal der Kostenfaktor in Frage, der kurzfristige oder selbst der kursichtige Blick auf rasche Liquidität wird immer wieder mal den Vorrang haben.

Ja, stimmt... Kurzsichtigkeit sollte meiner Liste auch noch hinzugefügt werden.

es ist auch ein Problem der Börsen bzw. des Kapitalflusses, es lohnt sich offenbar immer wieder kurzfristige Gewinne auf Kosten der späteren Situation zu machen; der Bilderbuchkapitalist nach Marx hatte immerhin noch etwas Interesse am Erhalt der Produktionsmittel.

ich müsste da nochmal testen was es sollte, wie gesagt nicht dokumentiert und schon was älter,

Bei solchen Gelegenheiten sieht man, wie wichtig eine gute Dokumentation ist ;-)

Da wäre vielleicht ein JavaScript Editor nützlich der Kommentare getrennt verwaltet oder am Schluss auf Wunsch automatisch aus der Endversion entfernt.

if (document.layers) au = document.sz;
if (document.all) au = document.all.sz.style;
if (document.getElementById) au = document.getElementById('sz').style;
au.left = abo
...   ... Kürzer, übersichtlicher, wartbarer, sicherer.

Danke für das Beispiel, es ist tatsächlich kürzer.

Grüsse

Cyx23

[Guardian]

Bitte nochmal das script, es ist nur zum teil verfügbar!

[ole]

hi

<Script language="Javascript">
ergebnis1 = eval%

was daran falsch ist...naja, das script an sich fehlt zum groß teil

so long
ole
(8-)>