camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject camel-ftp and ftps secure data channel
Date Tue, 15 Jun 2010 06:35:12 GMT
Claus,

I decided to create a new thred of conversation instead of reusing
"camel-ftp problems with ftps implicit mode". The modifications you did in
camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave me a lot
of problems due to the changs in Camel's OSGi support. Willem has helped me
to sort them out and I've now gone back to the original ftps secure data
channel subject.

NOTE, if you've read my last post in the thread "camel-ftp problems with
ftps implicit mode" I had missed the first line of the exception stacktrace
which I have corrected in this mail.

I've now tested your ftps enhancement against Filezilla and Serv-U and it
works. However, I noticed the following:

If option "execPbsz" is not set then the PBSZ command is not sent at all.
The documentation says that default value is "0" which indicates that PBSZ
is always sent. I think the behaviour is correct but the documentation
should change and specify that "null" is the default value for "execPbsz".

About the configuration, I still think that the configuration is a bit
illogical. First of all, PBSZ and PROT commands are valid even though a
secure data channel is not used. It might even be valid for purt ftp (not
ftps) as well - I'm not sure. Therefore, the execProt and execPbsz options
should take effect regardless of the value of the useSecureDataChannel
option.

Furthermore, I think the normal case should be default and require very
little configuration. I therefore suggest the following:

a) useSecureDataChannel should be true by default. This is due to two
reasons:
  1. If ftp severs have requirements in this area, they tend to be
restrictive. Serv-U, for example require PROT P (secure data channel). Clear
text is allowed if one explicitly sends PROT C but not if no PROT command is
sent at all.
  2. I think that if the default is clear text then many developers will
send unencrypted content by mistake. I think that if you choose to use ftps,
most developers assume that the data is encrypted. That's what I did anyway.

b) If useSecureDataChannel is true, then this implies execPbsz=0 and
execProt=P without having to configure it explicitly.

c) execPbsz and execProt options shall always take effect and shall override
the values implied by setting useSecureDataChannel to true. Normally one
would not have to configure these options at all.

One can argue that if we make PBSZ 0 and PROT P the default, then we could
skip the useSecureDataChannel and only have the execProt and execPbsz
options. This would actually be OK since overriding the PBSZ 0 / PROT P
options is an active decision by a developer who presumably knows what s/he
is doing. This is OK with me but then it should also be possible to disable
sending of the PBSZ and PROT commands by explicitly setting those options to
the empty string.

Maybe I'm writing too much in this thread now but I also found another
problem: If something goes wrong, e g file already exists (Filezilla doesn't
permit overwrite) then I get the following exception on subsequent attempts.
I have to manually restart the route to get it to work.

org.apache.camel.component.file.GenericFileOperationFailedException: File
operation failed: null Unconnected sockets not implemented. Code: 221
at
org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
at
org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
...

I get the above exception regardless of the value of the "disconnect" optin
in camel-ftp.


Best regards,

/Bengt

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message