Hi Christos, Looking at the integration test code for the second approach (the one not using the Auth Module), you just set the credentials and you don't have to explicitly call login/logout?

Sure it looks like magic. You don't have the nested callback structure. But where do you put the failure block code then, in case of wrong credentials?

++ Corinne On 29 May 2013 10:20, Christos Vasilakis <cvasilak(a)gmail.com&gt; 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) > > Wdyt? > > Thanks, > Christos > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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

On Wed, May 29, 2013 at 10:20 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt;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

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(a)lists.jboss.org&gt; > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi I guess we can have both approaches

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/AFN... 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?

Christos On May 29, 2013, at 1:27 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Wed, May 29, 2013 at 12:18 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;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(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(a)lists.jboss.org&gt; > > 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 > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi team, we have decided for our ios 1.1.0 release to go with the approach of setting the NSURLCredential as a config param on the pipe.

That is: id <AGPipe> pipe = [_pipeline pipe:^(id <AGPipeConfig> config) { [config setName:@"autobots"]; // set up credentials for Basic/Digest [config setCredential:[NSURLCredential credentialWithUser:PASSING_USERNAME password:LOGIN_PASSWORD persistence:NSURLCredentialPersistenceNone]]; }];

Main point that we decided to go with that approach is that users are familiar with the NSURLCredential object and is more straightforward to use instead of going through the authentication module 'login', 'logout' requests for this type of auth. It's a similar approach on what our underlying networking lib does when the user wants to set the credentials.

A note would be added for the user to be cautious when setting the persistence type (e.g. NSURLCredentialPersistencePermanent) so he can clear it up afterwards.

Thanks, Christos On Jun 3, 2013, at 4:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Mon, Jun 3, 2013 at 3:22 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt;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/AFN... 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(a)apache.org&gt; > wrote: > > > > > On Wed, May 29, 2013 at 12:18 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;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(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(a)lists.jboss.org&gt; >> > 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 >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jun 18, 2013, at 12:33 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Tue, Jun 18, 2013 at 11:26 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > Hi team, > > we have decided for our ios 1.1.0 release to go with the approach of > setting the NSURLCredential as a config param on the pipe. > Not really decided, since decisions are made here, on the public mailing list :-) +1000 for that wrong expression my bad :(

As mentioned on the meeting notes we talked about it, coming to the conclusion, that for now, it makes more sense using this approach (compared to the AGAuthModule with login/logout/enroll). > That is: > > id <AGPipe> pipe = [_pipeline pipe:^(id <AGPipeConfig> config) { > [config setName:@"autobots"]; > // set up credentials for Basic/Digest > [config setCredential:[NSURLCredential > credentialWithUser:PASSING_USERNAME > password:LOGIN_PASSWORD > persistence:NSURLCredentialPersistenceNone]]; > }]; > > I do like it - it's clean! > > Main point that we decided to go with that approach is that users are familiar with the NSURLCredential object and is more straightforward to use instead of going through the authentication module 'login', 'logout' requests for this type of auth. It's a similar approach on what our underlying networking lib does when the user wants to set the credentials. > > Fully agree - and this reflects what we discussed on the iOS team meeting (this is the mentioned follow-up). > A note would be added for the user to be cautious when setting the persistence type (e.g. NSURLCredentialPersistencePermanent) so he can clear it up afterwards. > > Ah, yeah - that's perfect and good! +1 on that > > Thanks, > Christos > > > On Jun 3, 2013, at 4:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Mon, Jun 3, 2013 at 3:22 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt;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/AFN... 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(a)apache.org&gt; >> wrote: >> >> >> >> >> On Wed, May 29, 2013 at 12:18 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;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(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(a)lists.jboss.org&gt; >>> > 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 >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

This all makes sense to me. It is similar to what I was trying to do with JS but still not sure we will get it to work or not.

+1 On Jun 18, 2013, at 5:01 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Tue, Jun 18, 2013 at 11:53 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > > On Jun 18, 2013, at 12:33 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Tue, Jun 18, 2013 at 11:26 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > >> Hi team, >> >> we have decided for our ios 1.1.0 release to go with the approach of >> setting the NSURLCredential as a config param on the pipe. >> > > > Not really decided, since decisions are made here, on the public mailing > list :-) > > > +1000 for that wrong expression my bad :( > :-) all good! not a big deal > > > As mentioned on the meeting notes we talked about it, coming to the > conclusion, that for now, it makes more sense using this approach (compared > to the AGAuthModule with login/logout/enroll). > > > > >> That is: >> >> >> id <AGPipe> pipe = [_pipeline pipe:^(id <AGPipeConfig> config) { >> >> [config setName:@"autobots"]; >> >> // set up credentials for Basic/Digest >> >> [config setCredential:[NSURLCredential >> >> credentialWithUser:PASSING_USERNAME >> >> password:LOGIN_PASSWORD >> >> persistence:NSURLCredentialPersistenceNone]]; >> >> }]; >> >> >> >> > I do like it - it's clean! > > > > >> >> >> >> >> Main point that we decided to go with that approach is that users are familiar with the NSURLCredential object and is more straightforward to use instead of going through the authentication module 'login', 'logout' requests for this type of auth. It's a similar approach on what our underlying networking lib does when the user wants to set the credentials. >> >> > Fully agree - and this reflects what we discussed on the iOS team meeting > (this is the mentioned follow-up). > > > >> A note would be added for the user to be cautious when setting the persistence type (e.g. NSURLCredentialPersistencePermanent) so he can clear it up afterwards. >> >> > Ah, yeah - that's perfect and good! > > +1 on that > > >> >> >> Thanks, >> >> Christos >> >> >> >> >> On Jun 3, 2013, at 4:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> >> On Mon, Jun 3, 2013 at 3:22 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt;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/AFN... 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(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> >>> On Wed, May 29, 2013 at 12:18 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;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(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(a)lists.jboss.org&gt; >>>> > 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(a)lists.jboss.org&gt; >>>> > 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 >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev