Kann mir mal jemand bitte einen Tip geben, warum das Script nach der
markierten Stelle einfach nix mehr tut? Die enthaltenen Zugangsdaten
sind echt, aber kein Problem, es ist ein Testsystem. Danke für Hilfe!
Der letzte Parameter bei request.open() ist mit Absicht "false", d.h.
das Script wartet, bis ein Ergebnis kommt (synchron), ansonsten rauscht
es dort einfach durch (asynchron), aber Ergebnisse kommen dann auch
keine ... nichtmal eine Fehlermeldung. Damit ist der Server ansonsten
sehr freigiebig
3.14 schrieb:> Gibt es irgendeine Meldung in der Entwicklerkonsole?
guter Hinweis, hatte ich übersehen:
"Quellübergreifende (Cross-Origin) Anfrage blockiert: Die
Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf
https://public-ws.dpd.com/services/LoginService/V2_0/?wsdl. (Grund:
CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt)."
Habe das File auf dem Desktop liegen und nicht in einem Server. Brrrr
Frank E. schrieb:> 3.14 schrieb:> Gibt es irgendeine Meldung in der Entwicklerkonsole?>> guter Hinweis, hatte ich übersehen:>> "Quellübergreifende (Cross-Origin) Anfrage blockiert: Die> Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf> https://public-ws.dpd.com/services/LoginService/V2_0/?wsdl. (Grund:> CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt).">> Habe das File auf dem Desktop liegen und nicht in einem Server. Brrrr
Setz dir ein Apache auf (Standardkonfiguration) und mach deine Projekte
darin. Aber sei vorsichtig, dass keine Portfreigaben eingerichtet sind.
Das Problem wird aber bleiben. Um es zu beheben, hast du die Möglichkeit
a) den Serverdienst auf den eigenen Server verfrachten (evtl. PHP oä
installieren)
b) JSONP verwenden (ist viel einfacher, als es klingt)
So Passwort geändert ... ist aber m.E: unkritisch, weil eh nur Sandbox.
Aber: Ich habe das Script jetzt in den Apache meiner Synology versetzt,
anstatt direkt als File zu öffen. Es "klemmt " aber immer noch an der
gleichen Stelle.
Ursprünglich dachte ich ja an ein Rechte-Problem: Von wegen File und
aktive Inhalte - Browser haben da sehr eigene Ansichten - ist aber
nicht. Bis zum ersten Alert wird es ausgeführt und dann ist Ende. Auch
kein Timeout, es sei denn, dieses ist 20min lang ... Mist.
Ich habe mich jetzt nochmal zum Thema CORS belesen - "tolle" Erfindung.
Das heisst am Ende, ich kann keinen XMLHttpRequest auf eine Domäne
machen, in der nicht auch mein eigenes Script liegt. Das ist echt super
z.B. für die Kontaktaufnahme zu einem Paketdient ...
Damit ist dieser Versuch wohl erledigt.
Frank E. schrieb:> Ich habe mich jetzt nochmal zum Thema CORS belesen - "tolle"> Erfindung.>> Das heisst am Ende, ich kann keinen XMLHttpRequest auf eine Domäne> machen, in der nicht auch mein eigenes Script liegt. Das ist echt super> z.B. für die Kontaktaufnahme zu einem Paketdient ...>> Damit ist dieser Versuch wohl erledigt.
Das hat ja auch seinen Grund. Aus Sicherheitstechnicher Sicht wäre dies
ein absoluter Super-Gau. Und wie bereits erwähnt kann man dies
"freischalten" auf dem Server. Dies macht man aber auch nur für bekannte
IPs.
Wenn der Paketdienst eine "Kontaktaufnahme" wünscht. Dann stellt er auch
eine Möglichkeit dazu bereit (JSON, XML File, UDP Req,...).
Wie wäre es in diesem Fall, wenn du einfach mal den Paketdienst fragst
welche Möglichkeiten er bietet die nötigen Informationen zu bekommen?
Hier eine API von DPD:
https://www.shippypro.com/dpd-API.html
Wie man sieht ist diese nicht kostenfrei, deswegen wird es auch keine
kostenfreie Schnittstelle nach außen geben. ?
Hallo Frank,
lad Dir mal SoapUI runter und trag dort Deine Daten so ein wie Du sie
sendest, dann kannst Du relativ genau sehen was passiert.
Gruß
Frank
Hallo Frank,
ich habe das mal eben durchlaufen lassen. Da Deine Passwort natürlich
geändert wurde erhalte ich keine Antwort bzw. ein "Fault occured". Der
Service antwortet also.
Im Anhang mal das Ergebnis aus SoapUI.
Gruß
Frank
Frank E. schrieb:> Ich habe mich jetzt nochmal zum Thema CORS belesen - "tolle" Erfindung.>> Das heisst am Ende, ich kann keinen XMLHttpRequest auf eine Domäne> machen, in der nicht auch mein eigenes Script liegt. Das ist echt super> z.B. für die Kontaktaufnahme zu einem Paketdient ...>> Damit ist dieser Versuch wohl erledigt.
Google mal nach "CORS-Proxies". Statt per XMLHttpRequest direkt auf die
gewünschte Resource zuzugreifen, schickt man seinen Request stattdessen
an den CORS-Proxy, teilt ihm mit, auf welche URL man eigentlich
zugreifen möchte, und bekommt dann vom Proxy die gewünschte Ressource
zurückgeliefert, aber mit passendem "Access-Control-Allow-Origin
*"-CORS-Header.
Und schwupps, schon hat man das völlig schwachsinnige Sicherheitskonzept
hinter CORS einfach ad absurdum geführt.
CORS-Liebhaber schrieb:> Und schwupps, schon hat man das völlig schwachsinnige Sicherheitskonzept> hinter CORS einfach ad absurdum geführt.
No, hat man nicht. Der sinn von cors ist es unter anderem, dass eine
seite nicht einfach so im nahmen eines anderen anhand seiner session
genutzt werden kann. Ein cors proxy hat einen anderen origin, und damit
nicht die selben session cookies. Natürlich muss das mit techniken wie
stp kombiniert werden, um effektiv zu sein. Ein anderer Aspekt ist, dass
dank CORS webbrowser nicht als proxies misbraucht werden können.