Hi Peter, The primary driver for this flag is to support app deployments for development environments where the developers are building server-side applications (rather than mobile clients) and using self-signed SSL certificates. The vast majority of these engineers just aren't skilled in, nor tooled-up to implement *any* sort of iOS development, let alone to code and deploy a new authentication provider in a library wrapped in a library wrapped in an app.
At Alfresco, we received many requests for our "Alfresco Mobile" app to support this scenario. Whilst our app exposes this setting via user preferences, we were mindful that this is far from ideal from a security standpoint - but had to weigh that against strong commercial drivers. That's why this behaviour has been designed to be off by default and must very explicitly be switched on during session creation; something app developers can choose to not expose at all should they wish. I believe not having this feature available at all would severely limit the usefulness of any app built upon Objective-CMIS and, I fear, therefore similarly limit interest in the platform. Regards, Mike -- Mike Hatfield Lead Engineer, Mobile Apps Alfresco Software, Inc. On 17 May 2013, at 13:54, "Eberlein, Peter" <[email protected]> wrote: > Hi Peter, > > I noticed the new session parameter, > kCMISSessionAllowUntrustedSSLCertificate, that you introduced. If set, server > certificate validation is skipped so SSL connections to untrusted servers can > be established. > > I don't think that we should have such a parameter. The world is already > insecure enough without encouraging people to deactivate essential security > settings. If there is a need to accept untrusted server certificates > temporarily, like during development, than this can easily be done by > providing a custom authentication provider. This was already possible before > this change, without extending the standard implementation with insecure > code. Or did I miss something? I would feel a lot better if this whole > "feature" was removed again and whoever needs to do such messy things does > them in own code in a custom authentication provider. > > Or is it just me who is overly sensitive here? What does everyone else think? > > Peter > >
