2013-03-22 5 views
5

Um die SSL-Zertifikatsfehler zu ignorieren, setze ich ServicePointManager.ServerCertificateValidationCallback in eine statische Methode, bevor ich eine HttpWebRequest mache. Ich möchte nur, dass dies für interne Anforderungen getan wird, und so setze ich die Eigenschaft auf den Standardwert im Block finally zurück. Aber da es sich um eine Webanwendung handelt, gibt es Probleme, wenn mehrere Threads die Eigenschaft ändern?Ist es für mehrere Threads sicher, ServicePointManager.ServerCertificateValidationCallback festzulegen?

Hier ist, wie ich die Eigenschaft bin mit

public static String GetResource() 
{ 
    try 
    {   
     ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };   
    } 
    catch() 
    { 
    } 
    finally 
    { 
     ServicePointManager.ServerCertificateValidationCallback -= delegate { return false; }; 
    }  
} 
  1. Wird dieser Code THREAD sein? Die Dokumentation zu msdn besagt, dass alle statischen Member vom Typ ServicePointManager threadsafe sind, aber ich wollte nur bestätigen. http://msdn.microsoft.com/en-us/library/zkfa48de%28v=vs.80%29.aspx
  2. Der Code im finally-Block, ist das der richtige Weg, um es auf den Standardwert zurückzusetzen?
+1

, dies wird nicht "thread-safe". Der Rückruf kann jederzeit von einem anderen Thread geändert werden. –

+1

BTW, "Thread sicher" in Bezug auf statische Mitglieder bedeutet einfach, dass diese Mitglieder atomischen statischen Zustand (falls vorhanden) ändern. Zwei Threads, die 'ServerCertificateValidationCallback' modifizieren, sind in dieser Hinsicht" threadsicher ". Aus Sicht der Anwendung ist dies jedoch nicht threadsicher, da die Daten eines Threads (* sein * 'ServerCertificateValidationCallback'-Wert) von einem anderen Thread überschrieben werden können - was möglicherweise zu Fehlfunktionen des Codes in Ihrem Thread führt. Es gibt keine Möglichkeit, den Zugriff auf "ServerCertificateValidationCallback" in Threads zu synchronisieren, für die Sie keine Kontrolle haben. –

+0

Danke Peter für deine Antwort. Ich sehe viele Beiträge, in denen sie diese Technik vorgeschlagen haben, aber anscheinend funktioniert es nicht. Ich bin mir nicht sicher, wie SSL-Zertifikatfehler für interne Webanforderungen am besten ignoriert werden. – user1689030

Antwort

5

Wenn Sie die Standardzertifikatüberprüfung müssen außer Kraft zu setzen, sollten Sie eine oder mehrere der folgenden Optionen:

  1. Set einmal ServerCertificateValidationCallback und nur einmal - bei der Anwendung starten oder möglicherweise in einem statischen Konstruktor. Dies eliminiert das Risiko von Threadkonflikten.
  2. Da Sie machen Sicherheit zügige, begrenzen das Verhalten zu debuggen mit bedingter Kompilierung baut:

    #if DEBUG 
        ServicePointManager.ServerCertificateValidationCallback += Callback; 
    #endif 
    
  3. Schließlich erinnern, dass Ihre Stellvertretung eine reiche Funktion ist. Sie müssen nicht einfach true zurückgeben. Sie können die Anfrage abfragen und entscheiden, wie Sie damit umgehen. Keine

    ServicePointManager.ServerCertificateValidationCallback += Callback; 
    
    static bool Callback(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) 
    { 
        if (IsInternalRequest(sender)) 
        { 
         return true; 
        } 
        else 
        { 
         return IsExternalRequestValid(sender, certificate, chain, sslPolicyErrors); 
        } 
    } 
    
Verwandte Themen