2017-03-02 23 views
6

Przeczytałem większość tematów dotyczących błędów w wielu domenach i nadal nie mogę uzyskać ich działania. Na stronie ładuję moduł Silverlight, który komunikuje się z usługą WCF Webservice. Na localhost, działa dobrze, nie wystąpił błąd.

mam Webservice hostowane na http://localhost:50283 iw tym samym folderze, który odnosi się do portu 50283 Mam clientaccesspolicy.xml położony który wygląda następującoBłąd międzydomenowy Silverlight + WCF

<access-policy> 
    <cross-domain-access> 
    <policy> 
     <allow-from http-request-headers="*"> 
     <domain uri="*"/> 
     </allow-from> 
     <grant-to> 
     <resource path="/" include-subpaths="true"/> 
     </grant-to> 
    </policy> 
    </cross-domain-access> 
</access-policy> 

umieściłem clientaccesspolicy.xml prawie wszędzie, ale w tym, że \ wwwroot i tak nie przyniosło to efektu. Mogę uzyskać dostęp do clientaccesspolicy.xml zarówno na komputerze lokalnym, jak i na innym komputerze w tej samej sieci (http://computerIP:50283/clientaccesspolicy.xml wyświetla zawartość).
Próbowałem przechwycić błąd, aby dowiedzieć się więcej szczegółów na temat natury błędu, ale skrzypek nie rejestruje żadnych błędów, tylko przeglądarka robi. Dosłownie próbowałem wszystkiego i wciąż nie zmieniłem. Czy ktoś miał podobny problem i mógł podać wskazówki, w których powinienem szukać rozwiązania?

wpadłem na podobny temat bez rozwiązania, a także, niestety
Silverlight-to-WCF cross-domain exception, but clientaccesspolicy.xml is being read successfully

+0

Tylko do rozwiązywania problemów zmień 'http-request-headers' na' http-request-headers = "*" ', aby upewnić się, że żądania mogą przejść, ale jest dozwolona, ​​a następnie pracuj wstecz, dodając ograniczenia. Jeśli przy wszystkich dozwolonych nagłówkach nadal nie przechodzi, problem jest gdzie indziej. może ustawienie ściany ogniowej? – Nkosi

Odpowiedz

1

Nie wiem, czy to ma coś zrobić z nim, ale mam podobną konfigurację i mój clientaccesspolicy.xml wygląda nieco inaczej.

<?xml version="1.0" encoding="utf-8" ?> 
<access-policy> 
    <cross-domain-access> 
    <policy> 
     <allow-from http-request-headers="SOAPAction"> 
     <domain uri="http://*"/> 
     <domain uri="https://*" /> 
     </allow-from> 
     <grant-to> 
     <resource include-subpaths="true" path="/"/> 
     </grant-to> 
    </policy> 
    </cross-domain-access> 
</access-policy> 

Szczególnie podział adresów http i https jest inny. Poza tym, że próbujesz to zrobić z portem innym niż domyślny, czy próbowałeś go na domyślnym porcie 80? och i na środowisku produkcyjnym te * są zamieniane na rzeczywistą nazwę domeny.

3

Pamiętam, że wpadłem na to wiele lat temu i rozwiązałem go nieco inaczej, a mianowicie zachowaniem. Rozważmy następujący:

using System; 
using System.IO; 
using System.ServiceModel; 
using System.ServiceModel.Channels; 
using System.ServiceModel.Configuration; 
using System.ServiceModel.Description; 
using System.Xml; 

internal class CrossDomainServiceBehavior : BehaviorExtensionElement, IEndpointBehavior 
{ 
    private ServiceHost serviceHost; 

    public override Type BehaviorType 
    { 
     get { return typeof(CrossDomainServiceBehavior); } 
    } 

    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) 
    { 
     if (serviceHost == null) 
     { 
      serviceHost = new ServiceHost(typeof(CrossDomainPolicyService)); 

      string address = new Uri(endpoint.Address.Uri, "/").ToString(); 
      ServiceEndpoint crossDomainEndpoint = serviceHost.AddServiceEndpoint(typeof(ICrossDomainPolicyService), new WebHttpBinding(), address); 
      crossDomainEndpoint.Behaviors.Add(new WebHttpBehavior()); 

      serviceHost.Open(); 
     } 
    } 

    public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime) 
    { 
    } 

    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher) 
    { 
    } 

    public void Validate(ServiceEndpoint endpoint) 
    { 
    } 

    protected override object CreateBehavior() 
    { 
     return new CrossDomainServiceBehavior(); 
    } 
} 

