camel-users mailing list archives

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

Just realised that I can stop both PSBZ and PROT to be sent by
specifying useSecureDataChannel=false. This means that it is possible to
tweak this every possible way. The only issue then would be the name of this
option. E g it's a bit illogical to specify:

useSecureDataChannel=false
execProt=P

as well as:

useSecureDataChannel=true
execProt=C

What the option "useSecureDataChannel" really does is setting default values
for execProt and execPbsz - maybe this should be reflected in the name. What
about renaming this option to "disableSecureDataChannelDefaults" (maybe a
bit long...). The meaning of its value would be the inverse of
"useSecureDataChannel" and its default value would be false.


/Bengt

2010/6/15 Bengt Rodehav <bengt@rodehav.com>

> Claus,
>
> I've tested your new version and it works very good. However, I did not
> find a way to specify that the PSBZ command should not be sent at all. I
> have a feeling that one does not want to send it when explicitly specifying
> PROT C. I'm not sure but maybe we need a way of specifying the the PSBZ /
> PROT command should not be sent. Perhaps some reserved value like "-1" for
> execPbsz and "none" for execProt.
>
> One other question/suggestion. The default port for ftps in camel-ftp is
> 2222. I don't quite understand why. Both Filizilla and Serv-U use port 21
> (the normal ftp port) for explicit ftps and port 990 for implicit ftps. I
> have a feeling that this is standard practice. Would be nice if camel-ftp
> defaulted to that.
>
> Did you know anything about the exception I mentioned? (Unconnected
> sockets not implemented...)
>
>
> Best regards,
>
> /Bengt
>
>
> 2010/6/15 Claus Ibsen <claus.ibsen@gmail.com>
>
> Hi Bengt
>>
>> I have just committed a change on trunk. Can you test it on your system?
>> It now defaults have useSecureDataChannel as true. And that P and 0 is
>> used if not explicit configured.
>>
>>
>>
>> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <bengt@rodehav.com> wrote:
>> > 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
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>
>

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