Ich weiß, dass es da draußen viele Fragen gibt - glauben Sie mir, ich habe viele davon gelesen und die Antworten ausprobiert.
(Dieses Projekt ist für ein internes Firmen-LAN, nicht für das Internet)
Wir haben einen WCF-Webservice, der RESTFUL ist und JSON sendet / empfängt, er benötigt NTLM (Curb wäre auch gut) auth / credentials, um sicherzustellen, dass der anrufende Benutzer (aus dem Browser, wer sie sind, sagt) wird zwischen dem Browser / Client und dem Dienst von den WCF-Bindungen ausgehandelt:
%Vor%Mit Fiddler kann ich die Methoden auf dem Dienst GET und POST erfolgreich aufrufen und vorausgesetzt ich passe den JSON an, den wir an den Webservice senden (um zum Beispiel die Sitzungs-ID aufzunehmen), gleitet er fröhlich weiter.
Die Probleme begannen, als wir versuchten, den Webservice mit JavaScript / jQuery aufzurufen. Die Idee ist, dass ein Webserver den HTML / JS an den Client-Browser liefert, der Browser sollte dann den WCF-Webservice aufrufen, um eine Sitzung zu erhalten, und einem Benutzer erlauben, ein paar Aktionen durchzuführen (wir haben insgesamt 3 Methoden). p>
Zuerst haben wir das X-Domain-Problem kennengelernt, das wir zu lösen versucht haben, indem wir den Webserver dazu gebracht haben, die richtigen Header zurückzugeben (Access-Control-Allow-Origin). Das hat Browser wie SRIron nicht daran gehindert, uns das zu sagen;
%Vor%Danach habe ich die Möglichkeit untersucht, Silverlight zu verwenden (scheint NTLM auth nicht über WebHttpBinding zu unterstützen), reverse proxy ist out, da der in dev verwendete IIS-Server nicht in prod (I glauben es ist WebSphere, aber nicht unter unserer Kontrolle); Als nächstes habe ich mir folgendes angesehen:
Was mich zu dem Eindruck brachte, dass der WCF-Webservice eigentlich die Sache war, die dem Browser mitteilen musste, von wo aus er angerufen werden durfte (wenn das sinnvoll ist). Nachdem ich den gesamten Code aus dem Beispiel implementiert hatte, stellte ich fest, dass das ApplyClientBehavior nie aufgerufen wurde, um die Header an den Client zurückzugeben (dies wird auch in Fiddler überwacht). Etwas mehr Googeln führte mich zu:
Da wir mit jQuery und nicht mit irgendeinem .NET-Client / Service-Verweis / proxy / app ... auf den Web-Service zugreifen, denke ich, dass es nicht möglich ist, diese Header vorab anzufordern, um den Zugriff darauf zu ermöglichen der Service. Außerdem scheint Fiddler zu denken, dass es eine Unautorisierte erhält, wenn es versucht, die Methode Ссылка aufzurufen.
Hier ist die jQuery, die ich benutze, um zu versuchen, den Anruf zu tätigen (ich habe ein paar Einstellungen in der Hoffnung geliefert, dass es funktionieren würde):
%Vor%Ok, wenn jemand hilfreiche Tipps oder Ideen hat, bitte wegzünden. Ich werde antworten und bearbeiten usw., um sicherzustellen, dass dies auf dem neuesten Stand gehalten wird, ich hoffe, ich habe nichts verpasst (aber meine Köpfe drehen sich ein wenig von meinem Googeln).
Ich weiß auch, dass es bessere Möglichkeiten gibt, dies zu tun, aber ich würde es am saubersten / schnellsten Weg von meinem jetzigen Standort aus tun - dh nicht viele Code-Änderungen, Neuschreibungen usw. kann ich post up configs auch, wenn Leute denken, dass sie wirklich nützlich sind.
Am Ende musste ich irgendwie herumarbeiten, wir haben die Verantwortlichen des Webservers dazu gebracht, einem IFrame zuzustimmen, der auf unsere von IIS gehostete Seite zeigt (diejenige mit dem JS etc.)
Dann nutzen wir die Magie von WCF / Windows und hosten die WCF-Dienste auf Port 80, die den Ursprung der X-Domain umgehen. So kann ich dann REST / JSON haben, ohne JSONP verwenden zu müssen.
Ich weiß, dass es nicht die Antwort auf die Frage ist, die die Kriterien erfüllt, die ich angegeben habe, aber ich denke, dass mir die Optionen am Ende völlig ausgingen.
Tags und Links wcf jquery json authentication rest