Kilka słów o Same Origin Policy, czyli artykuł powiązany z AJP1.3 Connector. Czy i jak można wykorzystać ww. konektor? Jednym z zastosowań i udogodnień z tym związanych jest możliwość bezproblemowego manipulowania ramkami w strukturze strony internetowej.

Zasada Same Origin Policy dotyczy właśnie manipulowania strukturą innego dokumentu w ramach obecnego dokumentu (o określonym adresie url). Gdy ramkę ze stroną generowaną przez Tomcata zagnieździmy w dokumencie HTML serwera Apache HTTP to już się domyślamy, że wszelka manipulacja (węzłami, funkcjami Javascript itp.) zakończy się niepowodzeniem z powodu tego chociażby, że główny dokument działać będzie domyślnie na porcie 80, a Tomcat np. 8080. Rozbieżność portu ogranicza nasze działania. O tym już wiecie, czas dowiedzieć się więcej na temat SOP. 

Na powyższym obrazku macie dwa przykłady opisane, które pokazują na czym polega Same Origin Policy. Tyle praktyki, ale co z teorią?

Same Origin Policy – zasada tożsamego pochodzenia – została wprowadzona w przeglądarkach internetowych w celu zabezpieczenia użytkowników serwisów WWW przed utratą poufnych danych. Polega ona na tym, że skrypty na stronie A nie mają dostępu do zasobów na stronie B, jeżeli adresy tych stron różnią się protokołem, nazwą domeny lub numerem portu. Reguła ta znacząco utrudnia tworzenie aplikacji, które są udostępniane na różnych domenach i które, wyświetlone na tej samej stronie (w iframe’ie) powinny w „dobrych zamiarach” komunikować się ze sobą bez udziału serwera.

Deweloperzy opracowali różne techniki, które pozwalają „obejść” powyższe zabezpieczenia. Ostatecznie problem został rozwiązany przez twórców standardu HTML5, który definiuje funkcję window.postMessage przewidzianą specjalnie do bezpiecznej komunikacji pomiędzy skryptami z różnych domen. Funkcja ta jest obecnie implementowana przez większość nowoczesnych przeglądarek.

[1] http://blog.xpro.biz/index.php/easyxdm-czyli-jak-latwo-ominac-regule-same-origin-policy/