![]() Mailinglisten-Archive |
Nabend Lutz, du sagst es... der Anwender sollte es Entscheiden... aber wer ist der Anweden, dazu gibts bis jetzt ja noch keine Antwort... Leichter w�re es wenn man dirket auf der domain mit nem frameset arbeiten w�rde. Dann w�re die sicherheit dennoch gegeben und php k�nnte javascript anweisen und javascript k�nnte auch agieren in beiden frames. MfG Tobias Lutz Zetzsche schrieb: > Hallo Tobias, > > Hilfe, jetzt seit Ihr schon zwei "Tobiasse" in dieser Diskussion... :-D > > Am Freitag, 16. M�rz 2007 15:31 schrieb Tobias Fichtner: > >>Deswegen darf javascript auch nicht mehr als ein Browser zul�sst. >>Und es sollte ja zumindest Domain-�bergreifendes Arbeiten >>m�glichsein. > > > Das sagst Du als Programmierer. ;-) Als Programmierer f�ndest Du es > praktisch, wenn Du bei Deiner Anwendung domain�bergreifend mit > Javascript und AJAX arbeiten k�nntest. Als Anwender m�chte ich das aber > gerne unterbinden, denn wei� ich bei der unendlichen Zahl von > Internetseiten, die ich besuche, ob ich allen trauen kann und ob alle > so programmiert sind, da� XSS zu meinem Schaden ausgeschlossen ist? > Einmal falsch geklickt, und schon habe ich mir doch einen Trojaner > eingefangen... > > Ich denke, da� in diesem Konflikt ganz klar das Sicherheitsinteresse des > Anwenders entscheidend ist und nicht die W�nsche des Programmiers. > > Im �brigen: Wer hindert Dich daran, dieses Domainproblem dadurch zu > umgehen, da� Du Dir eine Wrapper-Datei baust, die im PHP-Skript mit > include() per HTTP die gew�nschte, externe Seite einbindet (ich rede > nicht vom Inkludieren von PHP-Code)? Gut, dann hat nat�rlich der > Anwender wieder ein potentielles Sicherheitsproblem, ohne es zu > wissen... > > Viele Gr��e > Lutz
php::bar PHP Wiki - Listenarchive