Re: svn commit: r729187 - /mina/trunk/core/src/main/java/org/apache/mina/proxy/handlers/socks/Socks5LogicHandler.java
Hi Edouard,
just a few things about your last commit :
-int step = ((Integer) getSession().getAttribute(HANDSHAKE_STEP))
-.intValue();
-writeRequest(nextFilter, request, step);
+writeRequest(nextFilter, request, ((Integer) getSession().getAttribute(
+HANDSHAKE_STEP)).intValue());
When debugging, the second form is really painful, as you have to way to
get the integer value before calling the writeRequest method. Better
keep the two lines. The compiler will optimize the code anyway. And I
don't think we need to call the intValue() at all, java 5 will do some
autoBoxing.
-if (adr != null) {
+if (adr != null && !adr.isUnresolved()) {
As we are following Sun rules :
http://java.sun.com/docs/codeconv/html/CodeConventions.doc9.html#331, so
this line should be
if ((adr != null) && !adr.isUnresolved())
As you can see, nothing serious.
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
[jira] Resolved: (DIRMINA-652) Socks5LogicHandler.encodeProxyRequestPacket(final SocksProxyRequest request) should check that the result of request.getEndpointAddress() is resolved before using it
[
https://issues.apache.org/jira/browse/DIRMINA-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edouard De Oliveira resolved DIRMINA-652.
-
Resolution: Fixed
Fix Version/s: 2.0.0-RC1
Assignee: Edouard De Oliveira
Hi,
thanks for the report a patch was committed to trunk
Please let me know if it is ok with you
Regards
> Socks5LogicHandler.encodeProxyRequestPacket(final SocksProxyRequest request)
> should check that the result of request.getEndpointAddress() is resolved
> before using it
> --
>
> Key: DIRMINA-652
> URL: https://issues.apache.org/jira/browse/DIRMINA-652
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.0-RC1
>Reporter: Dan Mihai Dumitriu
>Assignee: Edouard De Oliveira
> Fix For: 2.0.0-RC1
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Depending on what is going on in layers above this one, the InetSocketAddress
> returned by request.getEndpointAddress() could be unresolved, in which case
> the hostname should be used.
> private IoBuffer encodeProxyRequestPacket(final SocksProxyRequest request)
> throws UnsupportedEncodingException {
> int len = 6;
> byte[] host = request.getHost() != null ? request.getHost().getBytes(
> "ASCII") : null;
> InetSocketAddress adr = request.getEndpointAddress();
> byte addressType = 0;
> if (adr != null && !adr.isUnresolved()) {
> if (adr.getAddress() instanceof Inet6Address) {
> len += 16;
> addressType = SocksProxyConstants.IPV6_ADDRESS_TYPE;
> } else if (adr.getAddress() instanceof Inet4Address) {
> len += 4;
> addressType = SocksProxyConstants.IPV4_ADDRESS_TYPE;
> }
> } else {
> len += 1 + host.length;
> addressType = SocksProxyConstants.DOMAIN_NAME_ADDRESS_TYPE;
> }
> IoBuffer buf = IoBuffer.allocate(len);
> buf.put(request.getProtocolVersion());
> buf.put(request.getCommandCode());
> buf.put((byte) 0x00); // Reserved
> buf.put(addressType);
> if (addressType == SocksProxyConstants.DOMAIN_NAME_ADDRESS_TYPE) {
> buf.put((byte) host.length);
> buf.put(host);
> } else {
> buf.put(request.getIpAddress());
> }
> buf.put(request.getPort());
> return buf;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [continuum] BUILD FAILURE: MINA - Apache Mina SSHD - default maven2 buildDefinition
Hi Guillaume, it would be cool is to check that the project builds before committing something, as much as possible. The CI system should be seen as a safety net, not a notification system :) Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (FTPSERVER-249) DBUserManager doesn't close Connections leading to pool exhaustion.
[ https://issues.apache.org/jira/browse/FTPSERVER-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658961#action_12658961 ] Niklas Gustavsson commented on FTPSERVER-249: - Thanks for working on this David! > DBUserManager doesn't close Connections leading to pool exhaustion. > --- > > Key: FTPSERVER-249 > URL: https://issues.apache.org/jira/browse/FTPSERVER-249 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-M4 >Reporter: David Latorre >Assignee: David Latorre > Fix For: 1.0.0-RC1 > > > DBUserManager creates a new Connection in every call but never returns the > connections to the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-247) Add DataConnectionConfiguration.isImplicitSsl
[ https://issues.apache.org/jira/browse/FTPSERVER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Conaway updated FTPSERVER-247: Attachment: ftpserver-247.patch Attaching updated patch to add the "implicitSsl" property to the DataConnectionConfiguration along with updates to the XML configuration and associated test cases. > Add DataConnectionConfiguration.isImplicitSsl > - > > Key: FTPSERVER-247 > URL: https://issues.apache.org/jira/browse/FTPSERVER-247 > Project: FtpServer > Issue Type: Improvement > Components: Core, Server >Reporter: Kevin Conaway >Priority: Critical > Attachments: ftpserver-247.patch > > > It would be extremely helpful to be able to force the data channel to use SSL > when in "implicit SSL" mode. > When using implicit SSL, some FTP clients do not send a PROT command to > change the data channel protection level yet they assume that the data > channel will be encrypted. > FtpServer assumes that the data channel will be un-encrypted. It would be > nice to have an option to force the data channel to be encrypted to > accommodate these clients. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-247) Add DataConnectionConfiguration.isImplicitSsl
[ https://issues.apache.org/jira/browse/FTPSERVER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Conaway updated FTPSERVER-247: Summary: Add DataConnectionConfiguration.isImplicitSsl (was: Add DataConnectionConfiguration.isSslRequired) > Add DataConnectionConfiguration.isImplicitSsl > - > > Key: FTPSERVER-247 > URL: https://issues.apache.org/jira/browse/FTPSERVER-247 > Project: FtpServer > Issue Type: Improvement > Components: Core, Server >Reporter: Kevin Conaway >Priority: Critical > > It would be extremely helpful to be able to force the data channel to use SSL > when in "implicit SSL" mode. > When using implicit SSL, some FTP clients do not send a PROT command to > change the data channel protection level yet they assume that the data > channel will be encrypted. > FtpServer assumes that the data channel will be un-encrypted. It would be > nice to have an option to force the data channel to be encrypted to > accommodate these clients. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-247) Add DataConnectionConfiguration.isImplicitSsl
[ https://issues.apache.org/jira/browse/FTPSERVER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Conaway updated FTPSERVER-247: Attachment: (was: ftpserver-237.patch) > Add DataConnectionConfiguration.isImplicitSsl > - > > Key: FTPSERVER-247 > URL: https://issues.apache.org/jira/browse/FTPSERVER-247 > Project: FtpServer > Issue Type: Improvement > Components: Core, Server >Reporter: Kevin Conaway >Priority: Critical > > It would be extremely helpful to be able to force the data channel to use SSL > when in "implicit SSL" mode. > When using implicit SSL, some FTP clients do not send a PROT command to > change the data channel protection level yet they assume that the data > channel will be encrypted. > FtpServer assumes that the data channel will be un-encrypted. It would be > nice to have an option to force the data channel to be encrypted to > accommodate these clients. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [FTPSERVER] Ftplets never destroyed
On Tue, Dec 23, 2008 at 11:22 AM, Jiří Kuhn wrote: > My approach can be seen in attached file. I think the patch is fine, could you please attach it to the JIRA issue to clear the license details? https://issues.apache.org/jira/browse/FTPSERVER-248 /niklas
[jira] Created: (FTPSERVER-251) IoUtils.close() operation takes a long time when using implicit SSL
IoUtils.close() operation takes a long time when using implicit SSL
---
Key: FTPSERVER-251
URL: https://issues.apache.org/jira/browse/FTPSERVER-251
Project: FtpServer
Issue Type: Bug
Components: Server
Affects Versions: 1.0.0-RC1
Environment: SLES 10 Java6 1.0.0-M4 (with SSL patch for FTPSERVER-241)
Reporter: Randy Prager
Fix For: 1.0.0
Using a configuration for implicit SSL. & PASV connections
Client is Auth TLS + PASV
The LIST command takes approx 10 seconds to complete.
It appears that the call to IoUtils.close() in method
IODataConnection.transferToClient() is the culprit.
I put some trace in the finally block:
if (writer != null) {
start = System.currentTimeMillis();
writer.flush();
LOG.info("flush in ["+(System.currentTimeMillis()-start)+"]
ms.");
}
start = System.currentTimeMillis();
IoUtils.close(writer);
LOG.info("close in ["+(System.currentTimeMillis()-start)+"] ms.");
[ INFO] 2008-12-23 12:22:13,892 flush in [0] ms.
[ INFO] 2008-12-23 12:22:24,086 close in [10193] ms.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Should we use InetAddress to represent IP Address while handling Protocol Message?
On Tue, Dec 23, 2008 at 7:53 PM, Mark Webb wrote: > I would disagree with using a String. There are too much room for > error IMO. I do agree that resolving the address is not the best > approach either. Would it make any sense to write an "IP Address" > class that at least validates the IP? > Yup, good suggestion, let me try this out.
Re: Should we use InetAddress to represent IP Address while handling Protocol Message?
I would disagree with using a String. There are too much room for error IMO. I do agree that resolving the address is not the best approach either. Would it make any sense to write an "IP Address" class that at least validates the IP? On Tue, Dec 23, 2008 at 9:05 AM, Ashish wrote: >>> The reason why I am a little confused is, InetAddress.getByAddress API >>> actually resolves the address which can hit the performance. ApacheDS >>> uses this approach. >>> >> You can have a look at the current implementation of this codec in the >> Directory project. It's written on top of MINA. >> >> http://svn.apache.org/repos/asf/directory/apacheds/trunk/protocol-dhcp/ >> > I have already looked at it and that's why debate started. ApacheDS > uses InetAddress approach > and I just thought about using a simple String. > On a similar not xid is being as int in ApacheDS DhcpMessageDecoder, > which is an unsigned int > as per RFC (4 bytes). Since ApacheDS is well tested, I am sticking to > the ApacheDS > implementation as the guideline. > > thanks >
Re: Should we use InetAddress to represent IP Address while handling Protocol Message?
>> The reason why I am a little confused is, InetAddress.getByAddress API >> actually resolves the address which can hit the performance. ApacheDS >> uses this approach. >> > You can have a look at the current implementation of this codec in the > Directory project. It's written on top of MINA. > > http://svn.apache.org/repos/asf/directory/apacheds/trunk/protocol-dhcp/ > I have already looked at it and that's why debate started. ApacheDS uses InetAddress approach and I just thought about using a simple String. On a similar not xid is being as int in ApacheDS DhcpMessageDecoder, which is an unsigned int as per RFC (4 bytes). Since ApacheDS is well tested, I am sticking to the ApacheDS implementation as the guideline. thanks
Re: Should we use InetAddress to represent IP Address while handling Protocol Message?
Ashish wrote: Was implementing DHCP Codec, and the message structure has a few IP Addresses (ciaddr, yiaddr, siaddr, giaddr). The question is, Should I represent the IP Address as InetAddess class or as a simple String in the message structure? The reason why I am a little confused is, InetAddress.getByAddress API actually resolves the address which can hit the performance. ApacheDS uses this approach. What's the general approach recommended in such situations? Is there any advantage that we may get by using InetAddress, instead of a simpler String representation? You can have a look at the current implementation of this codec in the Directory project. It's written on top of MINA. http://svn.apache.org/repos/asf/directory/apacheds/trunk/protocol-dhcp/ -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Should we use InetAddress to represent IP Address while handling Protocol Message?
Was implementing DHCP Codec, and the message structure has a few IP Addresses (ciaddr, yiaddr, siaddr, giaddr). The question is, Should I represent the IP Address as InetAddess class or as a simple String in the message structure? The reason why I am a little confused is, InetAddress.getByAddress API actually resolves the address which can hit the performance. ApacheDS uses this approach. What's the general approach recommended in such situations? Is there any advantage that we may get by using InetAddress, instead of a simpler String representation? -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
[jira] Updated: (FTPSERVER-250) java.net.BindException: Address already in use
[ https://issues.apache.org/jira/browse/FTPSERVER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Kuhn updated FTPSERVER-250: Attachment: BindExceptionParallelTest.java BindExceptionSerialTest.java ClientTestTemplate.patch > java.net.BindException: Address already in use > -- > > Key: FTPSERVER-250 > URL: https://issues.apache.org/jira/browse/FTPSERVER-250 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0.0-RC1 > Environment: linux, windows >Reporter: Jiri Kuhn > Attachments: BindExceptionParallelTest.java, > BindExceptionSerialTest.java, ClientTestTemplate.patch > > > I have configured ftp server to use particular interface and port on active > data mode like > ip-check="true"/> > After that, the server starts to throw java.net.BindException: Address > already in use during second and other data transfer. First data transfer is > always ok. It seems that it has something to do with TIME_WAIT tcp port state > (as it can be seen using netstat utility). > I have created two tests, one for serial execution and one for parallel > execution, see attached files (patch for ClientTestTemplate required) > - serial execution - emulates what I'm doing in command line ftp client (or > any other client), I'm always able to reproduce it on linux, but never on > windows xp sp2 > - parallel execution - emulates situation when more then one data connection > has to be opened in one time, it fails with two clients on linux (but it may > by simple serial execution failure), on windows it fails with three clients > BUT - I have tested the parallel test against proftpd server (fixed data port > 20) with 30 clients and none of them fails. > Are you able to reproduce the behaviour I have observed? > Does anyone with deeper knowledge of java socket programming know if it is > possible to bind a port once and then reuse it for generally unlimited number > of (simultaneous) 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-250) java.net.BindException: Address already in use
java.net.BindException: Address already in use -- Key: FTPSERVER-250 URL: https://issues.apache.org/jira/browse/FTPSERVER-250 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-RC1 Environment: linux, windows Reporter: Jiri Kuhn I have configured ftp server to use particular interface and port on active data mode like After that, the server starts to throw java.net.BindException: Address already in use during second and other data transfer. First data transfer is always ok. It seems that it has something to do with TIME_WAIT tcp port state (as it can be seen using netstat utility). I have created two tests, one for serial execution and one for parallel execution, see attached files (patch for ClientTestTemplate required) - serial execution - emulates what I'm doing in command line ftp client (or any other client), I'm always able to reproduce it on linux, but never on windows xp sp2 - parallel execution - emulates situation when more then one data connection has to be opened in one time, it fails with two clients on linux (but it may by simple serial execution failure), on windows it fails with three clients BUT - I have tested the parallel test against proftpd server (fixed data port 20) with 30 clients and none of them fails. Are you able to reproduce the behaviour I have observed? Does anyone with deeper knowledge of java socket programming know if it is possible to bind a port once and then reuse it for generally unlimited number of (simultaneous) connections? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [FTPSERVER] Ftplets never destroyed
When I saw the update I have noticed that there is a code duplicity. And for
someone like me, there is a code inconsistency. The duplicity should be
removed, the inconsistency may be discussed.
The duplicity: Listeners are stopped twice, for first time in
DefaultFtpServer.stop(), for second time in
DefaultFtpServerContext.dispose().
The inconsistency: As DefaultFtpServer starts listeners and initializes a
ftplet container, it should stop and destroy these as well. My understanding
of ftp server context is that it holds instances to be accessible accross
project but would'n have any application logic inside. Thus,
FtpServerContext.dispose() should free only resources - in our case memory.
Next note is about null checking. The first thing DefaultFtpServer.stop()
does is checking of serverContext if it is null, why to check it again
before dispose() is caled? And before ftpletContainer.destroy() is called,
the ftpletContainer is checked if it is null. But lot of code in project
implicitly expects the ftplet container to be not null (find usages of
FtpServerContext.getFtpletContainer() in your IDE).
My approach can be seen in attached file.
Jiří Kuhn.
2008/12/22 Niklas Gustavsson
> You've convinced me. I just added the change where we always detroy
> the Ftplets on shutdown. Thanks a lot for the motivations!
>
> /niklas
>
> 2008/12/22 Sai Pullabhotla :
> > I agree with Jiří that if some one chooses to use a custom Ftplet
> > container, it is their responsibility to implement the appropriate
> > methods (such as init and destroy). All we can do is call the destroy
> > method when we think the server is going down. I don't see any reason
> > why we need to keep track of what Ftplet container is in use and make
> > decisions based on that.
> >
> > Regards,
> > Sai Pullabhotla
> > Phone: (402) 408-5753
> > Fax: (402) 408-6861
> > www.jMethods.com
> >
> >
> > On Mon, Dec 22, 2008 at 1:20 AM, Jiří Kuhn wrote:
> >> In my opinion, if we call init(), we should call destroy(). It's clear
> and
> >> logic behaviour. Client may provide an instance of the ftplet container
> and
> >> the server calls methods defined by an interface, why to make a
> difference
> >> if the instance is default one or not. The decision is on a client if
> the
> >> destroy() method should be implemented or empty and the destruction of
> the
> >> provided ftplet container is done somewhere else.
> >>
> >> The interface defines a contract, if the client breaks it, it will face
> the
> >> consequences itself.
> >>
> >> At present, if you use everything default, your ftplets are never
> >> destroyed(). This is wrong, I think.
> >>
> >> Jiří Kuhn.
> >>
> >> 2008/12/19 Niklas Gustavsson
> >>
> >>> On Fri, Dec 19, 2008 at 8:14 AM, Jiří Kuhn
> wrote:
> >>> > destroy() method on ftplet container is never called. I gues that
> >>> something
> >>> > like
> >>> >
> >>> >serverContext.getFtpletContainer().destroy();
> >>> >
> >>> > should be placed somewhere inside DefaultFtpServer.stop() method.
> >>> Probably
> >>> > right just before serverContext disposition to be, let's say,
> consistent
> >>> > with init() method. I really wonder that none has noticed it yet. Or
> am I
> >>> > missing something?
> >>>
> >>> I'm aware of this, but unsure how we best handle it. If the user has
> >>> provided their own FtpletContainer (pretty unlikely but possible), I
> >>> think the API client should destroy the container itself. However, in
> >>> most cases, clients will simple add Ftplets to the server, in this
> >>> case we should destroy on shutdown. So, should we keep track of the
> >>> fact that we're using our default provided FtpletContainer and only
> >>> destroy if that's true?
> >>>
> >>> /niklas
> >>>
> >>
> >
>
Index: core/src/main/java/org/apache/ftpserver/impl/DefaultFtpServer.java
===
--- core/src/main/java/org/apache/ftpserver/impl/DefaultFtpServer.java (revision 728879)
+++ core/src/main/java/org/apache/ftpserver/impl/DefaultFtpServer.java (working copy)
@@ -114,11 +114,12 @@
listener.stop();
}
+// destroy the Ftplet container
+serverContext.getFtpletContainer().destroy();
+
// release server resources
-if (serverContext != null) {
-serverContext.dispose();
-serverContext = null;
-}
+serverContext.dispose();
+serverContext = null;
started = false;
}
Index: core/src/main/java/org/apache/ftpserver/impl/DefaultFtpServerContext.java
===
--- core/src/main/java/org/apache/ftpserver/impl/DefaultFtpServerContext.java (revision 728879)
+++ core/src/main/java/org/apache/ftpserver/impl/DefaultFtpServerContext.java (working copy)
@@ -189,17 +189,8 @@
* Close all the components.
*/
public void dispose() {
-
-Iterator listenerIter = listeners.values().iterator();
-while
Re: How to use IP restriction feature to allow only certain IPAddresses
On Mon, Dec 22, 2008 at 9:37 PM, Suresh Metla wrote: > I am looking for a feature where i can allow only certain IPAddress to > access FTP Server. Exactly this feature is mentioned on Apache FTP server > feature pages, unfortunatley I couldn't find any documentation on how to > allow IPS, documentation only talk about the black list. You're correct, we only support blacklisting at the moment (I've updated the documentation). > Could you please help if this feature is available on Apache FTPServer? > If Yes, Please let me know how to use this feature. This feature has been requested before, please add a JIRA ticket requesting this feature and we'll have a look at it after 1.0. /niklas
Re: How to use IP restriction feature to allow only certain IPAddresses
Maarten Bosteels wrote: On Mon, Dec 22, 2008 at 11:02 PM, Emmanuel Lecharny wrote: Suresh Metla wrote: Hi All, I am looking for a feature where i can allow only certain IPAddress to access FTP Server. Exactly this feature is mentioned on Apache FTP server feature pages, unfortunatley I couldn't find any documentation on how to allow IPS, documentation only talk about the black list. Could you please help if this feature is available on Apache FTPServer? If Yes, Please let me know how to use this feature. If you can, don't do that on the FtpServer layer. Use a firewall. Way way way better ... Well, IMO that is an over-generalization. You're right, Maarten ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [jira] Commented: (DIRMINA-586) Dynamic delimiter support for TextLineCodecFactory
IIRC, you can change the filterchain of a running session. So it should be possible to 'dynamically' create a new TextLineCodecFactorywhenever you want and use it to replace the current protocol codec. Or am I missing something ? Maarten On Tue, Dec 23, 2008 at 7:17 AM, Ashish Paliwal (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/DIRMINA-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658768#action_12658768] > > Ashish Paliwal commented on DIRMINA-586: > > > Hmm... I think I misinterpreted this. I am wondering do we need to have > this functionality as part of TextLineCodecFactory. If we do, then how do we > determine, when to switch context? > Pardon my ignorance, but how many implementation shall need such a > implementation? > > > > > > Dynamic delimiter support for TextLineCodecFactory > > -- > > > > Key: DIRMINA-586 > > URL: https://issues.apache.org/jira/browse/DIRMINA-586 > > Project: MINA > > Issue Type: Improvement > > Components: Filter > >Affects Versions: 2.0.0-M1 > >Reporter: Trustin Lee > >Priority: Minor > > Fix For: 2.0.0-RC1 > > > > > > TextLineCodecFactory supports static delimiters only. For some cases, > users need to switch the delimiter dynamically depending on context. > Related discussion is found here: > > http://markmail.org/message/loiqoej35evt2yvv > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: How to use IP restriction feature to allow only certain IPAddresses
On Mon, Dec 22, 2008 at 11:02 PM, Emmanuel Lecharny wrote: > Suresh Metla wrote: > >> Hi All, >> I am looking for a feature where i can allow only certain IPAddress to >> access FTP Server. Exactly this feature is mentioned on Apache FTP server >> feature pages, unfortunatley I couldn't find any documentation on how to >> allow IPS, documentation only talk about the black list. >> Could you please help if this feature is available on Apache FTPServer? >> If Yes, Please let me know how to use this feature. >> >> > If you can, don't do that on the FtpServer layer. Use a firewall. Way way > way better ... Well, IMO that is an over-generalization. When you're afraid of a DDOS, then using a firewall to only allow a fixed set op IP's is indeed the way to go. But when the set of IP's changes frequently and especially when that set can be changed via your application, then it's often way more convenient to do the filtering in your app itself. Have a look at the BlacklistFilter, it's trivial to convert it to a WhitelistFilter http://mina.apache.org/report/trunk/apidocs/org/apache/mina/filter/firewall/BlacklistFilter.html Maarten > > It's a bit like 'When you only have a hammer, everything looks like a nail' > idea. > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
[jira] Created: (FTPSERVER-249) DBUserManager doesn't close Connections leading to pool exhaustion.
DBUserManager doesn't close Connections leading to pool exhaustion. --- Key: FTPSERVER-249 URL: https://issues.apache.org/jira/browse/FTPSERVER-249 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0-M4 Reporter: David Latorre Assignee: David Latorre Fix For: 1.0.0-RC1 DBUserManager creates a new Connection in every call but never returns the connections to the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
