Thanks, Corneliu. Didn't think of using an AppDomain to circumvent the static nature of the callback - good idea!
Thanks, Joe. On Tue, Dec 13, 2011 at 12:06 PM, Corneliu I. Tusnea <[email protected] > wrote: > Joseph, > > Firstly you should never (for production use) hook onto that method. It's > a stupid design from MS to even have that method available as a static for > the clear reasons you already identified (racing conditions mostly). > > The best way to "play nicely" is to start your plugin (or some part of it) > inside a new app domain. > The app domain will have its own ServicePointManager that you can hook > onto without worrying you mess up with the rest of the application. > Once done you can tear-down the app domain. If you need it for a longer > time just keep that AppDomain live until the end of the app pool. > > Corneliu. > > > > On Tue, Dec 6, 2011 at 3:27 PM, Joseph Clark <[email protected]> wrote: > >> Hello list! >> >> I have a requirement to relax SSL certification validation on certain web >> requests in my application. I know that I can do this by setting a custom >> delegate on the ServicePointManager.ServerCertificateValidationCallback >> property - which works fine. >> >> The problem I have is that I am not in full control of the host >> application - I am writing a plugin package that gets hosted in a 3rd party >> IIS application. Is there a way I can achieve what I'm after whilst still >> remaining a 'good citizen' in the host app? >> >> I have written the delegate so that it only performs my custom validation >> when it matches the request URI to the URI I expect (otherwise performing >> the default check), and I only register the callback for as long as I need >> it during the execution of a single method before setting it back to the >> original value. Even so, this is still vulnerable to race conditions if >> there is another request executing concurrently, and my code would be >> vulnerable to other code overriding the certificate validation callback in >> a similar manner. >> >> Any suggestions on how I can make this more robust? Examples and samples >> for this API on the Internet are mostly shocking, encouraging developers to >> just set the callback and return "true" (ie. no validation) with no >> discussion of the pitfalls this entails. >> >> Cheers, >> Joe. >> >> >> >> >> >> >> >> >> >> >> >
