pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Brind <bri...@brindy.org.uk>
Subject Re: Idea for new Demo
Date Thu, 22 Oct 2009 15:45:52 GMT
Why not have the Query class thrown a different exception (e.g.
QueryAuthenticationException) if it couldn't authenticate?

The caller can catch that, decide how to authenticate (e.g. request
credentials from the user) and then execute the query again at a later

So change this:

           int statusPrefix = status / 100;
            if (statusPrefix != 2) {
                throw new QueryException(status, message);


if (status == 401) { // unauthorised
  throw QueryAuthenticationException(responseHeaders.get("WWW-Authenticate"));
} else {
           int statusPrefix = status / 100;
            if (statusPrefix != 2) {
                throw new QueryException(status, message);


2009/10/22 Sandro Martini <sandro.martini@gmail.com>:
> Hi Greg,
>> The HTTP protocol can provide this information for you. When you make an unauthenticated
request, the server will respond with a challenge indicating how the next request should be
> Yes, you remember that for DigestAuthentication you have done a little
> change in Query to support this ... but what I think is missing now is
> a GenericAuthentication class (but I don't like this name, probably is
> wrong) that tries to make a query without authentication info (and for
> query without authentication this would be enough), and in case of
> exception (because the server needs some authentication data for the
> reply), it could create an instance of the right Authenticator
> (depending on the type of needed authentication), and then retry the
> query with the new data ...
> This could be useful:
> - for example anytime I try to access to data somewhere and I have no
> prior knowledge of the authentication required
> - we could also implement standard Pivot Dialogs to handle this common
> behavior (if the user enable this in the instance of this class he
> have in its application, because maybe I could use it without GUI ...
> like in Unit Tests)
>  -- but having this/these standard dialogs could be an optional feature
>  -- and in any case it would be interesting to have inside this class
> a property with the dialog to use (an instance of the standard, or a
> user-defined dialog)
> Greg, comments ?
> I can try to do this, but before I'd like to ask others on what they
> think ... Todd and others, what do you say ?
> Sandro

View raw message