[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640897#action_12640897 ] David Latorre commented on FTPSERVER-136: - Actually this behaviour I mentioned was changed in Java SE 6 (when there is no Security Manager) but my explanation to the problem was incorrect (although the problem I pointed out would also affect if we fixed this). Now, this is correct (I think) We are building the InetAddress object representing the External Ip Address (when explicitly stated) inside the ListenerBeanDefinitionParser so, as Amichal said, the IP address is never looked up again (InetAddress will lookup the hostname if we didn't provide one when we created the object but won't even know that we didn't provide a numeric ip address so it won't look it up again). The easiest solution I can see is to store the address information in a String fiend and have a getter which will return an InetAddress or retrieve it as a String and build the object when appropriate (Not a problem since we also need to retrieve the local ip if we didn't configure the field in the xml). > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: Niklas Gustavsson >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640896#action_12640896 ] David Latorre commented on FTPSERVER-136: - So if I understand correctly, Amichal is providing a hostname (something like my-server.dyndns.org) as the external-ip-address in the passive data connection configuration. Is that right? Then, Amichal problem is that even if he's using a hostname which should be resolved through a DNS request, this name always point to the same address. This is because of the caching behaviour of InetAddress. From JavaDocs: InetAddress Caching The InetAddress class has a cache to store successful as well as unsuccessful host name resolutions. The positive caching is there to guard against DNS spoofing attacks; while the negative caching is used to improve performance. By default, the result of positive host name resolutions are cached forever, because there is no general rule to decide when it is safe to remove cache entries. Thus, we should set the security property which defines how long IP address will be cached: networkaddress.cache.ttl (default: -1) Indicates the caching policy for successful name lookups from the name service. The value is specified as as integer to indicate the number of seconds to cache the successful lookup. I find this could be a bit of a trouble because, most probably, Application Servers set themselves the property. And of course if a security manager is on we might not be able to change this setting. What do you think Niklas? Actually, that explanation about "spoofing prevention" is kinda laughable and I hope this cache forever default is dropped in the jdk! > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: Niklas Gustavsson >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: The names of FtpServerFactory#setFileSystem() and FtpServerFactory#getFileSystem()
2008/10/19 Andrea Francia <[EMAIL PROTECTED]>
> The FileSystemFactory is declared as:
>
> public interface FileSystemFactory {
> /**
> * Create user specific file system view.
> */
> FileSystemView createFileSystemView(User user) throws FtpException;
> }
>
> Its name is FileSystemFactory but it creates FileSystemViews instead of
> FileSystems?
> Should be renamed FileSystemViewFactory ? I think for no.
> What represents a FileSystemFactory? I think a single FileSystem that can
> be viewed (differently) from different users.
>
>
> The fact that the designer choose the Factory Class pattern for this piece
> of the system it's important but, I think, it's more important names the
> classes for what they represents. We can always document the fact that we
> choose the Factory Class pattern in the class javadocs.
>
> I think the right name for FileSystemFactory is FileSystem.
>
I think your suggestion about FileSystemFactory not being an adequate name
makes sense. I don't know, though, if FileSystem would be the best name. I
cannot think of anything better myself but I I'd prefer that the name
indicated that "FileSystem" class mission is to create different views
depending on the user (as you explained).
So, any other ideas? what do you think ?
>
> In the FtpServerFactory there is a similar names inconsistence that would
> be automatically resolved if we rename FileSystemFactory :
>
> public class FtpServerFactory {
> public FileSystemFactory getFileSystem() { ... }
> public void setFileSystem(FileSystemFactory fileSystem) { ... }
> }
>
> A getter/setter pair that get/set the fileSystem property.
>
> I propose the following the folling renaming:
>
> FileSystemFactory --> FileSystem
>
>
> In addition I think that the createFileSystemView() method name could be
> simplified:
> FileSystemFactory#createFileSystemView() --> FileSystem#createView()
> --
> Andrea Francia
> http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html
>
>
The names of FtpServerFactory#setFileSystem() and FtpServerFactory#getFileSystem()
The FileSystemFactory is declared as:
public interface FileSystemFactory {
/**
* Create user specific file system view.
*/
FileSystemView createFileSystemView(User user) throws FtpException;
}
Its name is FileSystemFactory but it creates FileSystemViews instead of
FileSystems?
Should be renamed FileSystemViewFactory ? I think for no.
What represents a FileSystemFactory? I think a single FileSystem that
can be viewed (differently) from different users.
The fact that the designer choose the Factory Class pattern for this
piece of the system it's important but, I think, it's more important
names the classes for what they represents. We can always document the
fact that we choose the Factory Class pattern in the class javadocs.
I think the right name for FileSystemFactory is FileSystem.
In the FtpServerFactory there is a similar names inconsistence that
would be automatically resolved if we rename FileSystemFactory :
public class FtpServerFactory {
public FileSystemFactory getFileSystem() { ... }
public void setFileSystem(FileSystemFactory fileSystem) { ... }
}
A getter/setter pair that get/set the fileSystem property.
I propose the following the folling renaming:
FileSystemFactory --> FileSystem
In addition I think that the createFileSystemView() method name could be
simplified:
FileSystemFactory#createFileSystemView() --> FileSystem#createView()
--
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html
