You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Sandro Martini <sa...@gmail.com> on 2009/10/22 16:27:34 UTC
Idea for new Demo
Hi to all,
with the new part on Digest Authentication just merged I've got now an
idea for a new Demo: a (Simple) Download Manager, but for one of next
releases.
The GUI could be split with a Menu toolbar (with Help, Settings
elements, etc), an upper panel with an URL text field and a button
like in Browsers, at the bottom an optional status bar or other, and
at the center the core: a split panel (or a tab panel) with at left a
list of current downloads (active, or in queue), and on right (or in
another tab) the details of the selected download (and all actions on
it, like start/pause/resume/stop/delete/maybe edit).
But one thing that I think is missing currently is the ability to
execute Web Queries without before knowing the authentication scheme
that could be required for the given URL (sometimes nothing, sometimes
Basic, Digest, etc ...).
To support this I think we should have something (or maybe a generic
authentication class) that in case of authorization needed I could
have a sort of callback and let my application take control (for
example to ask the user required data to login, maybe using a standard
Dialog ... like in Browsers) and only after proceed with the retry of
the query (or stop the first query and instance the right type of
Pivot Authenticator, containing the data of the user) ...
I think this feature could be useful in many situations, like in this sample.
What do you think ?
Bye,
Sandro
Re: Idea for new Demo
Posted by Sandro Martini <sa...@gmail.com>.
Hi Todd,
> In general, I'd say that if it does a good job highlighting a feature of
> Pivot, then it's a good demo. Demos don't generally get assigned JIRA
> tickets - they just get created by the person who champions them. So I'd
> say if you're itching to write a demo, have at it :)
Ok, thanks ... my idea for this was mainly to write a (simple) real
world application (that could be simple to compare with similar
applications) to ensure that our networking and authentication classes
works good (or better, it works good, but this is another way to test
it).
I'll try it as a future work, and post code if/when good ...
Byeee
Re: Idea for new Demo
Posted by Todd Volkert <tv...@gmail.com>.
In general, I'd say that if it does a good job highlighting a feature of
Pivot, then it's a good demo. Demos don't generally get assigned JIRA
tickets - they just get created by the person who champions them. So I'd
say if you're itching to write a demo, have at it :)
-T
On Fri, Oct 23, 2009 at 3:46 AM, Sandro Martini <sa...@gmail.com>wrote:
> Hi to all and thanks for all your suggestions,
> I understand your(s) point of view, and probably this could really
> generate some code bloat, my idea was to try to handle most common
> cases in a simple way (and efficient, also from a GUI point of view),
> but we can live without it, Ok.
>
> So to handle some of the cases seen in the (candidate) Demo we'll have
> to retry queries, or make something in a dedicated class (in user
> code).
>
>
> About the (Simple) "Download Manager" Demo what do you think,
> interesting or can we drop it ?
>
>
> Thanks,
> Sandro
>
Re: Idea for new Demo
Posted by Sandro Martini <sa...@gmail.com>.
Hi to all and thanks for all your suggestions,
I understand your(s) point of view, and probably this could really
generate some code bloat, my idea was to try to handle most common
cases in a simple way (and efficient, also from a GUI point of view),
but we can live without it, Ok.
So to handle some of the cases seen in the (candidate) Demo we'll have
to retry queries, or make something in a dedicated class (in user
code).
About the (Simple) "Download Manager" Demo what do you think,
interesting or can we drop it ?
Thanks,
Sandro
Re: Idea for new Demo
Posted by Christopher Brind <br...@brindy.org.uk>.
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 <gk...@mac.com>:
> 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" <br...@brindy.org.uk> 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 <sa...@gmail.com>:
>>> 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
>>>
>>
>>
>
Re: Idea for new Demo
Posted by Greg Brown <gk...@mac.com>.
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" <br...@brindy.org.uk> 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 <sa...@gmail.com>:
>> 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
>>
>
>
Re: Idea for new Demo
Posted by Christopher Brind <br...@brindy.org.uk>.
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 <sa...@gmail.com>:
> 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
>
Re: Idea for new Demo
Posted by Todd Volkert <tv...@gmail.com>.
As long as the caller can get at the response headers after they catch an
exception, then I think we're covered as is -- the caller catches
QueryException, looks at the HTTP status using exception.getStatus(), and if
it's 401, looks for the authentication scheme by pulling that response
header out of the query.
-T
On Thu, Oct 22, 2009 at 12:50 PM, Greg Brown <gk...@mac.com> wrote:
> >> 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.
>
> I think that's a slippery slope. Why wouldn't we then also define custom
> exceptions for every HTTP error code? I think I would prefer to leave it as
> is.
>
> >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 ?
>
> Correct.
>
> >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.
>
> Honestly, I think this kind of code is pretty straightforward and should be
> left to the application.
>
>
Re: Idea for new Demo
Posted by Greg Brown <gk...@mac.com>.
>> 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.
I think that's a slippery slope. Why wouldn't we then also define custom exceptions for every HTTP error code? I think I would prefer to leave it as is.
>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 ?
Correct.
>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.
Honestly, I think this kind of code is pretty straightforward and should be left to the application.
Re: Idea for new Demo
Posted by Sandro Martini <sa...@gmail.com>.
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
Re: Idea for new Demo
Posted by Christopher Brind <br...@brindy.org.uk>.
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
point.
So change this:
int statusPrefix = status / 100;
if (statusPrefix != 2) {
throw new QueryException(status, message);
}
to:
if (status == 401) { // unauthorised
throw QueryAuthenticationException(responseHeaders.get("WWW-Authenticate"));
} else {
int statusPrefix = status / 100;
if (statusPrefix != 2) {
throw new QueryException(status, message);
}
}
Cheers,
Chris
2009/10/22 Sandro Martini <sa...@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 authenticated.
> 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
>
Re: Idea for new Demo
Posted by Sandro Martini <sa...@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 authenticated.
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
Re: Idea for new Demo
Posted by Greg Brown <gk...@mac.com>.
>But one thing that I think is missing currently is the ability to
>execute Web Queries without before knowing the authentication scheme
>that could be required for the given URL (sometimes nothing, sometimes
>Basic, Digest, etc ...).
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 authenticated.