[aerogear-dev] iOS Basic/Digest Thoughts

Matthias Wessendorf matzew at apache.org
Mon Jun 3 09:32:13 EDT 2013


On Mon, Jun 3, 2013 at 3:22 PM, Christos Vasilakis <cvasilak at gmail.com>wrote:

> Hi
>
> I guess we can have both approaches
>

Not sure if we would mix a bit too much here



> too and document the fact that care should be taken for the persistent
> type.
>
> Further, another possible option allowing more more full control, is to
> expose as an option the underlying block that iOS provides so users can
> feed their own block.  It is similar to the approach the underlying
> afnetworking library does for users to configure<https://github.com/AFNetworking/AFNetworking/blob/master/AFNetworking/AFURLConnectionOperation.h#L320> if
> they wish too.
>
> In essence, something similar to:
>
>  id <AGPipe> pipe = [_pipeline pipe:^(id <AGPipeConfig> config) {
>         [config setName:@"autobots"];
>         // correct credentials
>         [config setAuthenticationChallengeBlock:^(NSURLConnection *connection, NSURLAuthenticationChallenge *challenge) {
>                 // create the credentials and server them to the challenge request
>     }];
>
>
> Wdyt?
>

Not sure on that as well. Right now we configure initial state/params. Not
sure we should really do extend the config to also accept
"blocks/functions" to react on behaviour. Hrm...








> Christos
>
>
> On May 29, 2013, at 1:27 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> On Wed, May 29, 2013 at 12:18 PM, Bruno Oliveira <bruno at abstractj.org>wrote:
>
>> 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?
>>
>
> Interesting point. Let me think about it
>
>
>
>>
>> Another question? Why not HTTPAuthenticationModule? With the addition of
>> more auth schemes you will end with something like
>> HTTPBasicDigestHawkPersonaOAuth2AuthenticationModule.
>>
>
>
> oh, right :) yeah, let's name it AGHTTPAuthenticationModule.h/m. Good
> point
>
>
>>
>>
>>
>> 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 at apache.org
>> > <mailto:matzew at apache.org>> wrote:
>> >
>> >
>> >
>> >
>> >     On Wed, May 29, 2013 at 10:20 AM, Christos Vasilakis
>> >     <cvasilak at gmail.com <mailto:cvasilak at 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/Foundation/Classes/NSURLCredentialStorage_Class/Reference/Reference.html>
>> 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.digest.auth/AeroGear-iOS-Integration/AeroGear-iOS-IntegrationTests/AGHttpBasicAuthenticationTests.m
>> >
>> >
>> >         For testing purposes, another branch
>> >         <
>> https://github.com/cvasilak/aerogear-ios/tree/basic.digest.nsurlcredential>
>> was
>> >         created, this time letting the user to directly pass
>> >         <
>> https://github.com/cvasilak/aerogear-ios-integration/blob/basic.digest.nsurlcredential/AeroGear-iOS-Integration/AeroGear-iOS-IntegrationTests/AGHttpBasicAuthenticationTests.m#L50>
>> an
>> >         NSURLCredential
>> >         <
>> http://developer.apple.com/library/ios/#Documentation/Cocoa/Reference/Foundation/Classes/NSURLCredential_Class/Reference/Reference.html>
>> 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.nsurlcredential/AeroGear-iOS/AeroGear-iOS/core/AGHttpClient.m#L240
>> >.
>> >         A usage example can be found in our integration test
>> >         <
>> https://github.com/cvasilak/aerogear-ios-integration/blob/basic.digest.nsurlcredential/AeroGear-iOS-Integration/AeroGear-iOS-IntegrationTests/AGHttpBasicAuthenticationTests.m
>> >
>> >
>> >         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/Cocoa/Reference/Foundation/Classes/NSURLCredential_Class/Reference/Reference.html>
>> 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 at lists.jboss.org <mailto:
>> aerogear-dev at 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 at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>> >     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130603/528ce663/attachment-0001.html 


More information about the aerogear-dev mailing list