Also so langsam fällt es mir schwer dir zu folgen. Also doof und die anderen hätten. Ich meine wo genau ist dein Punkt??
Es gibt Frameworks, die genau darum sich kümmern.
Die Browser nehmen dir die meiste Arbeit ab.
Und vor allem den SOP zu setzen ist ja gerade mal 0 das Problem, es sei den die zu Grunde liegende Anwendung ist schlecht und man kann es nicht setzen…
Also die Diskussion geht mal ins leere irgentwie.
Der Punkt ist: Jemand der keine Ahnung hat (in diesem Fall ich), versucht irgendeine triviale Sache zu machen.
Es geht um einen GET-request.
function doTest()
{
console.log('Well, here we go...');
var url = generateUrl();
$.ajax({
type : "GET",
contentType: "text/html",
url : url,
success : function(res) {
console.log('So there it is', res);
},
error : function(e) {
console.log("ERROR: ", e);
}
});
}
Und das funktioniert nicht. Irgendwas mit CORS. Ja gut, dann schaut man halt mal auf Cross-Origin Resource Sharing (CORS) - HTTP | MDN und schaut, was die Ursache ist…
- Reason: CORS disabled
- Reason: CORS request did not succeed
- Reason: CORS header ‘Origin’ cannot be added
- Reason: CORS request external redirect not allowed
- Reason: CORS request not http
- Reason: CORS header ‘Access-Control-Allow-Origin’ missing
- Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘xyz’
- Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’
- Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’
- Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’
- Reason: CORS preflight channel did not succeed
- Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’
- Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’
- Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel
- Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed
Ähh… ja, nochmal nachschauen.
Es geht um einen GET-request.
Dann schaut und liest man, und wird im schlimmsten Fall auf sowas wie RFC 6265 - HTTP State Management Mechanism verwiesen. Da kann man sich z.B. sowas hier durchlesen:
A user agent MUST use an algorithm equivalent to the following
algorithm to parse a „set-cookie-string“:
If the set-cookie-string contains a %x3B („;“) character:
The name-value-pair string consists of the characters up to,
but not including, the first %x3B („;“), and the unparsed-
attributes consist of the remainder of the set-cookie-string
(including the %x3B („;“) in question).Otherwise:
The name-value-pair string consists of all the characters
contained in the set-cookie-string, and the unparsed-
attributes is the empty string.If the name-value-pair string lacks a %x3D („=“) character,
ignore the set-cookie-string entirely.The (possibly empty) name string consists of the characters up
to, but not including, the first %x3D („=“) character, and the
(possibly empty) value string consists of the characters after
the first %x3D („=“) character.Remove any leading or trailing WSP characters from the name
string and the value string.If the name string is empty, ignore the set-cookie-string
entirely.The cookie-name is the name string, and the cookie-value is the
value string.
Alles klar. Als „professioneller Entwickler“ sollte man sich das durchlesen und verinnerlichen und immer im Hinterkopf halten, wenn man die Farbe eines Buttons per CSS anpasst. (Hier muss ich jetzt aufpassen, den hochkomprimierten Sarkasmus, der sich bei mir angesammelt hat, nicht zu geballt rauszulassen).
Es geht um einen GET-request.
Man schaut sich das ganze genauer an, und sieht, welche haarsträubenden Aufwände und muksigen Workarounds notwendig sind. Man schaut z.B. über https://stackoverflow.com/search?q=is%3Aquestion+cors und sieht über zweiunddreißig tausend Fragen(!) zu diesem Thema.
Es geht um einen GET-Request.
Und schließlich ändert man das Codestück, so, dass es geht:
function doTest()
{
console.log('Well, here we go...');
var url = generateUrl();
$.ajax({
type : "GET",
dataType: 'jsonp',
contentType: "text/html",
url : url,
success : function(res) {
console.log('So there it is', res);
},
error : function(e) {
console.log("ERROR: ", e);
}
});
}
Vielleicht ist es naiv, idealistisch, und jede Abweichung davon eine Folge oder Ausprägung des üblichen Programmierer-Weltschmerzes, aber es hätte ja sein können, dass man das ganze irgendwie sinnvoll begründen kann.
Aber in diesem Sinne geht die Diskussion hier wirklich ins Leere: Die Antwort auf meine Frage, ob das irgendeinen Sinn ergibt, kann offenbar nur beantwortet werden mit einem schulternzuckenden: „Naja, das ist halt so, find’ dich damit ab“.
Das werd’ ich dann mal versuchen, soweit wie es notwendig ist.
Mal kurz eine Frage ohne jegliches Hintergrundwissen eingeworfen: Hat SOP denn zwingend was mit Cookies zu tun? Geht es bei SOP nicht darum cross-site-attacks zu unterbinden?
Bei XSS Attacken im Allgemeinen werden 2 unterschieden:
Stored / DOM Based
Reflected
In beiden Fällen wird im „einfachsten Fall“ Quellcode, der auch zur Ausführung kommt, auf eine dir „vertraute“ Seite eingeschleust.
Bei den Stored XSS würde man so vorgehen, am Beispiel dieses Forums.
Ich schreibe ein Script , das bei dir zur Ausführung kommt.
Warum ist das schlimm? - Klar JS wird Client-Seitig, also durch deinen Browser ausgeführt. Also macht das Script ersteinmal alles in deinem COntext.
Das bedeutet, dass (siehe oben) per Definition bei jeder HTTP Abfrage es auch automatisch Cookies anhängt, obwohl diese eigentlich in dem Sinne nicht ausgelesen werden können.
Das führt dazu, dass man das Forum so kapern könnte.
Geht jetzt aber nicht, weil.
Und Und Und
Daher haben Cookies etwas mit SOP zu tun. Klar. Cookies haben aber auch weitere Einstellungen, HSTS Flag zum Beispiel.
Die mit dem * markierten sind aber auf die korrekte Funktionsweise des Browsers angewiesen.
Grund hierfür, liegt darin, dass das zugrundliede LIegende Protokoll sehr einfach ist. Das kennt die meisten heute exstierenden Anwendungen und Implementierungen gar nicht.
He 
Hehe. 
Theheheh. 
https://www.golem.de/news/url-trick-ein-zeichen-mehr-und-youtube-ist-werbefrei-2006-149095.html
Vielleicht sollten die bei YouTube/Google mal professionelle Entwickler einstellen *scnr*
In den Entwicklertools von Chrome/Chromium oder Firefox zeigt sich, dass einige Cross-Origin-Requests blockiert werden.
Ist doch vorteilhaft, ich weiß nicht, wieso du dich darüber aufregst… Einen geschenktem Gaul schaut man nicht ins Maul.
Btw., https://en.wikipedia.org/wiki/List_of_Google_Easter_eggs#YouTube tippt mal während des Videos „awesome“ ein für Party. 
Laut den Kommentaren klappt das wohl auch bei Golem selbst
Ich fand nur lustig, dass das gemeldet wurde, wenige Tage nachdem ich diese (so naive) Frage gestellt habe. Jetzt warte ich nur drauf, dass irgendein „Senior Professional JavaScript Developer“ (also irgendein Bachelor Of Arts, der seit zwei Jahren Webseiten bastelt) an der passenden Stelle ein "." an irgendeine RegEx hängt, ~„damit es funktioniert“, um dann in Zukunft versehentlich auch auch requests nach youtube.com.scam.ru durchgehen zu lassen *zurücklehnt und Chips mampft*
Haha! 
youtube.com.wedontstealyourcreditcardnumberoranyadditionalinformation.ky klingt doch gleich viel vertrauenswürdiger. 
Gute Frage, also bei der SOP geht es darum, eine Sicherheit gegenüber des Webservers zu haben, nicht gegenüber des gleichen Clients… Wenn ich das richtig verstand…