internal class CrossDomainPolicyService : ICrossDomainPolicyService 
{ 
    public Message ProvideClientAccessPolicyFile() 
    { 
     XmlReader xmlReader = CreateClientAccessXml(); 
     return Message.CreateMessage(MessageVersion.None, string.Empty, xmlReader); 
    } 

    public Message ProvideCrossDomainPolicyFile() 
    { 
     XmlReader xmlReader = CreateCrossDomainXml(); 
     return Message.CreateMessage(MessageVersion.None, string.Empty, xmlReader); 
    } 

    private static XmlReader CreateClientAccessXml() 
    { 
     TextReader reader = new StringReader(@"<?xml version='1.0' encoding='utf-8'?> 
                <access-policy> 
                <cross-domain-access> 
                 <policy> 
                 <allow-from http-request-headers='*' > 
                 <domain uri='*'/> 
                 </allow-from> 
                 <grant-to> 
                  <resource path='/' include-subpaths='true'/> 
                 </grant-to> 
                 </policy> 
                </cross-domain-access> 
                </access-policy>"); 
     return XmlReader.Create(reader); 
    } 

    private static XmlReader CreateCrossDomainXml() 
    { 
     TextReader reader = new StringReader(@"<?xml version='1.0'?> 
                <cross-domain-policy> 
                <allow-http-request-headers-from domain='*' headers='*'/> 
                </cross-domain-policy>"); 
     return XmlReader.Create(reader); 
    } 
} 

CrossDomainServiceBehavior musi zostać dodany do zachowań na usługi WCF i używa CrossDomainPolicyService dynamicznie dodając przekrój politykę domeny. Zapobiega to konieczności dodawania pliku Cross Domain do samej witryny.

Dodawanie zachowania z kodem (na przykład z siebie hostowane usługi):

endPoint.Behaviors.Add(new CrossDomainServiceBehavior()); 

lub w przypadku definicji WCF w config: W trosce o tym przykładzie zakładam CrossDomainServiceBehavior jest w przestrzeni nazw Services.CrossDomainServiceBehavior i zespół, w którym się znajduje, to wersja 1.0.0.0 o neutralnej kulturze. Zakłada również, że masz powiązanie z deklaracją usługi o nazwie webHttp.

Rejestrowanie zachowanie:

<system.serviceModel> 
    <extensions> 
    <behaviorExtensions> 
     <add name="CrossDomainServiceBehavior" type="Services.CrossDomainServiceBehavior, CrossDomainServiceBehavior.AssemblyName, Version=1.0.0.0, Culture=neutral" /> 
    </behaviorExtensions> 
    </extensions> 

stwierdzenie zachowanie:

<behaviors> 
    <endpointBehaviors> 
    <behavior name="CrossDomainServiceBehavior"> 
     <webHttp/> 
     <CrossDomainServiceBehavior/> 
    </behavior> 
    </endpointBehaviors> 
<behaviors> 

dodać zachowanie do wiązania (tu jako przykład jednej nazwie webHttp):

<bindings> 
    <webHttpBinding> 
     <binding name="webHttp" 
     maxReceivedMessageSize="20000000" > 
      <security mode="None"> 
       <transport clientCredentialType = "None"/> 
      </security> 
     </binding> 
     <CrossDomainServiceBehavior /> 
    </webHttpBinding> 
</bindings> 

Wreszcie, dodaj zachowanie do punktu końcowego usługi, tutaj w przykładzie pierwszym, który implementuje ISomeService:

<endpoint address="" binding="webHttpBinding" contract="Services.ISomeService" bindingConfiguration="webHttp" behaviorConfiguration="CrossDomainServiceBehavior "/> 
Powiązane problemy