I would not disagree that the IP restrictions should be handled by the filters, but at the same time. I was just looking for other ways that can be used when the filters do not provide the functionality the user wants. I do See that MINA propagates two different events -
1. session opened 2. session created Currently, we call the Ftplet.onConnect from the sessionOpened method. May be we should add yet another method to the Ftplets to indicate a sessionCreated event, in case if some one wants to use it? Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 7:38 AM, Niklas Gustavsson <[email protected]> wrote: > On Tue, Mar 16, 2010 at 1:29 PM, Sai Pullabhotla > <[email protected]> wrote: >> However, with FTPS (Implicit), the SSL negotiation is initiated prior >> to sending the onConnect event to the Ftplets. To be precise, the >> client does get the server's certificate before onConnect is called. I >> was wondering if this should be done differently so no data is >> exchanged (read/written) unless onConnect of all Ftplets are executed. > > With "data" in this case, we're only talking about the SSL handshake, > right? I think onConnect should indicate that the socket (session) is > established. With SSL, the socket might be ended (e.g due to > certificate validation failing) during the handshake. So, I think the > current behavior is correct. Besides, I think IP restriction is better > handled in the filter chain, rather than in Ftplets which I think > should contain things more like "business logic" (if you excuse the > very broad use of that term :-). > > /niklas >
