Community
Participate
Working Groups
Oomph's ECFURIHandlerImpl currently has a horrible reflective hack for enabling the processing of cookies in the underlying http client framework. Specifically the method org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl.FileTransferListener.applyCookieStore(IFileTransferConnectStartEvent) https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.setup.core/src/org/eclipse/oomph/setup/internal/core/util/ECFURIHandlerImpl.java#n978 This support was added via https://bugs.eclipse.org/bugs/show_bug.cgi?id=537032 I've also has problems with hosts the return invalid expiry dates which causes the cookies to be rejected and had to work around that problem too: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539070 The basic use case for Oomph is that we want to provide access to private setups at github or github-like (gitlab) hosts. For such a host, one needs to login and acquire a cookie and then the cookie must to sent to the host (via the headers) when accessing the resource. For github, accessing the login page yields a cookie that must be sent back to the host when logging in. The Oomph processing (as described in 537032), involves augmenting the original/actual URI with a query string to direct the prior processing of a login form URI. That URI will be visited before the resource is accessed. The login form itself is downloaded and inspected to find the <input> fields. The user is prompted for credentials and those credentials are stored in secure storage and those credentials are posted (http post) back to the host to login and acquire the cookie. The cookies need to be manage globally so that the same acquired cookies are used on all threads. I can see no direct way that ECF currently supports such a mechanism. Of course I don't expect all this funky stuff to happen transparently within ECF, but it would be good to have several features available: 1) A clean way to provide a cookie store, preferably via standard Java APIs for cookie stores to hide the http client implementation details. Note that my hack has to bridge the implementation of http client and Java's standard cookie store implementation. 2) A way to make the cookie header processing less fussy, i.e., to not reject a cookie because the expiry date format is not strictly conforming to some specification. Is there a better way to do a "post" via ECF than what I'm currently doing in ECFURIHandlerImpl?
Hi Ed, (In reply to Ed Merks from comment #0) > Oomph's ECFURIHandlerImpl currently has a horrible reflective hack for > enabling the processing of cookies in the underlying http client framework. > Specifically the method > org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl. > FileTransferListener.applyCookieStore(IFileTransferConnectStartEvent) > > https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org. > eclipse.oomph.setup.core/src/org/eclipse/oomph/setup/internal/core/util/ > ECFURIHandlerImpl.java#n978 > > This support was added via > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=537032 > > I've also has problems with hosts the return invalid expiry dates which > causes the cookies to be rejected and had to work around that problem too: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=539070 > > The basic use case for Oomph is that we want to provide access to private > setups at github or github-like (gitlab) hosts. For such a host, one needs > to login and acquire a cookie and then the cookie must to sent to the host > (via the headers) when accessing the resource. For github, accessing the > login page yields a cookie that must be sent back to the host when logging > in. The Oomph processing (as described in 537032), involves augmenting the > original/actual URI with a query string to direct the prior processing of a > login form URI. That URI will be visited before the resource is accessed. > The login form itself is downloaded and inspected to find the <input> > fields. The user is prompted for credentials and those credentials are > stored in secure storage and those credentials are posted (http post) back > to the host to login and acquire the cookie. The cookies need to be manage > globally so that the same acquired cookies are used on all threads. > > I can see no direct way that ECF currently supports such a mechanism. Of > course I don't expect all this funky stuff to happen transparently within > ECF, but it would be good to have several features available: > > 1) A clean way to provide a cookie store, preferably via standard Java APIs > for cookie stores to hide the http client implementation details. Note that > my hack has to bridge the implementation of http client and Java's standard > cookie store implementation. I don't know the java.net API nor the apache cookie api particularly well, but I've looked them over. I would be inclined to define a new as-simple-as-possible package in org.eclipse.ecf.filetransfer bundle called: org.eclipse.ecf.filetransfer.cookie that depended upon java.net.classes, ecf core + filetransfer classes only. Something at the same/similar level of abstraction as org.apache.http.cookie but not directly dependent on org.apache.http.cookie (in api) so that non-apache impls would be possible. It might also make sense to put some classes into a new package in org.eclipse.ecf.provider.filetransfer called org.eclipse.ecf.provider.filetransfer.cookie that could support all the providers with (e.g.) abstract classes for use by any provider implmentation such as httpclient45. > > 2) A way to make the cookie header processing less fussy, i.e., to not > reject a cookie because the expiry date format is not strictly conforming to > some specification. I don't understand what would be required for this, but seems as though we could make it more flexible as long as the expected underlying provider impl (httpclient45) is sufficiently flexible. > > Is there a better way to do a "post" via ECF than what I'm currently doing > in ECFURIHandlerImpl? ECF has a 'send' API called ISendFileTransferContainerAdapter. Given the abstract classes in org.eclipse.ecf.provider.filetransfer I believe send via http post would be pretty easy to implement with jre/httpclient4/45, but we've never done so...without specific server-side target. We have outgoing providers implemented for ssh (haven't moved that to mina ssh yet) and xmpp. I would suggest opening another enhancement for send via httpclient45 post specifically.
