Thanks for the clarification.
I think I didn't get it.
Indeed it should be well documented as you would expect a login action (ie
doing an actual login on endpoint) when sending a login message.
saveLoginCredentials would be the correct message but I guess we rather
stick to AGAuthenticationModuleAdapter protocol.
+1
Corinne
On 29 May 2013 11:13, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Wed, May 29, 2013 at 10:20 AM, Christos Vasilakis <cvasilak(a)gmail.com>wrote:
> Hi,
>
> iOS platform provides built-in implementations for authenticating against
> HTTP endpoints that support Basic / Digest authentication (among others).
> The workflow when iOS tries to authenticate against those endpoints is
> basically:
>
> a) A credential storage singleton
object<https://developer.apple.com/library/mac/#documentation/Cocoa/Re...
provided
> by the system is consulted for authentication credentials. If credentials
> are found, the system proceeds with authentication. Understandably for this
> to work, the developer has to initially push the credentials to the system
> object (and remove when done).
>
> b) If credentials are NOT found, the system tries to call the delegate
> method e.g.
'connection:didReceiveAuthenticationChallenge<http://developer.apple.com/library/mac/documentation/Foundation/Reference/NSURLConnectionDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intfm/NSURLConnectionDelegate/connection:didReceiveAuthenticationChallenge:>',
> giving a chance for the user to provide the credentials, by calling the
> appropriate methods on the authentication challenge object passed in.
>
> AeroGear library, currently has a notion of pluggable authentication
> modules providing an interface for clients to implement 'login', and
> 'logout' methods, depending on the authentication scenarios that they try
> to support. This fits nicely with singleton credential storage approach, in
> the sense when doing 'login' and 'logout', we simply edit the
credential
> storage adding or removing credentials appropriately. A branch for this
> work can be found
here<https://github.com/cvasilak/aerogear-ios/tree/basic.digest.auth>.
> For usage, have a look at our integration
test<https://github.com/cvasilak/aerogear-ios-integration/blob/basic.d...
>
> For testing purposes, another
branch<https://github.com/cvasilak/aerogear-ios/tree/basic.digest.nsur...
was
> created, this time letting the user to directly
pass<https://github.com/cvasilak/aerogear-ios-integration/blob/basic.d...
> an
NSURLCredential<http://developer.apple.com/library/ios/#Documentation/...
object
> initialised with the username/password combination during the Pipe
> configuration. Those credentials are internally stored and given back to
> the system by implementing the necessary callback
<
https://github.com/cvasilak/aerogear-ios/blob/basic.digest.nsurlcredentia...;.
> A usage example can be found in our integration
test<https://github.com/cvasilak/aerogear-ios-integration/blob/basic.d...
>
> advantages of using the singleton approach:
> - fits nicely with the authentication mechanism we have in place (as an
> extension
HTTPBasicDigestAuthenticationModule<https://github.com/cvasilak/aerogear-ios/blob/basic.digest.auth/AeroGear-iOS/AeroGear-iOS/security/AGHttpBasicDigestAuthentication.m>)
> so user familiarity when looking to add basic/digest support to the Pipe.
> - we control the credential type e.g.
> 'NSURLCredentialPersistenceForSession'. This eliminates errors of using
> 'NSURLCredentialPersistencePermanent' and having the user to explicitly
> clear the keychain when trying to login with a different combination. For
> my search, many errors occurs because of this.
>
> disadvantages of using the singleton approach:
> - not sure if many iOS dev will like the fact of creating an
> Authenticator object instead of using directly an NSURLCredential object
> that are used to.
>
> ---
> advantages of using the 'nsurlcredential' directly:
> - users familiarity with the object.
> - not explicit login logout request.
>
> disadvantages of using the 'nsurlcredential' directly:
> - error credential type can lead to errors.
>
> With discussions with Matthias, we are more keen in following the
>
HTTPBasicDigestAuthenticationModule<https://github.com/cvasilak/aerogear-ios/blob/basic.digest.auth/AeroGear-iOS/AeroGear-iOS/security/AGHttpBasicDigestAuthentication.m>
approach
> instead of providing the
NSURLCredential<http://developer.apple.com/library/ios/#Documentation/...
configuration
> option on the Pipe. Surely enough, in the documentation we will explicitly
> state that "login"/ "logout" methods, serve as a mean to setup
internally
> the iOS authentication system so users don't have too (instead of calling
> remote endpoints)
>
While the "NSURLCredential" better fits the meanings of BASIC/DIGEST (no
explicit login/logout against a server), however that will cause all sorts
of issues, since the APP_DEVELOPER is reponsible for providing
the NSURLCredential; If we uses a _permanent_ storage, all sorts of errors
may occur (like Christos was already indicating).
I (currently) like the "auth_module" approach better. However, as Christos
mentioned, we need to state (in API docs) that login/logout is JUST
applying/removing the credentials. The doc needs to say that on LOGIN (for
instance) no request is hit against the server.
-Matthias
>
> Wdyt?
>
> Thanks,
> Christos
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev