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
>
