[dss-developer] CORS <Cross-Origin Resource Sharing> Probleme mit DSS lighttpd-Server

[Chris Gross]

Guten Tag,

Ich entwickle zur Zeit an einer (AngularJS) Web-App  zur Integration des digitalSTROM-Systems, in eine "one  for All“ Remote-App. Als Entwicklungsplattform setzte ich einen Standard-IDE (Webstrom) ein und darin scheint mein Problem zu liegen. Im IDE ist auch ein HTTP-Server integriert (leider ohne pass through Proxy etc.), dass bedeutet, dass man die App-Files vom IDE/Server liest, jedoch die XMLHttpRequest direkt zum DSS-Server sendet. Das funktioniert auch einwandfrei, wenn man dies via CORS <Cross-Origin Resource Sharing> macht, mit einer kleinen Ausnahme, dass das Cookie mit dem Applikation-Token nicht übertragen werden, denn die werden gemäss W3C-HTTP-Spezfikation standardmässig nicht übertragen werden darf (siehe Anhang). 

Nach etlichen durchgearbeiteten Nächten und jeder menge Kaffee, habe ich folgendes festgestellt. Mein Framework und ich, sollten alles richtig machen 😜:

	• 	Der erste Aufruf mit der App zum lesen des Token’s funktioniert einwandfrei (https://dss.local:8080/json/system/requestApplicationToken?applicationName=cFlat)
	• 	Wenn ich den Request manuell via Browser aufrufe erhalte ich die Informationen DSS-Server (https://dss.local:8080/json/apartment/getStructure)

Theorie gut, Praxis schlecht, sobald ich diese Calls in der App ausführe fehlt das Token-Cookie...

Nach dem Studium der CORS-Spezifikationen, habe ich herausgefunden, dass man das Problem lösen kann, wenn man auf dem HTTP-Server des DSS den Parameter Access-Control-Allow-Credentials setzen muss, also rein ins vergnügen mit dem Studium der Doku des lighttpd-Servers.
  
Die Lösung wäre (Betonung auf wäre), anpassen des lighttpd.conf Files um die Cookies und CORS generell zu aktivieren und danach digitalSTORM zu informieren, mit der bitte den Patch, offiziell in den Server zu integrieren:

 Patch lighttpd.conf (Sorry digitalSTROM):

	• server.modul -> mod_setenv starten
	• setenv.add-response-header = (                        -> CORS Response-Header setzen
        	"Access-Control-Allow-Origin" => „*", 
        	"Access-Control-Allow-Headers" => "accept, origin, x-requested-with, content-type, x-transmission-session-id“,
        	"Access-Control-Expose-Headers" => "X-Transmission-Session-Id“,
        	"Access-Control-Allow-Methods" => "GET, POST, OPTIONS“,
		)

Diese Lösung habe ich leider nicht zum laufen gebracht, da ich kein Linux-Spezialist bin sondern (nur) ein Software Engineer (vielleicht liegt dort das Problem) !! 😁 !!.


Nach einer langer Ausführung nun zu meinen Fragen:

Hat jemand eine Idee wie ich den Patch zum laufen bringen kann.
Gibt es eine Umgehungs-Lösung zu meinem Problem.
Damit ich weiter Testen und Entwickeln kann, ist es möglich die Session-Token Kontrolle temporär auf dem DSS-Server zu deaktivieren.



!! Ich wäre froh, wenn mir jemand weiter Helfen könnte, da dieses Problem zurzeit mein grosser "Show-Stopper“ ist. !!



Im Anhang sind noch ein paar nützliche Links zu diesem Thema: 
http://www.html5rocks.com/en/tutorials/cors/#toc-introduction <http://www.html5rocks.com/en/tutorials/cors/#toc-introduction>
http://enable-cors.org/index.html <http://enable-cors.org/index.html>
http://www.w3.org/TR/cors/ <http://www.w3.org/TR/cors/>
http://www.gubatron.com/blog/2011/11/29/lighttpd-allow-access-control-allow-origin-headers-on-the-server-status-page/ <http://www.gubatron.com/blog/2011/11/29/lighttpd-allow-access-control-allow-origin-headers-on-the-server-status-page/>


VIELEN DANK für die HILFE


Gruss

Chris


-----------------------------------------

Chris Gross
Klotenerstrasse 31
CH - 8305 Dietlikon

E-Mail:		Chris.Gross at gmx.ch
Mobile:		+41 79 694 50 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.digitalstrom.org/pipermail/dss-developer/attachments/20150220/369ec71c/attachment.html>