[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Credentials and proxy API for file retrieval
|
Hi Henrich,
Henrich Kraemer wrote:
I am trying to understand how IRetrieveFileTransferContainerAdapter
and IRetrieveFileTransfer work in particular with respect to
authentication for both proxy and the targeted server.
IRetrieveFileTransfer extends IRetrieveFileTransferContainerAdapter
and can be created via IRetrieveFileTransferFactory which is
registered as an OSGI service. Below are some snippets from the JavaDocs:
The IRetrieveFileTransferContainerAdapter methods
setConnectContextForAuthentication(IConnectContext)
* This method should be called with a non-null connectContext in order
to allow
* authentication to occur during call to
and setProxy(Proxy).
* This method should be called with a non-null proxy to allow the
given proxy to
* be used in subsequent calls to
It seems ECFs' API is similar to Apache HttpClient version 4 with
respect to authentication, where the caller is responsible to manage
credentials.
See my related question to the HttpClient mailing list with Subject
"Potential account lockouts when using authentication using concurrent
http requests"
http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/200809.mbox/%3COFDC66AEAE.C8077D2D-ON882574C6.00726684-882574C6.0075A515@xxxxxxxxxx%3E
It appears different credentials can be set independently for
different IRetrieveFileTransfer or
IRetrieveFileTransferContainerAdapter instances. If the ECF API caller
is responsible for managing credentials, I would expect that a lack of
credentials would cause the retrieval to fail (if authentication is
needed by the server). Similar if bad credentials such as a bad
password are provided. The ECF retrieval should not cause a dialog to
popup in these cases. Instead when a retrieval fails the caller can
decide whether to prompt the user an retry the retrieval on the same
IRetrieveFileTransfer (or adapter).
Main question: Is this describing the API correctly?
Yes, in general. The ECF API caller is (currently) responsible for
managing credentials.
Additional questions:
Q1: How can the caller determine that authentication failed?
If authentication fails (for http) the sendRetrieveRequest should throw
an Exception. Previous to what's in HEAD (i.e. 3.4.0/ECF 2.0.0), there
was no easy way to determine the exception/error type. In response to
this bug 226769, though, we've added a getErrorCode method on the
exception class. Although there's some desire (on my part as well as
Pascal's) to define some more structure than int for error code. It
might make more sense to have an enum that had all the appropriate
failure codes...including auth failures of course...for file transfer
(rather than just returning an int).
https://bugs.eclipse.org/bugs/show_bug.cgi?id=226769
Q2a: How can the caller determine for which authentication scope
(AuthScope in HttpClient land) the credentials were requested for
(this may include a realm string)? (RFC 2617 support)
One way would be to add an ObjectCallback that exposed the realm info to
the callback handler. The existing providers don't do this, but it
would/could be easily added.
Q2b: How to know whether proxy credentials or target authorization and
credentials are needed?
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.
Q3: How can authentication state be carried along?
It can/could be done via the Callbacks created by the provider before
calling the CallbackHandler.handle() method. That being said, we don't
do this now.
Authentication headers will need information from previous requests.
Unless there is a mechanism to carry this state forward from a
previously failed request, the previous request/response must be
redone which should be avoided for efficiency reasons. Perhaps a
general mechanism to keep conversational state would make sense.
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).
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.
Incidently, one of the things that I will likely be looking to add in
ECF 2.1 is an ECF 'storage' API that uses the Equinox secure preferences
API. I have this API running/tested (it's available in
/cvsroot/technology/org.eclipse.ecf plugins/org.eclipse.ecf.storage
plugin also a tests/org.eclipse.ecf.tests.storage plugin exists). The
point of this plugin is to allow ECF IDs (e.g. IFileIDs) to be easily
stored and retrieved securely (along with arbitrary data...like
passwords...that need to be stored and associated with IDs/IFileIDs).
See methods on IIDStore and test code if you are interested. One of the
main things that was keeping us back from managing credentials within
ECF itself was the lack of availability of secure storage in the
platform. So now that issue is gone...and we have the IIDStore API we
can/could add credentials management/storage to ECF itself.
Thanks,
Scott
Thanks much,
Henrich
------------------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
