Re: [ecf-dev] Credentials and proxy API for file retrieval

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Henrich,

Henrich Kraemer wrote:
> Hi Scott,
>
> Thanks for your answers. Below are some more follow up questions:
>
> > The setProxy API allows callers to override the Platform proxy API, but
> > if the setProxy is *not* used explicitly, the current impl of both
> > providers will use the org.eclipse.core.net proxy API (if that 
> bundle is
> > present) to get/use proxy information and proxy credentials.
>
> Should I open a JavaDoc related defect or enhancement request?

A doc bug would be great, thanks.

> > >
> > > Q4: The need for Authentication can be influenced by the presence of
> > > cookies. How are cookies managed?
> > >
> >
> > They are not currently managed by the ECF provider code.  If a specific
> > provider manages them (e.g. httpclient or urlconnection) then that's 
> how
> > they are managed.
> >
> > >
> > > Q5: HttpClient 3 and 4 provide a great deal of connection management
> > > logic. Typically one would want to use the same connection manager
> > > across different retrievals. How can ECF take advantage of this?
> > >
> >
> > The httpclient provider can/could be modified to use the same 
> connection
> > manager (if I'm understanding correctly).
>
> Yes. This would also cause credential state to be cached as well as
> cookies (in HttpClient 3).
> But some callers may require additional control. For example to
> never accept cookies, allow only a certain number of connections per host,
> forget certain credentials etc.
> Some apps may need different strategies.
> Is there a natural place where this would fit?

They could be provided in the 'options' map to the http provider.  So 
far, we haven't defined any provider-specific options.  This could be 
used in this manner for those that wanted more fine-grained control of 
http.  I'm not sure all of these are appropriate for cross-provider API, 
as initially they seem pretty specific to http...but perhaps there are 
some, and if so these could be added explicitly via new/additional API.

> >
> > >
> > > Q6: An alternative to having the ECF consumer deal with
> > > authentication, ECF could potentially be responsible for managing
> > > this. Credentials and proxy info would not have to be passed in at 
> all
> > > and ECF would do 'the right thing'.
> > >
> >
> > In the case of proxy info ECF does do 'the right thing'...assuming that
> > the right thing is using the platform's net proxy API :).
> >
> > > However in this case some API would presumably be needed to clear
> > > (some) credentials, cookies, close open connections etc.
> > >
> >
> > Yes.  For ECF to manage credentials that's agreed...there would be
> > additional API (and probably UI also) needed to manage/clear
> > credentials, cookies, etc.
>
> Are there plans or existing RFEs for this?

Not yet.  If you would like to look at and propose adding to the ECF 3.0 
plan, please see http://wiki.eclipse.org/ECF/Plan_for_3.0.

I'm currently going over the plan with an eye toward how much we can 
do...given how many contributors and committers there are for different 
technical areas.  If you/yours can make a commitment to work on this, we 
can/should certainly include such work in the plan for 3.0.

Thanks,

Scott