Chris, sorry I didn't see your reply before I sent mine - sounds like I pretty much echoed what you said (though not in quite as much detail). :-) G
On Thursday, October 22, 2009, at 12:32PM, "Christopher Brind" <[email protected]> wrote: >Hi Sandro, > >> Or is it unnecessary because I can do a Query first without >> authentication, and in case of authentication error, instance the >> right authenticator and redo the query ? > >Yep, I think so. > > >> So maybe this could become a sort of factory to instance them if/when >> required ... and finally we could refactor Basic and Digest >> Authentication classes with a common base class. > >Maybe, but this could soon end up becoming API bloat... > >The problem is that all they have in common is a username and >password. I guess in terms of 'HTTP built in' authentication systems >that's fine, but the protocol is extensible, so Basic / Digest might >not be appropriate in a custom environment (e.g. using some kind of >SSO technology we don't know/care about). > >For instance, I the server could return the header: > >WWW-Authenticate: RSA SecureID > >And expect them to then send some bizarre combination of username, >password and secure id. > >Thus, an AuthenticationFactory wouldn't know what to Authentication >instance to return unless we have 'provided' an authentication >provider for this method. Things suddenly start getting rapidly more >complicated. At this stage we could create an extension point for >authentication providers, and add a few more classes to the API which >might never get used by most adopters. > >This seems easy enough to me: > >} catch (QueryAuthenticationException ex) { > > if ("Basic".equals(ex.getType()) { > // do something for basic > } else if ("Digest".equals(ex.getType()) { > // do something for digest > } else { > // message("Unable to authenticate against resource."); > } > >} > >It's easy enough to envisage a reasonable design that can accommodate >the above without having to build it in to Pivot, I feel. > > >Cheers, >Chris > > > > >2009/10/22 Sandro Martini <[email protected]>: >> Hi Chris, >> >>> Why not have the Query class thrown a different exception (e.g. >>> QueryAuthenticationException) if it couldn't authenticate? >> Why not ? Thanks for the suggestion, could be useful ... now let's see >> what say Greg on this. >> >> In any case, a GenericAuthentication class (or whatever name it should >> have) is missing, to solve the problem shown before, to provide a sort >> of abstraction to simplify life to coders, and also in the case a >> dialog (pivot standard or not, it's a detail) has to be shown to >> handle this situation in a simple way, like in browsers. >> >> Or is it unnecessary because I can do a Query first without >> authentication, and in case of authentication error, instance the >> right authenticator and redo the query ? >> So maybe this could become a sort of factory to instance them if/when >> required ... and finally we could refactor Basic and Digest >> Authentication classes with a common base class. >> >> Comments ? >> >> Bye, >> Sandro >> > >
