Except, that I was advocating the new exception and you didn't. =) But given your and Todd's comments, I concur, even that a new exception is unnecessary.
Cheers, Chris 2009/10/22 Greg Brown <[email protected]>: > 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 >>> >> >> >
