Hi, sorry for my n00bish. I like the idea of libraries to make
developer's life easier, I just have few questions.
Is possible to have both into AGAuthenticationModuleAdapter?
NSURLCredential for developers pretty familiar with it (and wants full
control) and HTTPBasicDigestAuthenticationModule for developer who want
to keep it simple?
Another question? Why not HTTPAuthenticationModule? With the addition of
more auth schemes you will end with something like
HTTPBasicDigestHawkPersonaOAuth2AuthenticationModule.
Corinne Krych wrote:
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
<mailto:matzew@apache.org>> wrote:
On Wed, May 29, 2013 at 10:20 AM, Christos Vasilakis
<cvasilak(a)gmail.com <mailto:cvasilak@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/Reference/Fo...
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...;,
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.digest.au...
For testing purposes, another branch
<
https://github.com/cvasilak/aerogear-ios/tree/basic.digest.nsurlcredentia... was
created, this time letting the user to directly pass
<
https://github.com/cvasilak/aerogear-ios-integration/blob/basic.digest.ns...
an
NSURLCredential
<
http://developer.apple.com/library/ios/#Documentation/Cocoa/Reference/Fou...
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.digest.ns...
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-...>)
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-...
approach
instead of providing the NSURLCredential
<
http://developer.apple.com/library/ios/#Documentation/Cocoa/Reference/Fou...
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 <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev