[jira] [Created] (FTPSERVER-411) Support CCC command
Support CCC command --- Key: FTPSERVER-411 URL: https://issues.apache.org/jira/browse/FTPSERVER-411 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Assignee: Sai Pullabhotla Priority: Minor Attachments: FTPS-CCC.patch Support CCC command to switch back to plain socket after login. See discussion on the mailing list at http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01587.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-411) Support CCC command
[ https://issues.apache.org/jira/browse/FTPSERVER-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-411: -- Attachment: FTPS-CCC.patch This is a preliminary patch for the team to review. I don't know if this is the correct way to do it, but we will find out. > Support CCC command > --- > > Key: FTPSERVER-411 > URL: https://issues.apache.org/jira/browse/FTPSERVER-411 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla >Priority: Minor > Attachments: FTPS-CCC.patch > > > Support CCC command to switch back to plain socket after login. See > discussion on the mailing list at > http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01587.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-410) Support digital certificate authentication with or without passwords
[ https://issues.apache.org/jira/browse/FTPSERVER-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-410: -- Attachment: FTPS-CERT-AUTH.patch This is the preliminary code for team's review to implement this feature. > Support digital certificate authentication with or without passwords > > > Key: FTPSERVER-410 > URL: https://issues.apache.org/jira/browse/FTPSERVER-410 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Attachments: FTPS-CERT-AUTH.patch > > > Please see the discussion on the mailing list at - > http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01507.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FTPSERVER-410) Support digital certificate authentication with or without passwords
Support digital certificate authentication with or without passwords Key: FTPSERVER-410 URL: https://issues.apache.org/jira/browse/FTPSERVER-410 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Assignee: Sai Pullabhotla Attachments: FTPS-CERT-AUTH.patch Please see the discussion on the mailing list at - http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg01507.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998022#comment-12998022 ] Sai Pullabhotla commented on FTPSERVER-357: --- Can this marked as done and closed or do we have any more work to do on this? > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FTPSERVER-371) Create a specialized FtpReply to send to Ftplets after login finishes
[ https://issues.apache.org/jira/browse/FTPSERVER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-371: -- Attachment: FTPSERVER-371.patch I've worked on this several months ago, and have been using in production with no issues. Just forgot to check it in. When you guys have a chance, could you please review it and provide your feedback? Thanks. > Create a specialized FtpReply to send to Ftplets after login finishes > - > > Key: FTPSERVER-371 > URL: https://issues.apache.org/jira/browse/FTPSERVER-371 > Project: FtpServer > Issue Type: New Feature > Components: Core, Ftplets >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: FTPSERVER-371.patch > > > As an addition to https://issues.apache.org/jira/browse/FTPSERVER-253, I > think it would be nice to have a specialized reply that could be sent to the > Ftplets. The reply could include information such as the attempted user name, > password used by anonymous users, any exception that was thrown by the > UserManager during authentication. Perhaps the exception is the most > important piece that the Ftplets (like the one that does audit logging) would > like to know. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FTPSERVER-360) When no passive ports are available error out immediately rather than waiting for a port to become available
[ https://issues.apache.org/jira/browse/FTPSERVER-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998020#comment-12998020 ] Sai Pullabhotla commented on FTPSERVER-360: --- I think this was already fixed. Can this be closed? > When no passive ports are available error out immediately rather than waiting > for a port to become available > > > Key: FTPSERVER-360 > URL: https://issues.apache.org/jira/browse/FTPSERVER-360 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.4 >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.0.6, 1.1.0 > > Attachments: FTPSERVER-360.patch > > > Based on the filed issue, http://issues.apache.org/jira/browse/FTPSERVER-359, > we probably want to quick fix the code to error out right away when no > passive port is available. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FTPSERVER-399) DefaultFtpHandler.sessionOpened does not check if the Ftplet returned a FtpletResult.SKIP
DefaultFtpHandler.sessionOpened does not check if the Ftplet returned a FtpletResult.SKIP - Key: FTPSERVER-399 URL: https://issues.apache.org/jira/browse/FTPSERVER-399 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.5 Reporter: Sai Pullabhotla Assignee: Sai Pullabhotla Fix For: 1.0.6 I was trying to use an Ftplet to send a custom welcome message using the Ftplet.onConnect. Within this method, I write a 220 reply to the client with my custom message, and return FtpletResult.SKIP. I expect that the server would not send the default welcome message, but it does it any how. When I looked at the server code, the DefaultFtpHandler does not handle the FtpletResult.SKIP case. I think it needs to be updated so a welcome message is sent only if the Ftplet returned DEFAULT result. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-789) Possible Deadlock/Out of memory when sending large amounts of data using Nio
[ https://issues.apache.org/jira/browse/DIRMINA-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878603#action_12878603 ] Sai Pullabhotla commented on DIRMINA-789: - Well, your statements do not match up with the Javadocs. I guess, we have to do some work on the Javadocs, unless you think I'm misinterpreting them. Below is what the WriteRequestFilter's Java doc says: Attaches an IoEventQueueHandler to an IoSession's WriteRequest queue to provide accurate write queue status tracking. The biggest difference from OrderedThreadPoolExecutor and UnorderedThreadPoolExecutor is that IoEventQueueHandler.polled(Object, IoEvent) is invoked when the write operation is completed by an IoProcessor, consequently providing the accurate tracking of the write request queue status to the IoEventQueueHandler. Most common usage of this filter could be detecting an IoSession which writes too fast which will cause OutOfMemoryError soon: session.getFilterChain().addLast( "writeThrottle", new WriteRequestFilter(new IoEventQueueThrottle())); The sentence I would like to highlight is - >> Most common usage of this filter could be detecting an IoSession which >> writes too fast which will cause OutOfMemoryError soon. Which is what I'm trying to prevent with this filter. > Possible Deadlock/Out of memory when sending large amounts of data using Nio > > > Key: DIRMINA-789 > URL: https://issues.apache.org/jira/browse/DIRMINA-789 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-RC1 > Environment: Windows Vista 64-bit Java 5 and Java 6 >Reporter: Sai Pullabhotla > Attachments: MinaClient.java, RandomDataServer.java > > > This is a followup to the post on the DEV mailing list, > http://old.nabble.com/Help-needed-with-OutOfMemory-error-and-or-GC-Issues-Dead-Locks-td28849756.html. > > I've even simplified the test cases so now it just has one simple NioServer, > and an NioClient. The MinaClient class creates 5 concurrent connections to > the RandomDataServer. Upon a successful connection, the server is setup to > send 500MB worth of random text data. The MinaClient just saves the received > data to a temp file in the working directory. When I run this code with small > amounts of data, it works fine, but with 500MB, I did not have success yet. > Some times, I get OOM on the server. Some times, nothing happens. > I've declared several constants in each class that you could change to try > various settings such as changing the amount of data served by the server, > whether or not to use an executor filter/IoEventThrottle etc. > Both classes have main methods, and I was running them as stand alone > applications on the same PC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-789) Possible Deadlock/Out of memory when sending large amounts of data using Nio
[ https://issues.apache.org/jira/browse/DIRMINA-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878568#action_12878568 ] Sai Pullabhotla commented on DIRMINA-789: - I understand what you are saying, and agree with it. However, I'm unable to figure out the purpose of IoThrottle filters. I tried using the WriteRequestFilter, which is what should help with the test server code I posted. But it does not seem to be helping. It just runs forever with little or no data flowing. > Possible Deadlock/Out of memory when sending large amounts of data using Nio > > > Key: DIRMINA-789 > URL: https://issues.apache.org/jira/browse/DIRMINA-789 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-RC1 > Environment: Windows Vista 64-bit Java 5 and Java 6 >Reporter: Sai Pullabhotla > Attachments: MinaClient.java, RandomDataServer.java > > > This is a followup to the post on the DEV mailing list, > http://old.nabble.com/Help-needed-with-OutOfMemory-error-and-or-GC-Issues-Dead-Locks-td28849756.html. > > I've even simplified the test cases so now it just has one simple NioServer, > and an NioClient. The MinaClient class creates 5 concurrent connections to > the RandomDataServer. Upon a successful connection, the server is setup to > send 500MB worth of random text data. The MinaClient just saves the received > data to a temp file in the working directory. When I run this code with small > amounts of data, it works fine, but with 500MB, I did not have success yet. > Some times, I get OOM on the server. Some times, nothing happens. > I've declared several constants in each class that you could change to try > various settings such as changing the amount of data served by the server, > whether or not to use an executor filter/IoEventThrottle etc. > Both classes have main methods, and I was running them as stand alone > applications on the same PC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-789) Possible Deadlock/Out of memory when sending large amounts of data using Nio
[ https://issues.apache.org/jira/browse/DIRMINA-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878555#action_12878555 ] Sai Pullabhotla commented on DIRMINA-789: - It looks like there is no easy way to simply wait for a write operation until the data is sent to the remote peer (other than using the messageSent event, which could be one or many events for one write). Is this correct? if so, should I open a JIRA for enhancing the API? Possibly updating the WriteFuture to signal a completion after the data is sent over the socket? I'm still looking for the best way to implement my requirement. I did some proof of concept a few months ago, which seemed to have worked fine. Over the past month or so, I spent a lot of time implementing my custom protocol, encoders and decoders around MINA (This is another layer I've that I did not mention before), but now I'm stuck with this major issue. I would appreciate any help you could provide in solving this issue. > Possible Deadlock/Out of memory when sending large amounts of data using Nio > > > Key: DIRMINA-789 > URL: https://issues.apache.org/jira/browse/DIRMINA-789 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-RC1 > Environment: Windows Vista 64-bit Java 5 and Java 6 >Reporter: Sai Pullabhotla > Attachments: MinaClient.java, RandomDataServer.java > > > This is a followup to the post on the DEV mailing list, > http://old.nabble.com/Help-needed-with-OutOfMemory-error-and-or-GC-Issues-Dead-Locks-td28849756.html. > > I've even simplified the test cases so now it just has one simple NioServer, > and an NioClient. The MinaClient class creates 5 concurrent connections to > the RandomDataServer. Upon a successful connection, the server is setup to > send 500MB worth of random text data. The MinaClient just saves the received > data to a temp file in the working directory. When I run this code with small > amounts of data, it works fine, but with 500MB, I did not have success yet. > Some times, I get OOM on the server. Some times, nothing happens. > I've declared several constants in each class that you could change to try > various settings such as changing the amount of data served by the server, > whether or not to use an executor filter/IoEventThrottle etc. > Both classes have main methods, and I was running them as stand alone > applications on the same PC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-789) Possible Deadlock/Out of memory when sending large amounts of data using Nio
[ https://issues.apache.org/jira/browse/DIRMINA-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877907#action_12877907 ] Sai Pullabhotla commented on DIRMINA-789: - Not to criticize or blame any one, but is the JavaDoc for IoSession.write(), is not accurate? It clearly states that - /** Writes the specified message to remote peer. This operation is asynchronous; IoHandler.messageSent(IoSession, Object) will be invoked when the message is actually sent to remote peer. You can also wait for the returned WriteFuture if you want to wait for the message actually written. **/ As you can see it clearly states that the message is written to the remote peer, not to the IoProcessor queue. So, according to this doc, waiting on the Furture should be sufficient. If not, we need to update the documentation. Also, the doc gives me the impression that one call to session.write() would result in one and only one "messageSent" event with the very same message that was written, assuming that the write was successful. I do understand that at the TCP level, the data might have been broken down into several packets, but messageSent should be fired only once, after all packets are sent. This is my interpretation of the doc (and the behavior one would naturally expect), and it contradicts with what you have said, where one call to session.write might result in an unknown number of messageSent events. At least, I hope that's what you said. If not, please correct me understand it. Now coming back to my original requirement - Client (C), connects to Server 1 (S1) and Server 2 (S2). Let's say S1 is a web server like Apache or App Server like Tomcat. S1 is sending a large file back to C. C has to forward that to S2. S1 is sending data as fast as it can, and C is receiving the messageReceived events. As soon as it sees this event, I simply writes the message to S2 (and possibly wait for the Future to complete, which does not guarantee a successful write?). Transfer rate from C to S2 is a lot slower than what it is from S1 to C. So, how can I prevent OOM in this scenario? Do I've to use some kind of locks/synchronization based on how many bytes were received vs. sent? > Possible Deadlock/Out of memory when sending large amounts of data using Nio > > > Key: DIRMINA-789 > URL: https://issues.apache.org/jira/browse/DIRMINA-789 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-RC1 > Environment: Windows Vista 64-bit Java 5 and Java 6 >Reporter: Sai Pullabhotla > Attachments: MinaClient.java, RandomDataServer.java > > > This is a followup to the post on the DEV mailing list, > http://old.nabble.com/Help-needed-with-OutOfMemory-error-and-or-GC-Issues-Dead-Locks-td28849756.html. > > I've even simplified the test cases so now it just has one simple NioServer, > and an NioClient. The MinaClient class creates 5 concurrent connections to > the RandomDataServer. Upon a successful connection, the server is setup to > send 500MB worth of random text data. The MinaClient just saves the received > data to a temp file in the working directory. When I run this code with small > amounts of data, it works fine, but with 500MB, I did not have success yet. > Some times, I get OOM on the server. Some times, nothing happens. > I've declared several constants in each class that you could change to try > various settings such as changing the amount of data served by the server, > whether or not to use an executor filter/IoEventThrottle etc. > Both classes have main methods, and I was running them as stand alone > applications on the same PC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-789) Possible Deadlock/Out of memory when sending large amounts of data using Nio
[ https://issues.apache.org/jira/browse/DIRMINA-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877861#action_12877861 ] Sai Pullabhotla commented on DIRMINA-789: - If I change the line 155 in the server code - session.write(buffer); to session.write(buffer).awaitUninterruptibly(); Shouldn't that help? Apparently, it has no effect on the behavior. Any idea why? > Possible Deadlock/Out of memory when sending large amounts of data using Nio > > > Key: DIRMINA-789 > URL: https://issues.apache.org/jira/browse/DIRMINA-789 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-RC1 > Environment: Windows Vista 64-bit Java 5 and Java 6 >Reporter: Sai Pullabhotla > Attachments: MinaClient.java, RandomDataServer.java > > > This is a followup to the post on the DEV mailing list, > http://old.nabble.com/Help-needed-with-OutOfMemory-error-and-or-GC-Issues-Dead-Locks-td28849756.html. > > I've even simplified the test cases so now it just has one simple NioServer, > and an NioClient. The MinaClient class creates 5 concurrent connections to > the RandomDataServer. Upon a successful connection, the server is setup to > send 500MB worth of random text data. The MinaClient just saves the received > data to a temp file in the working directory. When I run this code with small > amounts of data, it works fine, but with 500MB, I did not have success yet. > Some times, I get OOM on the server. Some times, nothing happens. > I've declared several constants in each class that you could change to try > various settings such as changing the amount of data served by the server, > whether or not to use an executor filter/IoEventThrottle etc. > Both classes have main methods, and I was running them as stand alone > applications on the same PC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-789) Possible Deadlock/Out of memory when sending large amounts of data using Nio
[ https://issues.apache.org/jira/browse/DIRMINA-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated DIRMINA-789: Attachment: RandomDataServer.java MinaClient.java Classes to reproduce the behavior I'm seeing. > Possible Deadlock/Out of memory when sending large amounts of data using Nio > > > Key: DIRMINA-789 > URL: https://issues.apache.org/jira/browse/DIRMINA-789 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-RC1 > Environment: Windows Vista 64-bit Java 5 and Java 6 >Reporter: Sai Pullabhotla > Attachments: MinaClient.java, RandomDataServer.java > > > This is a followup to the post on the DEV mailing list, > http://old.nabble.com/Help-needed-with-OutOfMemory-error-and-or-GC-Issues-Dead-Locks-td28849756.html. > > I've even simplified the test cases so now it just has one simple NioServer, > and an NioClient. The MinaClient class creates 5 concurrent connections to > the RandomDataServer. Upon a successful connection, the server is setup to > send 500MB worth of random text data. The MinaClient just saves the received > data to a temp file in the working directory. When I run this code with small > amounts of data, it works fine, but with 500MB, I did not have success yet. > Some times, I get OOM on the server. Some times, nothing happens. > I've declared several constants in each class that you could change to try > various settings such as changing the amount of data served by the server, > whether or not to use an executor filter/IoEventThrottle etc. > Both classes have main methods, and I was running them as stand alone > applications on the same PC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-789) Possible Deadlock/Out of memory when sending large amounts of data using Nio
Possible Deadlock/Out of memory when sending large amounts of data using Nio Key: DIRMINA-789 URL: https://issues.apache.org/jira/browse/DIRMINA-789 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-RC1 Environment: Windows Vista 64-bit Java 5 and Java 6 Reporter: Sai Pullabhotla This is a followup to the post on the DEV mailing list, http://old.nabble.com/Help-needed-with-OutOfMemory-error-and-or-GC-Issues-Dead-Locks-td28849756.html. I've even simplified the test cases so now it just has one simple NioServer, and an NioClient. The MinaClient class creates 5 concurrent connections to the RandomDataServer. Upon a successful connection, the server is setup to send 500MB worth of random text data. The MinaClient just saves the received data to a temp file in the working directory. When I run this code with small amounts of data, it works fine, but with 500MB, I did not have success yet. Some times, I get OOM on the server. Some times, nothing happens. I've declared several constants in each class that you could change to try various settings such as changing the amount of data served by the server, whether or not to use an executor filter/IoEventThrottle etc. Both classes have main methods, and I was running them as stand alone applications on the same PC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-371) Create a specialized FtpReply to send to Ftplets after login finishes
[ https://issues.apache.org/jira/browse/FTPSERVER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla reassigned FTPSERVER-371: - Assignee: Sai Pullabhotla > Create a specialized FtpReply to send to Ftplets after login finishes > - > > Key: FTPSERVER-371 > URL: https://issues.apache.org/jira/browse/FTPSERVER-371 > Project: FtpServer > Issue Type: New Feature > Components: Core, Ftplets >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.1.0 > > > As an addition to https://issues.apache.org/jira/browse/FTPSERVER-253, I > think it would be nice to have a specialized reply that could be sent to the > Ftplets. The reply could include information such as the attempted user name, > password used by anonymous users, any exception that was thrown by the > UserManager during authentication. Perhaps the exception is the most > important piece that the Ftplets (like the one that does audit logging) would > like to know. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-371) Create a specialized FtpReply to send to Ftplets after login finishes
Create a specialized FtpReply to send to Ftplets after login finishes - Key: FTPSERVER-371 URL: https://issues.apache.org/jira/browse/FTPSERVER-371 Project: FtpServer Issue Type: New Feature Components: Core, Ftplets Reporter: Sai Pullabhotla Fix For: 1.1.0 As an addition to https://issues.apache.org/jira/browse/FTPSERVER-253, I think it would be nice to have a specialized reply that could be sent to the Ftplets. The reply could include information such as the attempted user name, password used by anonymous users, any exception that was thrown by the UserManager during authentication. Perhaps the exception is the most important piece that the Ftplets (like the one that does audit logging) would like to know. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-315) Pass FtpSession information to the UserManager.authenticate method
[ https://issues.apache.org/jira/browse/FTPSERVER-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857883#action_12857883 ] Sai Pullabhotla commented on FTPSERVER-315: --- As a temporary (could be permanent too) solution, what do you think of: wrapping the FtpSession in the Authentication object or in the UserMetaData? I think it makes sense to have it in the Authentication object. At least, gets the job done! > Pass FtpSession information to the UserManager.authenticate method > -- > > Key: FTPSERVER-315 > URL: https://issues.apache.org/jira/browse/FTPSERVER-315 > Project: FtpServer > Issue Type: Improvement > Components: Core, Ftplets >Reporter: Sai Pullabhotla >Priority: Minor > Fix For: 2.0.0 > > > Currently the UserManager interface has the authenticate method defined as > follows: > User authenticate(Authentication authentication) > throws AuthenticationFailedException; > I'm wondering if it would be of any benefit to change it to: > User authenticate(Authentication authentication, FtpSession session) > throws AuthenticationFailedException; > The reason(s) behind this - > I want to log a message when the login fails. The login could fail to due to > a number of reasons - such as Account is disabled, password has expired and > so on. Since I do not have the session information available from this > interface, I'm not able to log all the information that I normally do - such > as the session ID, remote address and so on. I know I can log this > information from onLogin() method of an Ftplet, but then I would not have any > information on why the login has actually failed. All I've is - 530 > Authentication Failed reply. > Another benefit would be if I want to implement my user manager based on user > name and IP address. For example let User1 login if and only if he is > connecting from IP address xxx.xxx.xxx.xxx. Not sure if any one does this > kind of authentication, but in case if some one want to, this change should > help. > More info about this feature request can be found in the thread - > http://www.mail-archive.com/dev@mina.apache.org/msg12942.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856533#action_12856533 ] Sai Pullabhotla commented on FTPSERVER-357: --- Niklas, Any preference on the package name or the existing packages that the classes should go into? > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854506#action_12854506 ] Sai Pullabhotla commented on FTPSERVER-357: --- I've refactored all classes to the way we wanted it. Now its time to decide the package name/appropriate packages for each of these classes. Currently all supporting interfaces and classes are in a package com.apache.ftpserver.ipfilter. Do you have any preferences? > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853928#action_12853928 ] Sai Pullabhotla commented on FTPSERVER-357: --- Does this change to SessionFilter need to be another JIRA or could be use the same issue as it was never shipped out? > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-362) Add a configuration option for maximum number of threads the server is allowed to create
[ https://issues.apache.org/jira/browse/FTPSERVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853915#action_12853915 ] Sai Pullabhotla commented on FTPSERVER-362: --- Okay, it is checked into the trunk. I created a patch out of the trunk, applied it to the 1.x branch, and when I do the DIFF, all new lines are messed up (converted to windows new lines). I'm not sure what the issue is, probably with the SVN plugin for MyEclipse. So, I did not check into the branch. Could one of you check it into the branch please? Thanks. > Add a configuration option for maximum number of threads the server is > allowed to create > > > Key: FTPSERVER-362 > URL: https://issues.apache.org/jira/browse/FTPSERVER-362 > Project: FtpServer > Issue Type: New Feature > Components: Core >Affects Versions: 1.0.0-M1, 1.0.0-M2, 1.0.0-M3, 1.0.0-M4, 1.0.0-RC1, > 1.0.0-RC2, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4 >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.0.5 > > Attachments: FTPSERVER-362.patch > > > Currently the max threads are defaulted to 16. Based on the discussion on the > DEV mailing list, it would be nice to make this configurable. > The thread on the mailing list is at - > http://old.nabble.com/FTPServer-handling-of-multiple-concurrent-connections.-td28079420.html. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-360) When no passive ports are available error out immediately rather than waiting for a port to become available
[ https://issues.apache.org/jira/browse/FTPSERVER-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla reassigned FTPSERVER-360: - Assignee: Sai Pullabhotla > When no passive ports are available error out immediately rather than waiting > for a port to become available > > > Key: FTPSERVER-360 > URL: https://issues.apache.org/jira/browse/FTPSERVER-360 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.4 >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.0.5 > > Attachments: FTPSERVER-360.patch > > > Based on the filed issue, http://issues.apache.org/jira/browse/FTPSERVER-359, > we probably want to quick fix the code to error out right away when no > passive port is available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla reassigned FTPSERVER-357: - Assignee: Sai Pullabhotla > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FTPSERVER-362) Add a configuration option for maximum number of threads the server is allowed to create
[ https://issues.apache.org/jira/browse/FTPSERVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla reassigned FTPSERVER-362: - Assignee: Sai Pullabhotla > Add a configuration option for maximum number of threads the server is > allowed to create > > > Key: FTPSERVER-362 > URL: https://issues.apache.org/jira/browse/FTPSERVER-362 > Project: FtpServer > Issue Type: New Feature > Components: Core >Affects Versions: 1.0.0-M1, 1.0.0-M2, 1.0.0-M3, 1.0.0-M4, 1.0.0-RC1, > 1.0.0-RC2, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4 >Reporter: Sai Pullabhotla >Assignee: Sai Pullabhotla > Fix For: 1.0.5 > > Attachments: FTPSERVER-362.patch > > > Currently the max threads are defaulted to 16. Based on the discussion on the > DEV mailing list, it would be nice to make this configurable. > The thread on the mailing list is at - > http://old.nabble.com/FTPServer-handling-of-multiple-concurrent-connections.-td28079420.html. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853525#action_12853525 ] Sai Pullabhotla commented on FTPSERVER-357: --- Cool, I can do that. I will check in the updated code sometime this week. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853522#action_12853522 ] Sai Pullabhotla commented on FTPSERVER-357: --- I like those. I will go ahead and change those names. Are we good with the spring configuration tag names etc.? The tag name is currently . Not sure if we need to change it to . > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853515#action_12853515 ] Sai Pullabhotla commented on FTPSERVER-357: --- How about calling the interface (IpFilter) as FtpSessionFilter with boolean accept(IoSession). Rename the DefaultIpFilter to ClientIpFilter or just IpFilter Or should we stick to the IpFilter notation and simply change the accept method to have two parameter representing the Socket end points? > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-365) Overload FtpIoSession.getDataConnection to indicate whether or not a new DataConnectionFactory be created
Overload FtpIoSession.getDataConnection to indicate whether or not a new DataConnectionFactory be created - Key: FTPSERVER-365 URL: https://issues.apache.org/jira/browse/FTPSERVER-365 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.4 Reporter: Sai Pullabhotla Priority: Trivial Fix For: 1.0.5 It would be nice to overload the above mentioned method with a boolean parameter which indicates if a new DataConnectionFactory is to be created. Currently, we always create one if one does not exist already for the session. We try to create one even when the session is closing (for example when the control connection is refused by the blacklist filter), which does not make much sense. Having this overloaded method would be useful when the session is closing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853469#action_12853469 ] Sai Pullabhotla commented on FTPSERVER-357: --- may not be a bad idea to just pass the IoSession to the accept() method. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853427#action_12853427 ] Sai Pullabhotla commented on FTPSERVER-357: --- I'm wondering if we need to change the signature on the IpFilter interface. Currently, it requires that - boolean accept(InetAddress address) method be implemented. While this does the job pretty good, It does not give any information about the local network interface to which the client attempted to connect. This could be important for some people for the following reasons: 1. Auditing - simply log the remote client's IP, port and local interface IP and port. 2. If some one wants to implement a filter based on the both remote and local IPs. For example, allow client X to connect on interface A, but not on B and C. If you agree with me on this, the IpFilter interface probably needs to have the below method instead of the current one: boolean accept(SocketAddress remoteAddress, SocketAddress localAddress) Your ideas and thoughts are appreciated. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-362) Add a configuration option for maximum number of threads the server is allowed to create
[ https://issues.apache.org/jira/browse/FTPSERVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-362: -- Attachment: FTPSERVER-362.patch For the most part I made the patch work like we have talked on the mailing list. However, a few things note: If max-threads is explicitly set and is a positive integer, a thread pool of specified size will be created and shared across all listeners. If max-threads is not explicitly set, but max-logins are set (explicit or implicit), then max-threads = max-logins If max-threads is not explicitly set, and if the max-logins is set to zero (0) then max-threads become 16. This is due to the fact the we consider max-logins=0 as unlimited. I had to choose some default for max-threads and picked 16. Let me know if this looks good and can be checked in. Thanks. > Add a configuration option for maximum number of threads the server is > allowed to create > > > Key: FTPSERVER-362 > URL: https://issues.apache.org/jira/browse/FTPSERVER-362 > Project: FtpServer > Issue Type: New Feature > Components: Core >Affects Versions: 1.0.0-M1, 1.0.0-M2, 1.0.0-M3, 1.0.0-M4, 1.0.0-RC1, > 1.0.0-RC2, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4 >Reporter: Sai Pullabhotla > Fix For: 1.0.5 > > Attachments: FTPSERVER-362.patch > > > Currently the max threads are defaulted to 16. Based on the discussion on the > DEV mailing list, it would be nice to make this configurable. > The thread on the mailing list is at - > http://old.nabble.com/FTPServer-handling-of-multiple-concurrent-connections.-td28079420.html. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-364) Incorrect behavior when max logins limit is reached
Incorrect behavior when max logins limit is reached --- Key: FTPSERVER-364 URL: https://issues.apache.org/jira/browse/FTPSERVER-364 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.4 Reporter: Sai Pullabhotla Priority: Minor Fix For: 1.0.5 When max logins limit is reached, the server currently behaves as below: Accepts connections from new clients and keeps them open Let's the new clients issue some commands (like I can go ahead and issue as many invalid commands as I want) When the client sends a valid USER command with username argument, the server then figures out that it has reached the max limit. I think t would probably makes sense to change the behavior as follows: When a new client comes in, check if we reached the cap, and if so, send 421 message right away, instead of sending a 2xxx reply. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-363) Incorrect Javadoc for ConnectionConfigFactory.get/setMaxAnonymousLogins
Incorrect Javadoc for ConnectionConfigFactory.get/setMaxAnonymousLogins --- Key: FTPSERVER-363 URL: https://issues.apache.org/jira/browse/FTPSERVER-363 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.4 Reporter: Sai Pullabhotla Priority: Trivial Fix For: 1.0.5 The current javadoc for the above mentioned methods is: "The maximum number of time an anonymous user can fail to login before getting disconnected" Should have been: "The maximum number of anonymous logins the server would allow at any given time". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-362) Add a configuration option for maximum number of threads the server is allowed to create
Add a configuration option for maximum number of threads the server is allowed to create Key: FTPSERVER-362 URL: https://issues.apache.org/jira/browse/FTPSERVER-362 Project: FtpServer Issue Type: New Feature Components: Core Affects Versions: 1.0.4, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 1.0.0-RC2, 1.0.0-RC1, 1.0.0-M4, 1.0.0-M3, 1.0.0-M2, 1.0.0-M1 Reporter: Sai Pullabhotla Fix For: 1.0.5 Currently the max threads are defaulted to 16. Based on the discussion on the DEV mailing list, it would be nice to make this configurable. The thread on the mailing list is at - http://old.nabble.com/FTPServer-handling-of-multiple-concurrent-connections.-td28079420.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-323) Add a new configuration option for enabling/disabling IP check when accepting passive data connections
[ https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850909#action_12850909 ] Sai Pullabhotla commented on FTPSERVER-323: --- Looks like this feature is not checked into the 1.0.x branch. Could some one look into it and see if it should be in the branch? Thanks. > Add a new configuration option for enabling/disabling IP check when accepting > passive data connections > -- > > Key: FTPSERVER-323 > URL: https://issues.apache.org/jira/browse/FTPSERVER-323 > Project: FtpServer > Issue Type: New Feature > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: FTPSERVER-323.patch > > > In the current version it is possible for a hacker to connect to any passive > port that is currently waiting for a connection and read/write data off that > connection. We should implement a check in place to make sure the IP address > of the remote host is same as the one we are expecting, if not, close the > data connection right way. After closing the data connection we can do one of > the following: > 1. Wait for incoming connection again so the original client can connect > 2. just quit and send a reply back to the client that the data connection is > closed. We need to figure out what reply we want to send in this case. > What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-360) When no passive ports are available error out immediately rather than waiting for a port to become available
[ https://issues.apache.org/jira/browse/FTPSERVER-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850734#action_12850734 ] Sai Pullabhotla commented on FTPSERVER-360: --- Okay, I think I got a test case for this. What all branches do you want this fix to go in, in addition to the trunk? A side note - I do see two branches - 1.0.4 and 1.0.x. However, I do not see a 1.0.4 tag. Did we create a branch for 1.0.4 where it should have been a tag? > When no passive ports are available error out immediately rather than waiting > for a port to become available > > > Key: FTPSERVER-360 > URL: https://issues.apache.org/jira/browse/FTPSERVER-360 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.4 >Reporter: Sai Pullabhotla > Fix For: 1.0.5 > > Attachments: FTPSERVER-360.patch > > > Based on the filed issue, http://issues.apache.org/jira/browse/FTPSERVER-359, > we probably want to quick fix the code to error out right away when no > passive port is available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-360) When no passive ports are available error out immediately rather than waiting for a port to become available
[ https://issues.apache.org/jira/browse/FTPSERVER-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850728#action_12850728 ] Sai Pullabhotla commented on FTPSERVER-360: --- Niklas, Are you looking for a "client" test case, to actually connect to the server and try opening passive connections? Otherwise, the current test cases are good enough. > When no passive ports are available error out immediately rather than waiting > for a port to become available > > > Key: FTPSERVER-360 > URL: https://issues.apache.org/jira/browse/FTPSERVER-360 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.4 >Reporter: Sai Pullabhotla > Fix For: 1.0.5 > > Attachments: FTPSERVER-360.patch > > > Based on the filed issue, http://issues.apache.org/jira/browse/FTPSERVER-359, > we probably want to quick fix the code to error out right away when no > passive port is available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-360) When no passive ports are available error out immediately rather than waiting for a port to become available
[ https://issues.apache.org/jira/browse/FTPSERVER-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-360: -- Attachment: FTPSERVER-360.patch Here is a patch to try out to see if the server locks up as reported in the issue 359. This patch error out immediately when no passive ports are available. This is mainly for testing with the test case provided the submitter of FTPSERVER-359. Not sure if it is ready to be included in the code base. > When no passive ports are available error out immediately rather than waiting > for a port to become available > > > Key: FTPSERVER-360 > URL: https://issues.apache.org/jira/browse/FTPSERVER-360 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.4 >Reporter: Sai Pullabhotla > Fix For: 1.0.5 > > Attachments: FTPSERVER-360.patch > > > Based on the filed issue, http://issues.apache.org/jira/browse/FTPSERVER-359, > we probably want to quick fix the code to error out right away when no > passive port is available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-360) When no passive ports are available error out immediately rather than waiting for a port to become available
When no passive ports are available error out immediately rather than waiting for a port to become available Key: FTPSERVER-360 URL: https://issues.apache.org/jira/browse/FTPSERVER-360 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.4 Reporter: Sai Pullabhotla Fix For: 1.0.5 Based on the filed issue, http://issues.apache.org/jira/browse/FTPSERVER-359, we probably want to quick fix the code to error out right away when no passive port is available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-357: -- Attachment: ftpserver-ipfilter2.patch Here is the take 2. Hope this is better than the previous one and preserves the backward compatibility. I still have to do some more testing and update any test cases, but this should be good to start reviewing/testing. Let me know of any comments/suggestions. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch, ftpserver-ipfilter2.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847396#action_12847396 ] Sai Pullabhotla commented on FTPSERVER-357: --- Well, I don't think we can guarantee an accurate result if we start pulling Inets/Subnets from the new IpFilter. What I mean by accuarate result is, the returned list may not be the same as the one they have been getting with the current public release. This due to the fact that the new filter just maintains everything as Subnets. I think I'm going to cheat here by having a couple of "never used" member variables in AbstractListener which contain the list of InetAddress/Subnets and return them right away. What do you think? > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847377#action_12847377 ] Sai Pullabhotla commented on FTPSERVER-357: --- Well, I thought about that possibility. We can do it if we enforce the filter type in the IpFilter interface. Right now, the IpFilter has just one method, accept(). We could add getType() method which would return a type too. But I hate to enforce this at the interface level, which may not make sense when implementing custom filters where they do not care about the type or the type of the filter does not fall into the categories we support (DENY/ALLOW). The best we could do is, check to see if IpFilter is an instance of DefaultIpFilter, if so, check if it is of type DENY, and then return the list. Return null/blank list in all other cases. Hope it makes sense. Let me know what you think of this approach or any other ideas you may have. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847365#action_12847365 ] Sai Pullabhotla commented on FTPSERVER-357: --- Okay guys, I think I updated the ListenerFactory to have the old methods and marked them as deprecated. If the blockedAddresses or blockedSubnets are specified on the factory, they cannot set ipFilter. In other words, ipFilter and blocked* are mutually exclusive. If both are set, calling the createListener would raise an exception. This is similar to what I did with the spring configuration. Let me know if this is okay with you. Also, the Listener interface has getBlocked* methods. Do we want to make these available too? I don't think this is possible, especially when there is a custom filter. At the same time, I doubt if anybody is working directly with listeners. Let me know what you think. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847107#action_12847107 ] Sai Pullabhotla commented on FTPSERVER-357: --- I think I can get it to work with the old methods and constructors in the factory classes. Just wanted to get it going so, the quickest way was to remove/change signatures. I will look into it some more and let you know. I will double check the AbstractListener and see if I formatted the whole class. If I did, I will re-apply may changes to the version from trunk. Yeah, the FileSystem class changes were an accidental inclusion in the patch. I might open a new thread on this as I think it would be nice to have some of these member variables accessible in subclasses. It was a while ago I was playing with a subclass and needed those. I'll have to rewind and figure out what I was doing then. I don't think the DefaultIpFilter needs to be immutable. The class is extended from a Set that makes a copy of the Set on every change to the Set, so it is safe to modify the Set while an iterator is iterating over the items. Of course, I stole the idea from the existing filter in MINA. If everything else looks okay, and if you think the package/class names are good as they are, I will go ahead and try to wrap this up this week. Regards, Sai Pullabhotla On Thu, Mar 18, 2010 at 2:54 PM, Niklas Gustavsson (JIRA) > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847103#action_12847103 ] Sai Pullabhotla commented on FTPSERVER-357: --- I think I can get it to work with the old methods and constructors in the factory classes. Just wanted to get it going so, the quickest way was to remove/change signatures. I will look into it some more and let you know. I will double check the AbstractListener and see if I formatted the whole class. If I did, I will re-apply may changes to the version from trunk. Yeah, the FileSystem class changes were an accidental inclusion in the patch. I might open a new thread on this as I think it would be nice to have some of these member variables accessible in subclasses. It was a while ago I was playing with a subclass and needed those. I'll have to rewind and figure out what I was doing then. I don't think the DefaultIpFilter needs to be immutable. The class is extended from a Set that makes a copy of the Set on every change to the Set, so it is safe to modify the Set while an iterator is iterating over the items. Of course, I stole the idea from the existing filter in MINA. If everything else looks okay, and if you think the package/class names are good as they are, I will go ahead and try to wrap this up this week. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847102#action_12847102 ] Sai Pullabhotla commented on FTPSERVER-357: --- Oh, BTW, I missed an else block in the DefaultIpFilter.add(String) method which should have been there to filter a specific IP address. It's in now in my local copy. Just an FYI. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-357) Implement IP Filtering based on black or white list
[ https://issues.apache.org/jira/browse/FTPSERVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-357: -- Attachment: ftpserver-ipfilter.patch Please review this and provide your feedback. > Implement IP Filtering based on black or white list > --- > > Key: FTPSERVER-357 > URL: https://issues.apache.org/jira/browse/FTPSERVER-357 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: ftpserver-ipfilter.patch > > > Create a new IP Filter based on black or white list to deny or allow incoming > client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-357) Implement IP Filtering based on black or white list
Implement IP Filtering based on black or white list --- Key: FTPSERVER-357 URL: https://issues.apache.org/jira/browse/FTPSERVER-357 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Sai Pullabhotla Fix For: 1.1.0 Create a new IP Filter based on black or white list to deny or allow incoming client connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-345) Update the replies of MD5 and MMD5 commands to include the file path in double quotes when there are spaces in the path
[ https://issues.apache.org/jira/browse/FTPSERVER-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla resolved FTPSERVER-345. --- Resolution: Fixed Fix Version/s: 1.1.0 Committed the fix to trunk and 1.0.x branch. > Update the replies of MD5 and MMD5 commands to include the file path in > double quotes when there are spaces in the path > --- > > Key: FTPSERVER-345 > URL: https://issues.apache.org/jira/browse/FTPSERVER-345 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.3 >Reporter: Sai Pullabhotla >Priority: Minor > Fix For: 1.0.4, 1.1.0 > > > Even though the RFC does not explicitly say this, the example replies showed > in the RFC enclose all file paths in double quotes. I'm not sure if there are > any FTP clients that look for double quotes presence. A smart FTP client > could always grab the checksum from the last token in the reply, where each > token is separated by one or more white spaces. In order to offer best > compatibility, I would recommend enclosing the file paths in double quotes > when they contain any spaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-345) Update the replies of MD5 and MMD5 commands to include the file path in double quotes when there are spaces in the path
Update the replies of MD5 and MMD5 commands to include the file path in double quotes when there are spaces in the path --- Key: FTPSERVER-345 URL: https://issues.apache.org/jira/browse/FTPSERVER-345 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.3 Reporter: Sai Pullabhotla Priority: Minor Fix For: 1.0.4 Even though the RFC does not explicitly say this, the example replies showed in the RFC enclose all file paths in double quotes. I'm not sure if there are any FTP clients that look for double quotes presence. A smart FTP client could always grab the checksum from the last token in the reply, where each token is separated by one or more white spaces. In order to offer best compatibility, I would recommend enclosing the file paths in double quotes when they contain any spaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-326) LIST command does not work right with hidden files
[ https://issues.apache.org/jira/browse/FTPSERVER-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757872#action_12757872 ] Sai Pullabhotla commented on FTPSERVER-326: --- I think the attached patch should do what you outlined. Would you be able to merge it into the appropriate branch(es). I just don't feel comfortable working with the branches yet. I do not want to mess up things accidentally. > LIST command does not work right with hidden files > -- > > Key: FTPSERVER-326 > URL: https://issues.apache.org/jira/browse/FTPSERVER-326 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Priority: Minor > Fix For: 1.0.3 > > Attachments: FTPSERVER-326.patch > > > It appears that the LIST command does not work quite right with hidden files. > My testing on a Windows system gave the following results: > (1) a simple LIST command with no arguments, returns the list of all children > (including hidden files) > (2) LIST -la or LIST -a command returns all files that are NOT hidden > I think the behavior should be the other way round; i.e. (1) should return > all children that are not hidden and (2) should return all children including > the hidden ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-326) LIST command does not work right with hidden files
[ https://issues.apache.org/jira/browse/FTPSERVER-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754121#action_12754121 ] Sai Pullabhotla commented on FTPSERVER-326: --- Any one has any comments on the MLS* command behavior with hidden files? The RFCs really does not say anything. > LIST command does not work right with hidden files > -- > > Key: FTPSERVER-326 > URL: https://issues.apache.org/jira/browse/FTPSERVER-326 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Priority: Minor > Fix For: 1.0.3 > > Attachments: FTPSERVER-326.patch > > > It appears that the LIST command does not work quite right with hidden files. > My testing on a Windows system gave the following results: > (1) a simple LIST command with no arguments, returns the list of all children > (including hidden files) > (2) LIST -la or LIST -a command returns all files that are NOT hidden > I think the behavior should be the other way round; i.e. (1) should return > all children that are not hidden and (2) should return all children including > the hidden ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-327) breaking RFC by replying 150 after establishing data connection
[
https://issues.apache.org/jira/browse/FTPSERVER-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752486#action_12752486
]
Sai Pullabhotla commented on FTPSERVER-327:
---
Even though you are connecting to the passive IP and Port before a
data transfer command is issued (STOR, RETR etc), the server in fact
does not accept the connection until a data transfer command is
issued. In other words, on the server side there is no Socket open
until you send the STOR command. This means that sending 150 reply is
correct. Do you agree?
> breaking RFC by replying 150 after establishing data connection
> ---
>
> Key: FTPSERVER-327
> URL: https://issues.apache.org/jira/browse/FTPSERVER-327
> Project: FtpServer
> Issue Type: Bug
> Components: Server
>Affects Versions: 1.0.2
> Environment: RHEL3
>Reporter: Parijat Bansal
>Priority: Minor
>
> Hi,
> RFC 959 explains 125 and 150 (valid intermediate responses for STOR/RETR) as
> follows:
> 125 Data connection already open; transfer starting.
> 150 File status okay; about to open data connection.
> If the data connection is already estabilished and after it the server
> receives STOR/RETR then it should respond with 125. I connected in passive
> mode using my custom client to verify this. I first estabilished a data
> channel and after it only I sent STOR but still got 150 which is wrong.
> Following is part of my code :
>data = new Socket(pasv_ip, pasv_port);
>data_os = data.getOutputStream();
>data_is = data.getInputStream();
>control_os.print("STOR " + "file.txt" + "\r\n");
>System.out.print("---> STOR " + "file.txt" + "\n");
>control_os.flush();
>System.out.println(control_is.readLine());
> However if I tried sending STOR before establishing data channel then also I
> received 150 which seems ok as per RFC.
> Regards,
> Parijat Bansal
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-330) Timestamp values returned by various extension commands such as MDTM, MLSD are incorrect
Timestamp values returned by various extension commands such as MDTM, MLSD are incorrect Key: FTPSERVER-330 URL: https://issues.apache.org/jira/browse/FTPSERVER-330 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Fix For: 1.1.0 Various extension commands such as MDTM, MLSD, MLST etc return incorrect timestamp values. The RFC indicates that all timestamp values must be in UTC (GMT). The current version returns these values in local timezone. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-328) Make FTPReply implementation constructors to be public
[ https://issues.apache.org/jira/browse/FTPSERVER-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla resolved FTPSERVER-328. --- Resolution: Fixed > Make FTPReply implementation constructors to be public > -- > > Key: FTPSERVER-328 > URL: https://issues.apache.org/jira/browse/FTPSERVER-328 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > > Currently, various FTPReply implementations hide their constructors from > public use. It would be nice to allow these objects to be instantiated from > external code such as Ftplets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-328) Make FTPReply implementation constructors to be public
[ https://issues.apache.org/jira/browse/FTPSERVER-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-328: -- Component/s: Core > Make FTPReply implementation constructors to be public > -- > > Key: FTPSERVER-328 > URL: https://issues.apache.org/jira/browse/FTPSERVER-328 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > > Currently, various FTPReply implementations hide their constructors from > public use. It would be nice to allow these objects to be instantiated from > external code such as Ftplets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-323) Add a new configuration option for enabling/disabling IP check when accepting passive data connections
[ https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla resolved FTPSERVER-323. --- Resolution: Fixed > Add a new configuration option for enabling/disabling IP check when accepting > passive data connections > -- > > Key: FTPSERVER-323 > URL: https://issues.apache.org/jira/browse/FTPSERVER-323 > Project: FtpServer > Issue Type: New Feature > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: FTPSERVER-323.patch > > > In the current version it is possible for a hacker to connect to any passive > port that is currently waiting for a connection and read/write data off that > connection. We should implement a check in place to make sure the IP address > of the remote host is same as the one we are expecting, if not, close the > data connection right way. After closing the data connection we can do one of > the following: > 1. Wait for incoming connection again so the original client can connect > 2. just quit and send a reply back to the client that the data connection is > closed. We need to figure out what reply we want to send in this case. > What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-323) Add a new configuration option for enabling/disabling IP check when accepting passive data connections
[ https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-323: -- Component/s: Core Issue Type: New Feature (was: Bug) Summary: Add a new configuration option for enabling/disabling IP check when accepting passive data connections (was: Passive Data connections should check the remote IP address before starting the data transfer) Changed the title to better match the resolution we came up with. > Add a new configuration option for enabling/disabling IP check when accepting > passive data connections > -- > > Key: FTPSERVER-323 > URL: https://issues.apache.org/jira/browse/FTPSERVER-323 > Project: FtpServer > Issue Type: New Feature > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: FTPSERVER-323.patch > > > In the current version it is possible for a hacker to connect to any passive > port that is currently waiting for a connection and read/write data off that > connection. We should implement a check in place to make sure the IP address > of the remote host is same as the one we are expecting, if not, close the > data connection right way. After closing the data connection we can do one of > the following: > 1. Wait for incoming connection again so the original client can connect > 2. just quit and send a reply back to the client that the data connection is > closed. We need to figure out what reply we want to send in this case. > What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-253) Enhance the Ftplet.afterCommand to provide more information about the result of command execution
[ https://issues.apache.org/jira/browse/FTPSERVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla resolved FTPSERVER-253. --- Resolution: Fixed > Enhance the Ftplet.afterCommand to provide more information about the result > of command execution > - > > Key: FTPSERVER-253 > URL: https://issues.apache.org/jira/browse/FTPSERVER-253 > Project: FtpServer > Issue Type: New Feature > Components: Core, Ftplets >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: FTPSERVER-253_Patch.txt > > > It would be nice to enhance the afterCommand method in the Ftplet to provide > additional details about the result of command execution. Currently the > afterCommand method of an Ftplet is called back with the following parameters > - > FtpSession, FtpRequest and FtpReply. The FtpReply parameter contains only the > reply code and the reply string that was sent. The Ftplets may want to know a > little more information on what exactly happened to the command that was > executed. For example, the afterCommand for RNTO command might want to know > the from file, the to file and if the command was successful or not. > More information on this can be found at > http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-322) Cache SSLContext and SSLSocketFacotry for each SSLConfiguration
[ https://issues.apache.org/jira/browse/FTPSERVER-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla resolved FTPSERVER-322. --- Resolution: Fixed > Cache SSLContext and SSLSocketFacotry for each SSLConfiguration > --- > > Key: FTPSERVER-322 > URL: https://issues.apache.org/jira/browse/FTPSERVER-322 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > > FTPS performance could be better if we cache the SSLContext and > SSLSocketFactory for each SslConfiguration. Current code creates SSLContext > everytime a SSL connection has to be created, initializes the SSLContext > using the TrustManagers and KeyManagers and then creates the > SSLSocketFactory. Cache the SSLSocketFactory instead and reuse it when > needed. For more information please see this thread on the developers' > mailing list http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-321) Typo in the log message
[
https://issues.apache.org/jira/browse/FTPSERVER-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sai Pullabhotla resolved FTPSERVER-321.
---
Resolution: Fixed
Fix Version/s: (was: 1.0.3)
1.1.0
> Typo in the log message
> ---
>
> Key: FTPSERVER-321
> URL: https://issues.apache.org/jira/browse/FTPSERVER-321
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.2
>Reporter: Sai Pullabhotla
>Priority: Trivial
> Fix For: 1.1.0
>
>
> Fix the typo in DataConnectionConfig class on the following log message:
> log.info("We're waiting for a passive part, might be stuck");
> passive part should have been passive port.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FTPSERVER-320) Passive Data connections are slow when using SSL
[ https://issues.apache.org/jira/browse/FTPSERVER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla resolved FTPSERVER-320. --- Resolution: Fixed Fix Version/s: (was: 1.0.3) 1.1.0 > Passive Data connections are slow when using SSL > > > Key: FTPSERVER-320 > URL: https://issues.apache.org/jira/browse/FTPSERVER-320 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > > Creation of passive data sockets is slow when using SSL. The issue is that > the code calls InetAddress.getHostName() method which performs a reverse name > lookup. This is an expensive operation (at least on all the systems I've > tried). We really don't have a need to get the host name, so change the code > to get string version of the IP address and use it instead. More information > on this issue is available at > http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-326) LIST command does not work right with hidden files
[ https://issues.apache.org/jira/browse/FTPSERVER-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-326: -- Attachment: FTPSERVER-326.patch This is the fix for handling hidden files correctly. The fix is actually pretty simple. I could not create a test case for this as I do not have access to *NIX. However, I did some manual testing and things seem to be working as expected. I've a couple of questions/comments * This fix also affects the NLST command. NLST command now includes hidden files if and only if option "a" is present. * This fix also affects MLSD command, which always ignores hidden files. Previous versions were listing hidden files always. Do you think it is okay or should we change the MLSD to do what it was doing - list all files? * If we hide hidden files in MLSD, what should the "MLST hiddenfile" command do? Currently it still prints the attributes of the file. > LIST command does not work right with hidden files > -- > > Key: FTPSERVER-326 > URL: https://issues.apache.org/jira/browse/FTPSERVER-326 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Priority: Minor > Fix For: 1.0.3 > > Attachments: FTPSERVER-326.patch > > > It appears that the LIST command does not work quite right with hidden files. > My testing on a Windows system gave the following results: > (1) a simple LIST command with no arguments, returns the list of all children > (including hidden files) > (2) LIST -la or LIST -a command returns all files that are NOT hidden > I think the behavior should be the other way round; i.e. (1) should return > all children that are not hidden and (2) should return all children including > the hidden ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-323) Passive Data connections should check the remote IP address before starting the data transfer
[ https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747422#action_12747422 ] Sai Pullabhotla commented on FTPSERVER-323: --- Okay, the code is checked in for #323. I opened a new case for the constructors. Thanks. Sai Pullabhotla www.jMethods.com On Tue, Aug 25, 2009 at 7:37 AM, Niklas Gustavsson > Passive Data connections should check the remote IP address before starting > the data transfer > - > > Key: FTPSERVER-323 > URL: https://issues.apache.org/jira/browse/FTPSERVER-323 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: FTPSERVER-323.patch > > > In the current version it is possible for a hacker to connect to any passive > port that is currently waiting for a connection and read/write data off that > connection. We should implement a check in place to make sure the IP address > of the remote host is same as the one we are expecting, if not, close the > data connection right way. After closing the data connection we can do one of > the following: > 1. Wait for incoming connection again so the original client can connect > 2. just quit and send a reply back to the client that the data connection is > closed. We need to figure out what reply we want to send in this case. > What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-328) Make FTPReply implementation constructors to be public
Make FTPReply implementation constructors to be public -- Key: FTPSERVER-328 URL: https://issues.apache.org/jira/browse/FTPSERVER-328 Project: FtpServer Issue Type: New Feature Reporter: Sai Pullabhotla Fix For: 1.1.0 Currently, various FTPReply implementations hide their constructors from public use. It would be nice to allow these objects to be instantiated from external code such as Ftplets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-323) Passive Data connections should check the remote IP address before starting the data transfer
[ https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747367#action_12747367 ] Sai Pullabhotla commented on FTPSERVER-323: --- I will fix the typo. The public constructors in the FtpReply implementations do not have anything to do with this issue. I was going to open a new issue for that. I think it would be nice to have the constructors public so Ftplets can create and send specific type of reply. I currently do this in one of my Ftplets and then I've some code that takes the reply object and does audit logging. So, basically, my audit logger is built around FtpRequest, Session and FtpReply objects. Hope it makes sense. Let me know what you think. Sai Pullabhotla www.jMethods.com On Tue, Aug 25, 2009 at 2:07 AM, Niklas Gustavsson > Passive Data connections should check the remote IP address before starting > the data transfer > - > > Key: FTPSERVER-323 > URL: https://issues.apache.org/jira/browse/FTPSERVER-323 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: FTPSERVER-323.patch > > > In the current version it is possible for a hacker to connect to any passive > port that is currently waiting for a connection and read/write data off that > connection. We should implement a check in place to make sure the IP address > of the remote host is same as the one we are expecting, if not, close the > data connection right way. After closing the data connection we can do one of > the following: > 1. Wait for incoming connection again so the original client can connect > 2. just quit and send a reply back to the client that the data connection is > closed. We need to figure out what reply we want to send in this case. > What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-326) LIST command does not work right with hidden files
[ https://issues.apache.org/jira/browse/FTPSERVER-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746858#action_12746858 ] Sai Pullabhotla commented on FTPSERVER-326: --- I was thinking of fixing this if you agree with me. Let me know. Thanks. > LIST command does not work right with hidden files > -- > > Key: FTPSERVER-326 > URL: https://issues.apache.org/jira/browse/FTPSERVER-326 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Priority: Minor > Fix For: 1.0.3 > > > It appears that the LIST command does not work quite right with hidden files. > My testing on a Windows system gave the following results: > (1) a simple LIST command with no arguments, returns the list of all children > (including hidden files) > (2) LIST -la or LIST -a command returns all files that are NOT hidden > I think the behavior should be the other way round; i.e. (1) should return > all children that are not hidden and (2) should return all children including > the hidden ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-323) Passive Data connections should check the remote IP address before starting the data transfer
[ https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-323: -- Attachment: FTPSERVER-323.patch Thought it is a good idea to have you guys review before I check this in. Let me know if this looks alright. Thanks. > Passive Data connections should check the remote IP address before starting > the data transfer > - > > Key: FTPSERVER-323 > URL: https://issues.apache.org/jira/browse/FTPSERVER-323 > Project: FtpServer > Issue Type: Bug >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla > Fix For: 1.1.0 > > Attachments: FTPSERVER-323.patch > > > In the current version it is possible for a hacker to connect to any passive > port that is currently waiting for a connection and read/write data off that > connection. We should implement a check in place to make sure the IP address > of the remote host is same as the one we are expecting, if not, close the > data connection right way. After closing the data connection we can do one of > the following: > 1. Wait for incoming connection again so the original client can connect > 2. just quit and send a reply back to the client that the data connection is > closed. We need to figure out what reply we want to send in this case. > What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-326) LIST command does not work right with hidden files
LIST command does not work right with hidden files -- Key: FTPSERVER-326 URL: https://issues.apache.org/jira/browse/FTPSERVER-326 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Priority: Minor Fix For: 1.0.3 It appears that the LIST command does not work quite right with hidden files. My testing on a Windows system gave the following results: (1) a simple LIST command with no arguments, returns the list of all children (including hidden files) (2) LIST -la or LIST -a command returns all files that are NOT hidden I think the behavior should be the other way round; i.e. (1) should return all children that are not hidden and (2) should return all children including the hidden ones. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-323) Passive Data connections should check the remote IP address before starting the data transfer
Passive Data connections should check the remote IP address before starting the data transfer - Key: FTPSERVER-323 URL: https://issues.apache.org/jira/browse/FTPSERVER-323 Project: FtpServer Issue Type: Bug Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Fix For: 1.1.0 In the current version it is possible for a hacker to connect to any passive port that is currently waiting for a connection and read/write data off that connection. We should implement a check in place to make sure the IP address of the remote host is same as the one we are expecting, if not, close the data connection right way. After closing the data connection we can do one of the following: 1. Wait for incoming connection again so the original client can connect 2. just quit and send a reply back to the client that the data connection is closed. We need to figure out what reply we want to send in this case. What do you guys think we should do? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-322) Cache SSLContext and SSLSocketFacotry for each SSLConfiguration
Cache SSLContext and SSLSocketFacotry for each SSLConfiguration --- Key: FTPSERVER-322 URL: https://issues.apache.org/jira/browse/FTPSERVER-322 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Fix For: 1.1.0 FTPS performance could be better if we cache the SSLContext and SSLSocketFactory for each SslConfiguration. Current code creates SSLContext everytime a SSL connection has to be created, initializes the SSLContext using the TrustManagers and KeyManagers and then creates the SSLSocketFactory. Cache the SSLSocketFactory instead and reuse it when needed. For more information please see this thread on the developers' mailing list http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-321) Typo in the log message
Typo in the log message
---
Key: FTPSERVER-321
URL: https://issues.apache.org/jira/browse/FTPSERVER-321
Project: FtpServer
Issue Type: Bug
Components: Core
Affects Versions: 1.0.2
Reporter: Sai Pullabhotla
Priority: Trivial
Fix For: 1.0.3
Fix the typo in DataConnectionConfig class on the following log message:
log.info("We're waiting for a passive part, might be stuck");
passive part should have been passive port.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-320) Passive Data connections are slow when using SSL
Passive Data connections are slow when using SSL Key: FTPSERVER-320 URL: https://issues.apache.org/jira/browse/FTPSERVER-320 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Fix For: 1.0.3 Creation of passive data sockets is slow when using SSL. The issue is that the code calls InetAddress.getHostName() method which performs a reverse name lookup. This is an expensive operation (at least on all the systems I've tried). We really don't have a need to get the host name, so change the code to get string version of the IP address and use it instead. More information on this issue is available at http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-318) Subclasses of FtpException ignore the Throwable parameter in their constructors
Subclasses of FtpException ignore the Throwable parameter in their constructors --- Key: FTPSERVER-318 URL: https://issues.apache.org/jira/browse/FTPSERVER-318 Project: FtpServer Issue Type: Bug Components: Core, Ftplets Affects Versions: 1.0.2 Reporter: Sai Pullabhotla Priority: Minor Fix For: 1.0.3 Currently there are two subclasses of FtpException - 1) AuthenticationFailedException 2) DataConnectionException The constructors AuthenticationFailedException(String msg, Throwable th) and DataConnectionException(final String msg, final Throwable th) ignore (do not use) the second parameter, "th". The parameter "th" should be passed to the constructor of super class to have accurate stack trace. Also, out of curiosity, why does the FtpException has a member variable named "throwable" for storing the cause instead of using the cause defined in java.lang.Throwable? Why were the printStackTrace methods overridden? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-315) Pass FtpSession information to the UserManager.authenticate method
[ https://issues.apache.org/jira/browse/FTPSERVER-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725145#action_12725145 ] Sai Pullabhotla commented on FTPSERVER-315: --- Another reason where this change would be useful is: If I want to force some users (not all) log in to the FTPS server using client certificate and passwords, I could use the FtpSession.getClientCertificates() method in the authenticate method to determine if the user should be allowed access or not. > Pass FtpSession information to the UserManager.authenticate method > -- > > Key: FTPSERVER-315 > URL: https://issues.apache.org/jira/browse/FTPSERVER-315 > Project: FtpServer > Issue Type: Improvement > Components: Core, Ftplets >Reporter: Sai Pullabhotla >Priority: Minor > Fix For: 2.0.0 > > > Currently the UserManager interface has the authenticate method defined as > follows: > User authenticate(Authentication authentication) > throws AuthenticationFailedException; > I'm wondering if it would be of any benefit to change it to: > User authenticate(Authentication authentication, FtpSession session) > throws AuthenticationFailedException; > The reason(s) behind this - > I want to log a message when the login fails. The login could fail to due to > a number of reasons - such as Account is disabled, password has expired and > so on. Since I do not have the session information available from this > interface, I'm not able to log all the information that I normally do - such > as the session ID, remote address and so on. I know I can log this > information from onLogin() method of an Ftplet, but then I would not have any > information on why the login has actually failed. All I've is - 530 > Authentication Failed reply. > Another benefit would be if I want to implement my user manager based on user > name and IP address. For example let User1 login if and only if he is > connecting from IP address xxx.xxx.xxx.xxx. Not sure if any one does this > kind of authentication, but in case if some one want to, this change should > help. > More info about this feature request can be found in the thread - > http://www.mail-archive.com/dev@mina.apache.org/msg12942.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-315) Pass FtpSession information to the UserManager.authenticate method
Pass FtpSession information to the UserManager.authenticate method -- Key: FTPSERVER-315 URL: https://issues.apache.org/jira/browse/FTPSERVER-315 Project: FtpServer Issue Type: Improvement Components: Core, Ftplets Reporter: Sai Pullabhotla Priority: Minor Fix For: 2.0.0 Currently the UserManager interface has the authenticate method defined as follows: User authenticate(Authentication authentication) throws AuthenticationFailedException; I'm wondering if it would be of any benefit to change it to: User authenticate(Authentication authentication, FtpSession session) throws AuthenticationFailedException; The reason(s) behind this - I want to log a message when the login fails. The login could fail to due to a number of reasons - such as Account is disabled, password has expired and so on. Since I do not have the session information available from this interface, I'm not able to log all the information that I normally do - such as the session ID, remote address and so on. I know I can log this information from onLogin() method of an Ftplet, but then I would not have any information on why the login has actually failed. All I've is - 530 Authentication Failed reply. Another benefit would be if I want to implement my user manager based on user name and IP address. For example let User1 login if and only if he is connecting from IP address xxx.xxx.xxx.xxx. Not sure if any one does this kind of authentication, but in case if some one want to, this change should help. More info about this feature request can be found in the thread - http://www.mail-archive.com/dev@mina.apache.org/msg12942.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
[ https://issues.apache.org/jira/browse/FTPSERVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713055#action_12713055 ] Sai Pullabhotla commented on FTPSERVER-304: --- gets You wrote: Not sure what you meant by that. currently, if the user's timeout is set to zero, the session never times out. It does not use the listener's timeout. I think most/all FTP servers that I've worked with have a global timeout option that can be overriddden at a user level. Have not seen the "max-idle-time" option. So, I guess, we should treat our listener timeout as default-timeout instead of max-timeout. It would help if other users in the group throw in their ideas too. Sai Pullabhotla www.jMethods.com On Mon, May 25, 2009 at 2:18 PM, Niklas Gustavsson (JIRA) wrote: > The Idle Timeout set in the listener configuration does not have any effect > --- > > Key: FTPSERVER-304 > URL: https://issues.apache.org/jira/browse/FTPSERVER-304 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.1 >Reporter: Sai Pullabhotla > Fix For: 1.0.2 > > > As reported on the mailing list by Johannes, I confirmed that the idle > timeout set on the listener factory did not have any effect. The > connection/session is still good long after the specified idle timeout. As > far as I can remember this used to work fine in pre-1.0 releases. We also > have to make sure that the idle timeout on the data connections works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
[ https://issues.apache.org/jira/browse/FTPSERVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712602#action_12712602 ] Sai Pullabhotla commented on FTPSERVER-304: --- Well...The impression I get by looking at the configuration options/reading the documentation is that the "idle-timeout" parameter is *NOT* the max-idle-time, but is the *default* timeout. Below is the snippet from the documentation: idle-timeout - The number of seconds before an inactive client is disconnected Basically we should be able to support the following: * There should be a way on "User" records which tells us that the user gets the default timeout which is defined on the listener. Since the timeout on User records is an integer, it has to be a value that is less than 0. 0 would mean infinite and a positive number implies a finite timeout. * Ability to override the timeout on a per user basis. This could be less than the default timeout, greater than the default timeout or infinite timeout. For example, all "admin" level users might want to have infinite timeout even though the default timeout is set to 300. I'm not sure if it is of much advantage to support 'max-idle-timeout' (if we do the above two), but if you think it is, then we should perhaps add another configuration option for max-idle-timeout keeping the existing one as default timeout. Hope this makes sense. Let me know what you think. Sai Pullabhotla www.jMethods.com On Sun, May 24, 2009 at 1:37 PM, Niklas Gustavsson (JIRA) > The Idle Timeout set in the listener configuration does not have any effect > --- > > Key: FTPSERVER-304 > URL: https://issues.apache.org/jira/browse/FTPSERVER-304 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.1 >Reporter: Sai Pullabhotla > Fix For: 1.0.2 > > > As reported on the mailing list by Johannes, I confirmed that the idle > timeout set on the listener factory did not have any effect. The > connection/session is still good long after the specified idle timeout. As > far as I can remember this used to work fine in pre-1.0 releases. We also > have to make sure that the idle timeout on the data connections works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
[ https://issues.apache.org/jira/browse/FTPSERVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712601#action_12712601 ] Sai Pullabhotla commented on FTPSERVER-304: --- Well...The impression I get by looking at the configuration options/reading the documentation is that the "idle-timeout" parameter is *NOT* the max-idle-time, but is the *default* timeout. Below is the snippet from the documentation: idle-timeout - The number of seconds before an inactive client is disconnected Basically we should be able to support the following: * There should be a way on "User" records which tells us that the user gets the default timeout which is defined on the listener. Since the timeout on User records is an integer, it has to be a value that is less than 0. 0 would mean infinite and a positive number implies a finite timeout. * Ability to override the timeout on a per user basis. This could be less than the default timeout, greater than the default timeout or infinite timeout. For example, all "admin" level users might want to have infinite timeout even though the default timeout is set to 300. I'm not sure if it is of much advantage to support 'max-idle-timeout' (if we do the above two), but if you think it is, then we should perhaps add another configuration option for max-idle-timeout keeping the existing one as default timeout. Hope this makes sense. Let me know what you think. > The Idle Timeout set in the listener configuration does not have any effect > --- > > Key: FTPSERVER-304 > URL: https://issues.apache.org/jira/browse/FTPSERVER-304 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.1 >Reporter: Sai Pullabhotla > Fix For: 1.0.2 > > > As reported on the mailing list by Johannes, I confirmed that the idle > timeout set on the listener factory did not have any effect. The > connection/session is still good long after the specified idle timeout. As > far as I can remember this used to work fine in pre-1.0 releases. We also > have to make sure that the idle timeout on the data connections works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
[ https://issues.apache.org/jira/browse/FTPSERVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712570#action_12712570 ] Sai Pullabhotla commented on FTPSERVER-304: --- It appears to have been implemented just like how you described. In my case, I've my listener timeout set to 300 seconds (upper limit) and all users' timeout is set to 0. The third point you mentioned - * If the users limit is smaller than the listeners, it is used. 0 is numerically smaller than 300, but when talking about Java timeouts, 0 (infinite) is greater than 300. Is this correct? Also, It would be nice in some cases for all users to just inherit the listener timeout. So, today my network policy is all connections would timeout after 300 seconds of idle time. After a month, my network policy changes and want all connections to timeout in 120 seconds. In this case, If I've 500 users, I've to update all 500 user records, which is a lot of work. How can we support this? > The Idle Timeout set in the listener configuration does not have any effect > --- > > Key: FTPSERVER-304 > URL: https://issues.apache.org/jira/browse/FTPSERVER-304 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.1 >Reporter: Sai Pullabhotla > Fix For: 1.0.2 > > > As reported on the mailing list by Johannes, I confirmed that the idle > timeout set on the listener factory did not have any effect. The > connection/session is still good long after the specified idle timeout. As > far as I can remember this used to work fine in pre-1.0 releases. We also > have to make sure that the idle timeout on the data connections works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
[ https://issues.apache.org/jira/browse/FTPSERVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-304: -- Description: As reported on the mailing list by Johannes, I confirmed that the idle timeout set on the listener factory did not have any effect. The connection/session is still good long after the specified idle timeout. As far as I can remember this used to work fine in pre-1.0 releases. We also have to make sure that the idle timeout on the data connections works. (was: As reported on the mailing list by Johannes, I conformed that the idle timeout set on the listener factory did not have any effect. The connection/session is still good long after the specified idle timeout. As far as I can remember this used to work fine in pre-1.0 releases. We also have to make sure that the idle timeout on the data connections works. ) > The Idle Timeout set in the listener configuration does not have any effect > --- > > Key: FTPSERVER-304 > URL: https://issues.apache.org/jira/browse/FTPSERVER-304 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.1 >Reporter: Sai Pullabhotla > Fix For: 1.0.2 > > > As reported on the mailing list by Johannes, I confirmed that the idle > timeout set on the listener factory did not have any effect. The > connection/session is still good long after the specified idle timeout. As > far as I can remember this used to work fine in pre-1.0 releases. We also > have to make sure that the idle timeout on the data connections works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
[ https://issues.apache.org/jira/browse/FTPSERVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711449#action_12711449 ] Sai Pullabhotla commented on FTPSERVER-304: --- After researching into this issue...here is what I found. The idle timeout set on the listener does in fact work until the user logs in. Once the user logs in, the idle timeout is taken from the "User" object and set on the session. In my case, I left the idle timeout for the user at zero (perhaps, so did the original poster) which makes the timeout infinite. At this point I'm not sure how exactly we wanted the behavior to be. But I would recommend the following: 1. By default all users should inherit the timeout specified in the listener configuration. 2. Timeout can be overridden at a specific user level by setting it to a value >= 0, where 0 means do not timeout. 3. Any negative value specified for the user timeout should be interpreted as use the default timeout (the timeout specified on the listener). 4. Update the BaseUser class to default the idle timeout to -1 (in the constructor). Basically by allowing the timeout inheritance, there is no need to have a timeout specified on every user's record. Let me know what you guys think. > The Idle Timeout set in the listener configuration does not have any effect > --- > > Key: FTPSERVER-304 > URL: https://issues.apache.org/jira/browse/FTPSERVER-304 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.1 >Reporter: Sai Pullabhotla > Fix For: 1.0.2 > > > As reported on the mailing list by Johannes, I conformed that the idle > timeout set on the listener factory did not have any effect. The > connection/session is still good long after the specified idle timeout. As > far as I can remember this used to work fine in pre-1.0 releases. We also > have to make sure that the idle timeout on the data connections works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-305) Logging filter should not convert the request (command) to all UPPER CASE
Logging filter should not convert the request (command) to all UPPER CASE - Key: FTPSERVER-305 URL: https://issues.apache.org/jira/browse/FTPSERVER-305 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Sai Pullabhotla Fix For: 1.0.2 I'm not sure if it is a good idea for the logging filter to log the entire command in UPPER CASE, especially the arguments to the command such as file paths. We might want to log the original command that was sent by the client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect
The Idle Timeout set in the listener configuration does not have any effect --- Key: FTPSERVER-304 URL: https://issues.apache.org/jira/browse/FTPSERVER-304 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Sai Pullabhotla Fix For: 1.0.2 As reported on the mailing list by Johannes, I conformed that the idle timeout set on the listener factory did not have any effect. The connection/session is still good long after the specified idle timeout. As far as I can remember this used to work fine in pre-1.0 releases. We also have to make sure that the idle timeout on the data connections works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-253) Enhance the Ftplet.afterCommand to provide more information about the result of command execution
[ https://issues.apache.org/jira/browse/FTPSERVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-253: -- Attachment: FTPSERVER-253_Patch.txt Attached is the first draft of the patch. There is probably more to do regarding this, but I first wanted you to review it to ensure we are on the right track. Below is what I've done so far: Added two new methods in the FtpReply interface - one that returns the time the reply was sent and another that tells if the reply is a positive reply Implemented the above two methods int he DefaultFtpReply. Added a new method in the FtpRequest interface that returns the time at which the request was received. Implemented the above method in the DefaultFtpRequest. The above 4 items can be used by the Ftplet implementations to determine if the request was sucessfully processed or not and the total time it took to process the request. Added a new method named getPhysicalFile in the FtpFile interface. This method returns an Object. The above method is already implemented in the NativeFtpFile. The above two are needed as most often the Ftplets want to know the physical location to do any further processing on the file or just to log the physical file. Created a new Interface org.apache.ftpserver.ftplet.DataTransferFtpReply Created a new Interface org.apache.ftpserver.ftplet.RenameFtpReply. Created org.apache.ftpserver.impl.LocalizedDataTransferFtpReply which exteds LocalizedFtpReply and implements DataTransferFtpReply Created org.apache.ftpserver.impl.LocalizedRenameFtpReply which extends LocalizedFtpReply and implements RenameFtpReply Updated the APPE, LIST, RETR, STOR, STOU commands to send LocalizedDataTransferFtpReply. I still have to update the MLSD command I believe. Updated the RNTO command to send LocalizedRenameFtpReply. Created a new utility class named FtpReplyTranslator where all methods that expand variables and translate messages are kept. These methods are used by the Localized*FtpReply classes. Below is what needs to be done if you all like what has been done above: Create one more extension of FtpReply (may be call it FileActionFtpReply) which is sent on all commands that act on a file (no data transfer is involved). These commands include MKD, RMD, DELE, CWD etc. Update these commands to send the new type of FtpReply. Other observations: While working on the above I noticed a couple of things that may need to be changed/fixed: 1. All data transfer commands (such as LIST, RETR etc) have a block of code that checks to see if a PASV/PORT command was issued. This code should probably go into the AbstractCommand instead of having the very same code in 7 different command implementations. Also, the reply sent when this check fails may need to be translated. 2. getUniqueFile in STOU command may need to be synchronized. Even if we synchronize it, there is no gurantee that two different FTP sessions get the same file as we do not create the file in this method. Perhaps, we should use File.createTempFile() method to do this. Hope it all makes sense. Please let me know what you think or need any clarification. Regards, Sai Pullabhotla > Enhance the Ftplet.afterCommand to provide more information about the result > of command execution > - > > Key: FTPSERVER-253 > URL: https://issues.apache.org/jira/browse/FTPSERVER-253 > Project: FtpServer > Issue Type: New Feature > Components: Core, Ftplets >Reporter: Sai Pullabhotla > Fix For: 1.1 > > Attachments: FTPSERVER-253_Patch.txt > > > It would be nice to enhance the afterCommand method in the Ftplet to provide > additional details about the result of command execution. Currently the > afterCommand method of an Ftplet is called back with the following parameters > - > FtpSession, FtpRequest and FtpReply. The FtpReply parameter contains only the > reply code and the reply string that was sent. The Ftplets may want to know a > little more information on what exactly happened to the command that was > executed. For example, the afterCommand for RNTO command might want to know > the from file, the to file and if the command was successful or not. > More information on this can be found at > http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-253) Enhance the Ftplet.afterCommand to provide more information about the result of command execution
[ https://issues.apache.org/jira/browse/FTPSERVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694974#action_12694974 ] Sai Pullabhotla commented on FTPSERVER-253: --- Can't wait for 2.0 ;). I think I figured out what needs to be done for the most part. I will have a patch out for 1.1 this weekend. Regards, Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Sun, Mar 29, 2009 at 1:38 PM, Niklas Gustavsson (JIRA) > Enhance the Ftplet.afterCommand to provide more information about the result > of command execution > - > > Key: FTPSERVER-253 > URL: https://issues.apache.org/jira/browse/FTPSERVER-253 > Project: FtpServer > Issue Type: New Feature > Components: Core, Ftplets >Reporter: Sai Pullabhotla > Fix For: 1.1 > > > It would be nice to enhance the afterCommand method in the Ftplet to provide > additional details about the result of command execution. Currently the > afterCommand method of an Ftplet is called back with the following parameters > - > FtpSession, FtpRequest and FtpReply. The FtpReply parameter contains only the > reply code and the reply string that was sent. The Ftplets may want to know a > little more information on what exactly happened to the command that was > executed. For example, the afterCommand for RNTO command might want to know > the from file, the to file and if the command was successful or not. > More information on this can be found at > http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-253) Enhance the Ftplet.afterCommand to provide more information about the result of command execution
[
https://issues.apache.org/jira/browse/FTPSERVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693578#action_12693578
]
Sai Pullabhotla commented on FTPSERVER-253:
---
Okay, I think I'm ready to work on this and need your inputs in finalizing the
approach. Below is one of the emails I sent a while ago :
- BEGIN EMAIL -
Change the signature of the Command.execute to return the FtpReply
(this may not be needed, but I think it makes more sense to do it this
way rather than storing the "lastReply" in the FtpSession. I
definitely prefer this approach.
Create subclasses of FtpReply where Ftplets may want to know
additional information about the result of a command. For example, the
RNTO command returns a RenameFtpReply would contain the fromFile and
toFile information.
I don't think we will have too many subclasses of the DefaultFtpReply,
but I will see what I can do when I dig into the code.
One thing I'm still debating on is - if we really should use FtpReply
objects to provide this additional information or create yet another
abstract class (call it Result) and call back the Ftplet afterCommand
method with the Result instead of the FtpReply. This Result would
contain the FtpReply plus any other information. I prefer this solely
based on the logical structure/naming of the objects. Both approaches
would work fine, except the backward compatibility issue if we decide
to go with the new Result object. To be more specific, the Result
class would look like -
public abstract class Result {
private FtpReply reply;
private boolean success;
private long startTime;
private long endTime;
}
A sub class of Result, RenameResult would look like -
public abstract class RenameResult extends Result {
private FtpFile from;
private FtpFile to;
}
- END EMAIL -
I'm leaning towards the second approach of creating a Result object which holds
all the information about the execution result, which includes the FtpReply we
sent.
We cannot use the described soultion #1 (extending DefaultFtpReply) as is
because we have a subclass of DefaultFtpReply which is the LocalizedFtpReply.
So, if we want to go with solution #1 we have to extend the new Reply classes
such as RenameFtpReply from LocalizedFtpReply or get rid of the
LocalizedFtpReply and make the DefaultFtpReply support both English and
Localized messages.
Please let me know what you guys think and we will go from there.
> Enhance the Ftplet.afterCommand to provide more information about the result
> of command execution
> -
>
> Key: FTPSERVER-253
> URL: https://issues.apache.org/jira/browse/FTPSERVER-253
> Project: FtpServer
> Issue Type: New Feature
> Components: Core, Ftplets
>Reporter: Sai Pullabhotla
> Fix For: 1.1
>
>
> It would be nice to enhance the afterCommand method in the Ftplet to provide
> additional details about the result of command execution. Currently the
> afterCommand method of an Ftplet is called back with the following parameters
> -
> FtpSession, FtpRequest and FtpReply. The FtpReply parameter contains only the
> reply code and the reply string that was sent. The Ftplets may want to know a
> little more information on what exactly happened to the command that was
> executed. For example, the afterCommand for RNTO command might want to know
> the from file, the to file and if the command was successful or not.
> More information on this can be found at
> http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-273) Do not default tha algorithm for KeyManager and TrustManager to SunX509
Do not default tha algorithm for KeyManager and TrustManager to SunX509 --- Key: FTPSERVER-273 URL: https://issues.apache.org/jira/browse/FTPSERVER-273 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-RC2 Reporter: Sai Pullabhotla Priority: Minor Fix For: 1.0.0 The SSLConfigurationFactory class currently defaults the trustStoreAlgoritm and keyStoreAlgorithms to SunX509. This does not work on IBM's JVM unless user explicitly configures these parameters to IbmX509. Instead of defaulting to a hard coded value, SunX509, we should consider changing the code to use - KeyManagerFactory.getDefaultAlgorithm() and TrustManagerFactory.getDefaultAlgorithm(). So, if the "algorithm" attribute is not specified, create key and trust managers using the default algorithm used by the JVM. If we decide to do this, update the documentation as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-253) Enhance the Ftplet.afterCommand to provide more information about the result of command execution
Enhance the Ftplet.afterCommand to provide more information about the result of command execution - Key: FTPSERVER-253 URL: https://issues.apache.org/jira/browse/FTPSERVER-253 Project: FtpServer Issue Type: New Feature Components: Core, Ftplets Reporter: Sai Pullabhotla Fix For: 1.1 It would be nice to enhance the afterCommand method in the Ftplet to provide additional details about the result of command execution. Currently the afterCommand method of an Ftplet is called back with the following parameters - FtpSession, FtpRequest and FtpReply. The FtpReply parameter contains only the reply code and the reply string that was sent. The Ftplets may want to know a little more information on what exactly happened to the command that was executed. For example, the afterCommand for RNTO command might want to know the from file, the to file and if the command was successful or not. More information on this can be found at http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-252) Maintain a session ID for every client session and make it available via an API call
[ https://issues.apache.org/jira/browse/FTPSERVER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-252: -- Description: Add a new method to the FtpSession to return a unique session ID of a particular FTP session. It is important that these generated session IDs are unique for the entire life of an FTP server installation, i.e., a given install of the FTP server should never generate a duplicate session ID. If we want to think one more step ahead, it may not be a bad idea to even use UUIDs if we plan on running the server clusters for load balancing and fail over. More information about this can be found at - http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. was: Add a new method to the FtpSession to return a unique session ID of a particular FTP session. It is important that these generated session IDs are unique for the entire life of an FTP server installation, i.e., a given install of the FTP server should never generate a duplicate session ID. More information about this can be found at - http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. > Maintain a session ID for every client session and make it available via an > API call > > > Key: FTPSERVER-252 > URL: https://issues.apache.org/jira/browse/FTPSERVER-252 > Project: FtpServer > Issue Type: New Feature > Components: Core, Ftplets >Reporter: Sai Pullabhotla > Fix For: 1.1 > > > Add a new method to the FtpSession to return a unique session ID of a > particular FTP session. It is important that these generated session IDs are > unique for the entire life of an FTP server installation, i.e., a given > install of the FTP server should never generate a duplicate session ID. If we > want to think one more step ahead, it may not be a bad idea to even use UUIDs > if we plan on running the server clusters for load balancing and fail over. > More information about this can be found at - > http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-252) Maintain a session ID for every client session and make it available via an API call
Maintain a session ID for every client session and make it available via an API call Key: FTPSERVER-252 URL: https://issues.apache.org/jira/browse/FTPSERVER-252 Project: FtpServer Issue Type: New Feature Components: Core, Ftplets Reporter: Sai Pullabhotla Fix For: 1.1 Add a new method to the FtpSession to return a unique session ID of a particular FTP session. It is important that these generated session IDs are unique for the entire life of an FTP server installation, i.e., a given install of the FTP server should never generate a duplicate session ID. More information about this can be found at - http://www.mail-archive.com/ftpserver-us...@mina.apache.org/msg00512.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-238) PROT and PBSZ commands should be allowed before/after login
PROT and PBSZ commands should be allowed before/after login --- Key: FTPSERVER-238 URL: https://issues.apache.org/jira/browse/FTPSERVER-238 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: Sai Pullabhotla Fix For: 1.0.0-RC1 PROT and PBSZ commands should be allowed before/after login. Almost all FTP servers allow clients to run these commands before login and the RFC also does not say otherwise. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655242#action_12655242 ] Sai Pullabhotla commented on FTPSERVER-227: --- We don't have to check if the directory being deleted is parent directory of current working directory, because, then Java would not let the deletion go through. In other words, java.io.File.delete() fails on a non-empty directory. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com > RMD command should not delete the current working directory or the any parent > of current working directory > -- > > Key: FTPSERVER-227 > URL: https://issues.apache.org/jira/browse/FTPSERVER-227 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > Attachments: FTPSERVER-227_patch.text > > > RMD command should not delete the current working directory or the any parent > of current working directory. > case 1: Let us say, the current working directory is "/wd" then "RMD ." or > RMD "/wd" should result in a 5XX reply. > case 2: Let us say the working directory is "/wd/subdir", then RMD /wd or > "RMD .." should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-227) RMD command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-227: -- Attachment: FTPSERVER-227_patch.text Attached is the patch for this issue. This patch is set to send a 550 reply code when the client attempts to delete the current working directory. Feel free to change it to 450 if you think that is more appropriate. I found another bug related to the 450 reply in the RMD command for which I left a TODO with description. I added a new method in the NativeFtpFile to check if two NativeFtpFile objects are same. Right now, it checks to see if the java.io.File objects are equal. I hope that is good enough. Updated the RmDir test case. Please note that this fix stops one from deleting the working directory from one's own session. In other words, session 2 would be able to delete the working directory of session 1. This is what most FTP servers do too. > RMD command should not delete the current working directory or the any parent > of current working directory > -- > > Key: FTPSERVER-227 > URL: https://issues.apache.org/jira/browse/FTPSERVER-227 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla > Fix For: 1.0.0-RC1 > > Attachments: FTPSERVER-227_patch.text > > > RMD command should not delete the current working directory or the any parent > of current working directory. > case 1: Let us say, the current working directory is "/wd" then "RMD ." or > RMD "/wd" should result in a 5XX reply. > case 2: Let us say the working directory is "/wd/subdir", then RMD /wd or > "RMD .." should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-226) DELE command deletes directories
[ https://issues.apache.org/jira/browse/FTPSERVER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-226: -- Attachment: FTPSERVER-226_patch.txt Attached is the patch to fix this. I used the existing 550 message on the DELE command. The clients receive a reply like this: 550 Not a valid file "/abc/b/c". hope it is alright with you guys. I also updated the Delete test case, not very used to writing test cases, but I tried :) Hope I did not mess up anything. > DELE command deletes directories > > > Key: FTPSERVER-226 > URL: https://issues.apache.org/jira/browse/FTPSERVER-226 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla > Fix For: 1.0.0-RC1 > > Attachments: FTPSERVER-226_patch.txt > > > DELE command should NOT delete the object if the argument represents a > directory. According to the FTP Standards RMD command should be used for > deleting directories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-229) MFMT Command - Code Enhancement
[ https://issues.apache.org/jira/browse/FTPSERVER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653293#action_12653293 ] Sai Pullabhotla commented on FTPSERVER-229: --- Nicklas, That's a very valid point. I did not even think about it. I guess, it could stay the way it is or if we want, we can create a SynchronizedSimpleDateFormat class using the Deligator pattern, but synchronize some methods like format and parse. Surely, the synchronization would have a performance hit too. We need to think some more about this. Thanks. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Thu, Dec 4, 2008 at 5:37 AM, Niklas Gustavsson (JIRA) > MFMT Command - Code Enhancement > --- > > Key: FTPSERVER-229 > URL: https://issues.apache.org/jira/browse/FTPSERVER-229 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > > MFMT Command - in the source code for this command (MFMT.java), the > DateFormat and > its configuration should be moved to static block for performance and to > reduce object creations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-227) DELE command should not delete the current working directory or the any parent of current working directory
[ https://issues.apache.org/jira/browse/FTPSERVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653290#action_12653290 ] Sai Pullabhotla commented on FTPSERVER-227: --- Sorry for filing it incorrect, but it should have been RMD command should not delete working directory or parent of working directory. Could you please reopen this? Thanks. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com > DELE command should not delete the current working directory or the any > parent of current working directory > --- > > Key: FTPSERVER-227 > URL: https://issues.apache.org/jira/browse/FTPSERVER-227 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: Sai Pullabhotla > Fix For: 1.0.0-RC1 > > > DELE command should not delete the current working directory or the any > parent of current working directory. > case 1: Let us say, the current working directory is "/wd" then "DELE ." or > DELE "/wd" should result in a 5XX reply. > case 2: Let us say the working directory is "/wd/subdir", then DELE /wd or > "DELE .." should also be restricted and a 5xx reply should be sent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-234) TYPE command with no argument
TYPE command with no argument - Key: FTPSERVER-234 URL: https://issues.apache.org/jira/browse/FTPSERVER-234 Project: FtpServer Issue Type: Improvement Components: Core Affects Versions: 1.0.0-M3 Reporter: Sai Pullabhotla Fix For: 1.0.0-M4 Not sure if TYPE command with no argument should change the type to ASCII. Instead it should reply back with 2xx reply indicating the current type in use. Not sure what the RFC says. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FTPSERVER-233) MKD command should not create all the parent directories
MKD command should not create all the parent directories Key: FTPSERVER-233 URL: https://issues.apache.org/jira/browse/FTPSERVER-233 Project: FtpServer Issue Type: Bug Reporter: Sai Pullabhotla MKD command should not create all the parent directories, instead it should only try to create the last name in the given path. I'm filing this as a bug because most FTP servers fail if the parent directory does not exist. Just to be consistent with those we need to change the behavior too. To fix this, java.io.File.mkdirs() should be changed to java.io.File.mkdir() in the NativeFtpFile.java. Have to make sure this does not effect any other things though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
