| [ecf-dev] Credentials and proxy API for file retrieval |
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?
Additional questions:
Q1: How can the caller determine that authentication failed?
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)
Q2b: How to know whether proxy credentials or target authorization and credentials are needed?
Q3: How can authentication state be carried along?
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?
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?
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'. However in this case some API would presumably be needed to clear (some) credentials, cookies, close open connections etc.
Thanks much,
Henrich