- 7. September 2014

SAPUI5 & Same-Origin Policy: Lokales Testen mittels Proxy

Heutzutage sind Webbrowser mit einer Vielzahl an standardmäßig aktivierten Sicherheitsfeatures ausgestattet. Neben einer eingebauten Cross-Site-Scripting-Prüfung, welche eine erste Sicherheitsstufe zur Verhinderung des Einschleusens von fremden Code in eine Anwendung darstellt, hat ebenso die Same-Origin-Policy Einzug in moderne Webbrowser gefunden. In diesem Artikel erfahren sie, wann und warum die Same-Origin-Policy bei der Entwicklung von SAPUI5 Anwendungen zur Hürde werden kann. Natürlich erfahren Sie ebenfalls, wie diese Hürde ohne großen Aufwand zu meistern ist.

Wir sind Ihr Dienstleister für die Entwicklung, die Ihr SAP noch besser macht.
Wir beraten sie zu Vor- und Nachteilen der SAP UI-Technologien und unterstützen Sie bei Planung und Design Ihrer Applikationen.

Wir sind Ihr Dienstleiter für Ihr Entwicklungsprojekt, das den Anwender in den Mittelpunkt stellt.

Der perfekte Einstieg in das Thema SAPUI5 ist unser SAP UI5 Kickstarter Workshop.

Gerne spreche ich mit Ihnen über Ihre Ausgangslage und zeige Lösungsmöglichkeiten auf. Auf Wunsch unterbreite ich Ihnen im Anschluss ein unverbindliches Angebot.

Kontaktieren Sie mich: Telefon 0211.9462 8572-16 oder per E-Mail info@erlebe-software.de

Same-Origin Policy kurz erklärt

Die Same-Origin Policy (SOP) ist ein wichtiges Sicherheitskonzept für eine Reihe von browserseitiger Programmiersprachen, wie beispielsweise JavaScript, die Programmiersprache der SAPUI5 Library. JavaScript ist faktisch die Programmiersprache des Webs und wird in jeder modernen Webanwendung eingesetzt. Neben komplettem Zugriff auf das Document Object Model (DOM), also dem „HTML-Baum“ der Anwendung, ist durch JavaScript auch der direkte Zugriff auf die Kommunikation zwischen Anwendung und Webserver möglich. Durch die SOP wird kurz gesagt der Zugriff auf Objekte anderer Webseiten, die nicht der „Origin“ entsprechen, blockiert. Somit wird beispielsweise verhindert, mittels JavaScript Grafiken, Texte oder eben Daten von bspw. OData Schnittstellen nachzuladen, falls die Origin abweicht.

In welchen Fällen die SOP eine Anfrage akzeptiert bzw. abweist zeigt die folgende Tabelle. Die Origin ist dabei so definiert, dass sowohl Protokoll, URI und Port identisch sein müssen.

Angesprochene URLErgebnisGrund
http://www.example.com/dir/page2.htmlJaselbes Protokoll und Host
http://www.example.com/dir2/other.htmlJaselbes Protokoll und Host
http://www.example.com:81/dir/other.htmlNeinselbes Protokoll und Host, aber anderer Port
https://www.example.com/dir/other.htmlNeinanderes Protokoll
http://en.example.com/dir/other.htmlNeinanderer Host
http://example.com/dir/other.htmlNeinanderer Host (genaue Übereinstimmung benötigt)
http://v2.www.example.com/dir/other.htmlNeinanderer Host (genaue Übereinstimmung benötigt)
http://www.example.com:80/dir/other.htmlN/APort eindeutig. Hängt von der Implementierung des Browsers ab.

Quelle: Wikipedia

SAPUI5 und die Same-Origin Policy

SAPUI5 Anwendungen laufen in der Regel auf dem SAP NetWeaver Gateway und werden von dort an den Anwender ausgeliefert. Während der Entwicklung kann es aber durchaus nötig sein, den vom Gateway bereitgestellten Webservice direkt aufzurufen um die Anwendung auf dem Entwicklungsrechner testen zu können. In diesem Fall greift wieder die Same-Origin Policy: Die lokale Adresse, in der Regel http://localhost/, stimmt nicht mit der Adresse des Gateway überein. Die SOP verhindert das Laden der benötigten OData Daten über die Schnittstelle.

Damit solche Szenarien dennoch ausgeführt werden können kommt in sogenannter Proxy zu Einsatz. Dieser vermittelt sozusagen zwischen Webbrowser und Gateway und leitet die entsprechenden Anfragen um:

OData Aufruf verstößt gegen Same-Origin Polixy

OData Aufruf verstößt gegen Same-Origin Policy

Durch den Einsatz eines Proxys werden die Anfragen an die OData Schnittstelle umgeleitet, für den Browser erscheinen diese Anfragen unter der gleichen URL. Somit verstoßen diese Anfragen nicht gegen die SOP und werden wie gewünscht bearbeitet:

sadsadsad

Durch Proxy verstößt der OData Aufruf nicht gegen die Same-Origin Policy

Proxy in Eclipse aktivieren

Wird eine SAPUI5 Applikation mit Eclipse und den entsprechenden Entwicklertools entwickelt, kann ein entsprechender Proxy in der Konfigurationsdatei des Projekts aktiviert werden. Diese ist innerhalb der Ordnerstuktur des Projekts unter dem Pfad WebContent > WEB-INF > web.xml zu finden.

SAP Gateway Proxy

Proxy Konfiguration in Eclipse

Die obige Abbildung zeigt eine beispielhafte Konfiguration unter der Annahme, dass der OData Service unter der URL http://gateway.mindsquare.de:8000 zu erreichen ist. Da nicht grundsätzliche alle HTTP-Requests der Anwendung umgeleitet werden müssen, kann ein URL-Pattern angegeben werden. Die Umleitung gilt in diesem Fall nur für Aufrufe, die mit /proxy/ beginnen.

OData Aufruf aus JavaScript

Damit nun alle OData Aufrufe auf das angegebene URL-Pattern passen, empfiehlt es sich die URL in eine extra Methode auszulagern. Im nachfolgenden Beispiel passiert der „zusammenbau“ der OData Serivce Adresse in der Methode getUrl. In Abhängigkeit der aktuellen URL (window.location.hostname) wird entweder ein proxy vorangestellt und somit der Proxy verwendet, oder einfach direkt die URL zurückgegeben, da kein Proxy benötigt wird wenn die App auf den Gateway Server ausgeführt wird.

Proxy über JavaScript aufrufen

Proxy über JavaScript aufrufen

Abschließend interessiert mich natürlich, wie sie bei der Entwicklung Ihrer Anwendungen mit dem Thema Same-Origin Policy umgehen.

Kennen Sie weitere Möglichkeiten oder hat sich ein anderer Ansatz für Sie bewährt? Ich freue mich über einen Erfahrungsaustauch über die Kommentarfunktion am Ende des Artikels. Natürlich beantworte ich dort auch gerne weitere Fragen zum Thema.


SHARE



Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.