Dieses Problem, das ich habe, tritt nicht bei allen Clients auf, die auf unsere Dienste zugreifen, aber was konsistent ist, ist, dass wenn der Fehler auftritt, dies bei ein und demselben Serviceaufruf für eine Handvoll Clients geschieht / p>
Hier sind die Details der Ausnahme:
System.ServiceModel.Security.MessageSecurityException Die HTTP-Anforderung war mit Client-Authentifizierungsschema "Anonymous" verboten. System.ServiceModel.Security.MessageSecurityException: Das HTTP Anfrage wurde mit Client-Authentifizierungsschema 'Anonym' verboten. & gt; --- & gt; System.Net.WebException: Der Remote-Server hat einen Fehler zurückgegeben: (403) Verboten. bei System.Net.HttpWebRequest.GetResponse () um System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply (TimeSpan Timeout) --- Ende der inneren Ausnahme Stack-Trace --- Server Stapelverfolgung: um System.ServiceModel.Security.IssuanceTokenProviderBase
1.DoNegotiation(TimeSpan timeout) at System.ServiceModel.Security.SspiNegotiationTokenProvider.OnOpen(TimeSpan timeout) at System.ServiceModel.Security.TlsnegoTokenProvider.OnOpen(TimeSpan timeout) at System.ServiceModel.Security.WrapperSecurityCommunicationObject.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Security.CommunicationObjectSecurityTokenProvider.Open(TimeSpan timeout) at System.ServiceModel.Security.SecurityUtils.OpenTokenProviderIfRequired(SecurityTokenProvider tokenProvider, TimeSpan timeout) at System.ServiceModel.Security.SymmetricSecurityProtocol.OnOpen(TimeSpan timeout) at System.ServiceModel.Security.WrapperSecurityCommunicationObject.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Channels.SecurityChannelFactory1.ClientSecurityChannel1.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout) at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout) at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout) at System.ServiceModel.Security.SecuritySessionClientSettings1.ClientSecuritySessionChannel.OnOpen (TimeSpan Timeout) um System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannel.OnOpen (TimeSpan-Timeout)
bei System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call (ServiceChannel Kanal, TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce (TimeSpan Timeout, CallOnceManager-Kaskade) um System.ServiceModel.Channels.ServiceChannel.EnsureOpened (TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannel.Call (String-Aktion, Boolean oneway, ProxyOperationRuntime-Operation, Object [] ins, Objekt [] outs, TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannel.Call (String-Aktion, Boolean oneway, ProxyOperationRuntime-Operation, Object [] ins, Objekt [] outs) bei System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (IMethodCallMessage MethodeCall, ProxyOperationRuntime Operation) um System.ServiceModel.Channels.ServiceChannelProxy.Invoke (IMessage Meldung) Ausnahme bei [0] erneut ausgelöst: um System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg) bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & amp; msgData, Int32-Typ) um & gt; Proxy.FileTransferService.IFileTransferService.EstablishProxy (DownloadRequest Anfrage) bei Proxy.FileTransferService.FileTransferServiceClient. Proxy.FileTransferService.IFileTransferService.EstablishProxy (DownloadRequest Anfrage) bei NormalFileTransferServiceClient.Download (Int32 packageId, IStreamWriter Downloader, Archiver Archiver) bei LoggingFileTransferServiceClient.Download (Int32 packageId, ISt
Diese Ausnahme wird vom Client ausgelöst.
Die Client-Proxy-Konfiguration für IFileTransferService lautet:
%Vor%Die Servicekonfiguration ist
%Vor%Hinweis: Einige Clients verwenden das basicHttpBinding (wenn ich alles richtig eingerichtet habe). In späteren Versionen des Clients, die möglicherweise noch nicht vollständig verteilt wurden (weshalb ich 2 Versionen unterstützen muss), habe ich den Proxy so geändert, dass er stattdessen den wsHttpBinding-Endpunkt verwendet. Ich frage mich, ob dieser Fehler, den ich bekomme, spezifisch für basicHttp ist und wenn ja, vielleicht habe ich diese Konfigurationen nicht richtig eingerichtet. Ich gehe davon aus, dass die Clients, die diesen 403-Fehler erhalten, das wsHttpBinding verwenden.
Hier ist der Code für den Service:
%Vor%Weiß jemand, ob das, was diese Ausnahme loslässt, etwas mit meiner Kontrolle ist? Gibt es Konfigurationsänderungen, die ich in den Client- oder Dienstkonfigurationsdateien vornehmen kann?
Wenn Sie weitere Informationen von mir brauchen, lassen Sie es mich wissen.
In meinem Fall stammt dieser Fehler vom HTTP-Proxy-Server unserer Organisation . Gefunden von:
MessageSecurityException.InnerException.Response.Headers :
{Mime-Version: 1.0
X-Squid-Fehler: ERR_ACCESS_DENIED 0
X-Cache: MISS von & lt;
X-Cache-Lookup: KEINE von & lt; Proxy-Server-Adresse & gt;
Proxy-Verbindung: schließen
Inhaltslänge: 2165
Inhaltstyp: text / html
Datum: Mi, 25 Apr 2012 10:55:39 GMT
Server: Tintenfisch / 3.0.STABLE25
Via: 1.0 & lt; Proxy-Server-Adresse & gt; (squid / 3.0.STABLE25)
}
In meinem Fall ist es auch bei einer Dateiübertragungsmethode passiert, die Dateibrocken in einem byte -Array der Größe 16384 überträgt. Beim Reduzieren der Größe auf 10000 wurde der Fehler behoben. Dies bedeutet, dass der Proxy-Server eine bestimmte Größenbeschränkung hat.
Auf einem Computer mit direktem Internetzugang ist die Dateiübertragungsmethode mit diesem Fehler nicht fehlgeschlagen, selbst für die Array-Größe & gt; 16384.
Da nur einige Ihrer Clients mit diesem Problem konfrontiert sind, befinden sie sich möglicherweise hinter einem Firewall / Proxy-Server, der den Zugriff tatsächlich blockiert und diesen Fehler zurückgibt?
Es klingt für mich so, als würden die Clients, die MessageSecurityException erhalten, keinen gültigen Benutzernamen / Passwort mit ihrer Anfrage angeben.
Siehe das folgende msdn-Thema Ссылка
Sie haben also einen Web-Service in IIS mit anonymer Authentifizierung konfiguriert, und Sie erhalten einen 403 verbotenen Fehler für nur eine Handvoll Benutzer.
Aus meiner eigenen Erfahrung wird dies normalerweise durch eine Zugriffsverweigerungs-Ausnahme verursacht, wenn auf eine ACL-gesteuerte Systemressource wie das Dateisystem zugegriffen wird.
Jeder Benutzer, der anomal verbunden ist, bearbeitet seine Anfrage (unter der Annahme von IIS 7) durch den w3wp.exe-Prozess, der normalerweise die Anwendungspoolidentität (IIS APPPOOL / AppPoolName) hat, wenn diese Identität keiner der erforderlichen Zugriffssteuerungslisten hinzugefügt wird Zugriff verweigert-Ausnahme wird IIS mit einem 403-Fehler antworten.
Normalerweise füge ich die Identität des Anwendungspools zu einer Gruppe hinzu und füge die Gruppe dann zu den erforderlichen Ressourcen hinzu.
Wenn Sie nicht herausfinden können, welche Ressourcen die Ausnahmebedingung verursachen könnten, suchen Sie im Sicherheitsereignisprotokoll nach "Audit Failure" -Einträgen nach Hinweisen. Möglicherweise müssen Sie die lokale Sicherheitsrichtlinie zum Protokollieren von Sicherheitsereignissen konfigurieren.
viel Glück