Open mikejohnstn opened 10 years ago
Ref Issue #237
Just a thought: Rather than requiring to subclass SPAuthenticationViewController
, you could introduce a protocol that includes authenticator
and signingIn
as required properties and to which any custom authentication view controller must conform to. So, basically the authentication view controller type would be something like UIViewController<SPAuthenticationUISupport>
. A quick look at the code didn't reveal any further dependencies to SPAuthenticationViewController
other than the two properties mentioned above.
This would allow to "start fresh", and thus also eliminate the risk of having weird and hard-to-debug side-effects caused by some superclass method (after all, SPAuthenticationViewController
is quite a heavy view controller and does not seem to be specifically designed for safe subclassing).
I agree, we should decouple the backend interaction from the SPAuthenticationViewController class, and offer a mechanism to implement authentication by means of a protocol. That would allow 3rd party apps to implement auth in (any imaginable) way.
Perhaps that could even allow you to tap into the new TouchID API, and feed the fingerprint-token as the user password.
Thanks for your suggestion @danielr!
From https://github.com/Simperium/simperium-ios/issues/156#issuecomment-27471291