Laden...

[gelöst] WCF antwortet nach einiger Zeit nicht mehr korrekt

Erstellt von Grumbler85 vor 13 Jahren Letzter Beitrag vor 13 Jahren 8.310 Views
G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren
[gelöst] WCF antwortet nach einiger Zeit nicht mehr korrekt

Hallo allerseits,

folgende Problematik tritt bei mir auf, die ich nicht zu lösen weiß ...

Es geht um einen WCF Service, der auf einem IIS gehostet wird.
Der IIS fordert HTTPS an und benötigt den Windowsanmeldenamen des Benutzers (nur zum Lesen der Daten).

Nach Programmstart funktioniert die Verbindung einwandfrei und ich kann operationen Ausführen.
Warte ich aber ca. 30 Sekunden (von Remote-PCs sogar nur 1 Sekunde), so bekomme ich folgende Fehlermeldung:

System.ServiceModel.Security.MessageSecurityException: Die HTTP-Anforderung ist beim Clientauthentifizierungsschema "Negotiate" nicht autorisiert. Vom Server wurde der Authentifizierungsheader "NTLM,Negotiate" empfangen. ---> System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.

folgendes ist in der ServiceModel-Config:


 <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="basicHttpEndpoint" closeTimeout="00:01:00" openTimeout="00:01:00"
                    receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
                    bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="6553600" maxBufferPoolSize="524288" maxReceivedMessageSize="6553600"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <security mode="Transport">
                        <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="https://..adresse../AppVSubscriptionService/SubscriptionService.svc"
                binding="basicHttpBinding" bindingConfiguration="basicHttpEndpoint"
                contract="SubscriptionServiceReference.ISubscriptionService"
                name="basicHttpEndpoint" />
        </client>
    </system.serviceModel>

Ein wechsel auf wsHTTPBinding führt zum gleichen Problem.

Für Ideen bin ich wie immer Dankbar
TG

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

I
1.739 Beiträge seit 2005
vor 13 Jahren

Ein normaler Timeout. Nach einem Timeout ist die Session abgelaufen bzw. Zustandslos bei einseitiger Betrachtung.
Zur Erneuerung/Restaurierierung einer abgelaufenen Session müssen diverse Daten neu übertragen werden.
Bedauerlicherweise weiss ich nicht mehr über dein User-Konzept... Die einfachste Lösung wäre eine Neuanmeldung vor jeder Aktion.

G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren

Die Benutzer gehören aller der Domäne an.

Ich habe aber auch versucht, den ServiceClient vor jedem Aufruf neu zu instantiieren, aber ich erhalte den gleichen Fehler.

Das Logging des IIS gibt mir aufschluss darüber, dass der Client beim ersten Anmelden versucht sich anonym zu authentifizieren (und dann ein 401 bekommt), dann aber automatisch auf Negotiate oder NTLM wechselt und die operation gelingt.

Bei weiteren Aufrufen dann wird die Negotiate/NTLM authentifizierung wieder versucht, führt aber zum obigen Fehler.

Wenn ich die Anmeldedaten von Hand festlegen kann (ohne sie dem Benutzer abzufragen oder sie zu kennen) kann ich selbiges auch gerne ausprobieren.

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren

Okay - ich habe eine Lösung:

Nutzt man


<security mode="TransportWithMessageCredential">
  <transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
  <message clientCredentialType="Windows" algorithmSuite="Default" />
</security>

In der Config, so wird alles gut und es kommt nicht mehr zu oben genanntem Verhalten.

Danke trotzdem für die Mithilfe

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren

Nachtrag:
Offensichtlich gibt es ein ernstzunehmendes Problem, wenn mehrere Verschiedene Netzwerkquellen benutzt werden, denn das unten beschriebene Problem trat wieder auf und war nur Lösbar indem Bilder, die per HTTP geladen wurden nicht per BitmapImage.UriSource (WPF) sondern per WebRequest geladen wurden.

Ansonsten kommt es aus unerfindlichen Gründen zu einer Fehlerhaften Authentifizierungsantwort vom Client, da selbiger einen NTLM Handshake nicht mehr korrekt ausführt. (Daten mit Fiddler erhoben)

Andere Authentifizierungsverfahren sind evtl. nicht davon betroffen

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)