You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-users@mina.apache.org by Sai Pullabhotla <sa...@jmethods.com> on 2008/11/14 15:13:55 UTC
Question on Ftplets
Dear Developers,
I've been trying to use the Ftplets for audit log purposes. Basically I
would like to implement the Ftplet interface or extend the DefaultFtplet
class and implement/override the appropriate methods. For example, if I
choose to go with extending the DefaultFtplet class, I would like to
override the onDeleteEnd method, and within this method, I would like to
determine if the Delete operation was sucessful or not. Based on the result,
I would like to add a record to my audit log table (e.g. User xyz deleted
file foo or User xyz tried to delete the file foo, but it failed for XYZ
reason).
However, I could not find a way to know the actual result of the command
that was just finished. The only parameters we get in the call back method
are FtpSession and FtpRequest. Neither of these parameters tell me what the
result of the command was. Do you think we need to change the signature of
the afterCommand method to include the FtpReply as well? Or add a new method
in the FtpSession which will return the last FtpReply? (e.g.
FtpSession.getLastFtpReply()).
I look forward for your suggestions/comments.
Thanks.
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
Re: Question on Ftplets
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Nov 17, 2008 at 1:11 PM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> Talking about multiple replies, are you talking about the positive
> preliminary replies (1YZ type), such as 150 Opening data connection?
Yes.
> If so, I'm not sure if that is something the Ftplet implementations
> would be really interested in. They definitely want to know if the
> data connection fails, which should work with the code I already have
> using a single reply.
You might very well be right, lets gather some more input. What do the
rest of you think? Should Ftplets get all replies or the final one
only?
/niklas
Re: Question on Ftplets
Posted by Sai Pullabhotla <sa...@jmethods.com>.
Niklas,
Talking about multiple replies, are you talking about the positive
preliminary replies (1YZ type), such as 150 Opening data connection?
If so, I'm not sure if that is something the Ftplet implementations
would be really interested in. They definitely want to know if the
data connection fails, which should work with the code I already have
using a single reply.
If you still think we need to send these preliminary replies to the
Ftplets, let me know. I can make it a List <FtpReply>. Let me know if
you rather prefer a different approach than the using List.
Thanks and Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Sun, Nov 16, 2008 at 10:14 AM, Niklas Gustavsson
<ni...@protocol7.com> wrote:
> On Sun, Nov 16, 2008 at 4:09 PM, Sai Pullabhotla
> <sa...@jmethods.com> wrote:
>> I started changing the code the way we talked and found the following:
>>
>> The only common place where all FtpReplies go out seems to be from the
>> FtpIOSession.writeObject() method. So, I updated this method to store
>> the last reply in an instance variable of FtpIOSession class. Below is
>> the new writeObject method:
>>
>> public WriteFuture write(Object message) {
>> WriteFuture future = wrappedSession.write(message);
>> this.lastReply = (FtpReply) message;
>> return future;
>> }
>>
>>
>> Then in the DefaultFtpHandler, line 144ish, added the new parameter on
>> the call to ftplet.afterCommand.
>>
>> try {
>> ftpletRet = ftplets.afterCommand(session.getFtpletSession(),
>> request, session.getLastReply());
>> } catch (Exception e) {
>> LOG.debug("Ftplet container threw exception", e);
>> ftpletRet = FtpletResult.DISCONNECT;
>> }
>
> As noted before, multiple replies can be returned on one command (e.g.
> during a STOR), thus the patch needs support for this. Also, it will
> need unit tests for all functionality.
>
>> So, the question to you is, do we really want to change the signature
>> of Ftplet.afterCommand to include the FtpReply parameter or just have
>> the Ftplet implementations retrieve the last reply from the
>> FtpSession/FtpIoSession?
>
> I would like it in the Ftplet callback rather than the session.
>
>> Also, for passing additional information about the result of a command
>> (as discussed in my previous email), I was thinking we should have a
>> return value from the execute() method of Command class. This return
>> type could be a ExecutionResult object which can be
>> implemented/overridden by various commands to provide results with
>> different parameters. If you like this idea, then need to update the
>> Ftplet afterCommand method to simply include the ExecutionResult
>> parameter which tells callers all about the result.
>>
>> In summary, I think we need to change the
>> void execute(FtpIoSession, FtpServerContext, FtpRequest)
>> to
>> ExecutionResult execute(FtpIoSession, FtpServerContext, FtpRequest)
>
> Let's wait with this patch, I don't think the change in the interface
> is necessary and we can hold this until after 1.0.
>
> /niklas
>
Re: Question on Ftplets
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, Nov 16, 2008 at 4:09 PM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> I started changing the code the way we talked and found the following:
>
> The only common place where all FtpReplies go out seems to be from the
> FtpIOSession.writeObject() method. So, I updated this method to store
> the last reply in an instance variable of FtpIOSession class. Below is
> the new writeObject method:
>
> public WriteFuture write(Object message) {
> WriteFuture future = wrappedSession.write(message);
> this.lastReply = (FtpReply) message;
> return future;
> }
>
>
> Then in the DefaultFtpHandler, line 144ish, added the new parameter on
> the call to ftplet.afterCommand.
>
> try {
> ftpletRet = ftplets.afterCommand(session.getFtpletSession(),
> request, session.getLastReply());
> } catch (Exception e) {
> LOG.debug("Ftplet container threw exception", e);
> ftpletRet = FtpletResult.DISCONNECT;
> }
As noted before, multiple replies can be returned on one command (e.g.
during a STOR), thus the patch needs support for this. Also, it will
need unit tests for all functionality.
> So, the question to you is, do we really want to change the signature
> of Ftplet.afterCommand to include the FtpReply parameter or just have
> the Ftplet implementations retrieve the last reply from the
> FtpSession/FtpIoSession?
I would like it in the Ftplet callback rather than the session.
> Also, for passing additional information about the result of a command
> (as discussed in my previous email), I was thinking we should have a
> return value from the execute() method of Command class. This return
> type could be a ExecutionResult object which can be
> implemented/overridden by various commands to provide results with
> different parameters. If you like this idea, then need to update the
> Ftplet afterCommand method to simply include the ExecutionResult
> parameter which tells callers all about the result.
>
> In summary, I think we need to change the
> void execute(FtpIoSession, FtpServerContext, FtpRequest)
> to
> ExecutionResult execute(FtpIoSession, FtpServerContext, FtpRequest)
Let's wait with this patch, I don't think the change in the interface
is necessary and we can hold this until after 1.0.
/niklas
Re: Question on Ftplets
Posted by Sai Pullabhotla <sa...@jmethods.com>.
Niklas,
I started changing the code the way we talked and found the following:
The only common place where all FtpReplies go out seems to be from the
FtpIOSession.writeObject() method. So, I updated this method to store
the last reply in an instance variable of FtpIOSession class. Below is
the new writeObject method:
public WriteFuture write(Object message) {
WriteFuture future = wrappedSession.write(message);
this.lastReply = (FtpReply) message;
return future;
}
Then in the DefaultFtpHandler, line 144ish, added the new parameter on
the call to ftplet.afterCommand.
try {
ftpletRet = ftplets.afterCommand(session.getFtpletSession(),
request, session.getLastReply());
} catch (Exception e) {
LOG.debug("Ftplet container threw exception", e);
ftpletRet = FtpletResult.DISCONNECT;
}
So, the question to you is, do we really want to change the signature
of Ftplet.afterCommand to include the FtpReply parameter or just have
the Ftplet implementations retrieve the last reply from the
FtpSession/FtpIoSession?
Logically, it definitely makes sense to have the parameter, but it is
not required technically. I will wait for your response on this.
Also, for passing additional information about the result of a command
(as discussed in my previous email), I was thinking we should have a
return value from the execute() method of Command class. This return
type could be a ExecutionResult object which can be
implemented/overridden by various commands to provide results with
different parameters. If you like this idea, then need to update the
Ftplet afterCommand method to simply include the ExecutionResult
parameter which tells callers all about the result.
In summary, I think we need to change the
void execute(FtpIoSession, FtpServerContext, FtpRequest)
to
ExecutionResult execute(FtpIoSession, FtpServerContext, FtpRequest)
Let me know what you think.
Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Sat, Nov 15, 2008 at 2:20 AM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Fri, Nov 14, 2008 at 11:35 PM, Sai Pullabhotla
> <sa...@jmethods.com> wrote:
>> What do you think of the following change:
>>
>> Change the signature of Ftplet.afterCommand to -
>>
>> FtpletResult afterCommand(FtpSession session, FtpRequest request,
>> FtpReply reply)
>> throws FtpException, IOException;
>
> As noted in an earlier mail on this thread, multiple replies might
> have been sent for one request, meaning we need to provide a list of
> replies. Besides that, I like this change.
>
>> I know this breaks the existing applications that are using this
>> interface, but I'm not sure if there is a way to prevent this.
>
> Meaning it has to go into M4 (I hope to have a stable public API in
> M4), so we should have it done quickly.
>
>> Implemntations can then check to see if reply.getCode() and see if it
>> is a Positive Completion Reply (2XX) which means, the requested action
>> was successful. A 4xx or 5xx message means that the requested action
>> has failed.
>>
>> The implementations can then process the parameters of FtpRequest and
>> get any additional details such as file name that the command acted
>> on, its size etc.
>>
>> This would be a good beginning. However, if we want to take it one
>> more step further, It is not a bad idea to create subclasses of
>> DefaultFtpReply to include some more additional information. For e.g.
>> create a new class FtpUploadReply as shown below:
>>
>> public class FtpUploadReply extends DefaultFtpReply {
>> private FileObject file = null;
>> private long bytesReceived = 0L; //This may not be needed, as it
>> could be retrieved from the FileObject.
>> private long transferStartTime = 0L;
>> private long transferEndTime = 0L;
>> }
>
> We might need to think some further on the details, but I like the
> change in general. However, as this is a non-breaking change, we can
> do this later. For now we should focus on the change above.
>
>> Hope this all makes sense. Let me know what you think and if you would
>> like me to work on this.
>
> Feel free to take a stab. First of all, add JIRA issues describing the
> improvements you would like to see and then we'll attempt to get the
> first change into M4.
>
> /niklas
>
Re: Question on Ftplets
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Fri, Nov 14, 2008 at 11:35 PM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> What do you think of the following change:
>
> Change the signature of Ftplet.afterCommand to -
>
> FtpletResult afterCommand(FtpSession session, FtpRequest request,
> FtpReply reply)
> throws FtpException, IOException;
As noted in an earlier mail on this thread, multiple replies might
have been sent for one request, meaning we need to provide a list of
replies. Besides that, I like this change.
> I know this breaks the existing applications that are using this
> interface, but I'm not sure if there is a way to prevent this.
Meaning it has to go into M4 (I hope to have a stable public API in
M4), so we should have it done quickly.
> Implemntations can then check to see if reply.getCode() and see if it
> is a Positive Completion Reply (2XX) which means, the requested action
> was successful. A 4xx or 5xx message means that the requested action
> has failed.
>
> The implementations can then process the parameters of FtpRequest and
> get any additional details such as file name that the command acted
> on, its size etc.
>
> This would be a good beginning. However, if we want to take it one
> more step further, It is not a bad idea to create subclasses of
> DefaultFtpReply to include some more additional information. For e.g.
> create a new class FtpUploadReply as shown below:
>
> public class FtpUploadReply extends DefaultFtpReply {
> private FileObject file = null;
> private long bytesReceived = 0L; //This may not be needed, as it
> could be retrieved from the FileObject.
> private long transferStartTime = 0L;
> private long transferEndTime = 0L;
> }
We might need to think some further on the details, but I like the
change in general. However, as this is a non-breaking change, we can
do this later. For now we should focus on the change above.
> Hope this all makes sense. Let me know what you think and if you would
> like me to work on this.
Feel free to take a stab. First of all, add JIRA issues describing the
improvements you would like to see and then we'll attempt to get the
first change into M4.
/niklas
Re: Question on Ftplets
Posted by Sai Pullabhotla <sa...@jmethods.com>.
What do you think of the following change:
Change the signature of Ftplet.afterCommand to -
FtpletResult afterCommand(FtpSession session, FtpRequest request,
FtpReply reply)
throws FtpException, IOException;
I know this breaks the existing applications that are using this
interface, but I'm not sure if there is a way to prevent this.
Implemntations can then check to see if reply.getCode() and see if it
is a Positive Completion Reply (2XX) which means, the requested action
was successful. A 4xx or 5xx message means that the requested action
has failed.
The implementations can then process the parameters of FtpRequest and
get any additional details such as file name that the command acted
on, its size etc.
This would be a good beginning. However, if we want to take it one
more step further, It is not a bad idea to create subclasses of
DefaultFtpReply to include some more additional information. For e.g.
create a new class FtpUploadReply as shown below:
public class FtpUploadReply extends DefaultFtpReply {
private FileObject file = null;
private long bytesReceived = 0L; //This may not be needed, as it
could be retrieved from the FileObject.
private long transferStartTime = 0L;
private long transferEndTime = 0L;
}
Provide accessor methods for the above instance variables.
Implementations of Ftplet interface can then check the type of
FtpReply first and typecast it to the real type and retrieve the
available information from the FtpReply.
Finally, update the DefaultFtplet to match up with the new interface.
Update the call to afterCommand to include the new parameter.
Hope this all makes sense. Let me know what you think and if you would
like me to work on this.
Thanks.
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Fri, Nov 14, 2008 at 3:32 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Fri, Nov 14, 2008 at 10:16 PM, Sai Pullabhotla
> <sa...@jmethods.com> wrote:
>> Thanks for the quick reply. I apologize for not being very specific in
>> my previous post. I used the FileObserver interface which allows me to
>> receive notification of various file events such as download, upload,
>> mkdir etc. These notifications also contain the FtpIoSession which in
>> turn contains information of the user, remote address etc. which is
>> what I mainly need for the audit log. However, these notifications are
>> available only when the user requested action is successful. However,
>> I would like to log any unsuccessful requests as well. So, the
>> FileObserver alone cannot get me what I want.
>
> Right, I would say that your original idea of using an Ftplet is
> probably the best option, at least given that we could provide you the
> replies.
>
> /niklas
>
Re: Question on Ftplets
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Fri, Nov 14, 2008 at 10:16 PM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> Thanks for the quick reply. I apologize for not being very specific in
> my previous post. I used the FileObserver interface which allows me to
> receive notification of various file events such as download, upload,
> mkdir etc. These notifications also contain the FtpIoSession which in
> turn contains information of the user, remote address etc. which is
> what I mainly need for the audit log. However, these notifications are
> available only when the user requested action is successful. However,
> I would like to log any unsuccessful requests as well. So, the
> FileObserver alone cannot get me what I want.
Right, I would say that your original idea of using an Ftplet is
probably the best option, at least given that we could provide you the
replies.
/niklas
Re: Question on Ftplets
Posted by Sai Pullabhotla <sa...@jmethods.com>.
Niklas,
Thanks for the quick reply. I apologize for not being very specific in
my previous post. I used the FileObserver interface which allows me to
receive notification of various file events such as download, upload,
mkdir etc. These notifications also contain the FtpIoSession which in
turn contains information of the user, remote address etc. which is
what I mainly need for the audit log. However, these notifications are
available only when the user requested action is successful. However,
I would like to log any unsuccessful requests as well. So, the
FileObserver alone cannot get me what I want.
Do you have any other suggestions? I personally would prefer to extend
the functionality of Ftplet to send more information on the
afterCommand method call. This approach seems to be more straight
forward and easy to implement. What do you think? If you agree, I
would be glad to help you with design/coding.
FYI, here is the snippet of code that works for me to some extent
using the FileObserver:
ServerFtpStatistics stats = (ServerFtpStatistics)
server.getServerContext().getFtpStatistics();
stats.setFileObserver(new FileObserver() {
public void notifyDelete(FtpIoSession session, FileObject file) {
System.out.println("**********************************");
System.out.println("Remote Address: "
+ session.getRemoteAddress());
System.out.println("Session ID: " + session.getId());
System.out.println("User: " + session.getUser());
System.out.println("Description: " + "File "
+ ((NativeFileObject)file).getPhysicalFile() + "
was deleted");
System.out.println("**********************************");
}
public void notifyDownload(FtpIoSession session, FileObject file,
long size) {
System.out.println("**********************************");
System.out.println("Remote Address: "
+ session.getRemoteAddress());
System.out.println("Session ID: " + session.getId());
System.out.println("User: " + session.getUser());
System.out.println("Description: " + "File "
+ ((NativeFileObject)file).getPhysicalFile() + "
was downloaded");
System.out.println("File Size: " + size);
System.out.println("**********************************");
}
public void notifyMkdir(FtpIoSession arg0, FileObject arg1) {
//TODO implement
}
public void notifyRmdir(FtpIoSession arg0, FileObject arg1) {
//TODO implement
}
public void notifyUpload(FtpIoSession session, FileObject file,
long size) {
System.out.println("**********************************");
System.out.println("Remote Address: "
+ session.getRemoteAddress());
System.out.println("Session ID: " + session.getId());
System.out.println("User: " + session.getUser());
System.out.println("Description: " + "File "
+ ((NativeFileObject)file).getPhysicalFile() + "
was uploaded");
System.out.println("File Size: " + size);
System.out.println("**********************************");
}
});
I look forward to hearing from you with any ideas/comments.
Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Fri, Nov 14, 2008 at 2:54 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
>
> On Fri, Nov 14, 2008 at 9:47 PM, Sai Pullabhotla
> <sa...@jmethods.com> wrote:
> > I digged into the code and javadoc some more and found that I could achieve
> > the functionality I want by using the FtpStatistics/ServerFtpStatistics
> > interface. Is this the correct way to go?
>
> If what you need are the number of occurrences of different actions, then yes.
>
> /niklas
Re: Question on Ftplets
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Fri, Nov 14, 2008 at 9:47 PM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> I digged into the code and javadoc some more and found that I could achieve
> the functionality I want by using the FtpStatistics/ServerFtpStatistics
> interface. Is this the correct way to go?
If what you need are the number of occurrences of different actions, then yes.
/niklas
Re: Question on Ftplets
Posted by Sai Pullabhotla <sa...@jmethods.com>.
I digged into the code and javadoc some more and found that I could achieve
the functionality I want by using the FtpStatistics/ServerFtpStatistics
interface. Is this the correct way to go?
Thanks.
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Fri, Nov 14, 2008 at 8:13 AM, Sai Pullabhotla <
sai.pullabhotla@jmethods.com> wrote:
> Dear Developers,
>
> I've been trying to use the Ftplets for audit log purposes. Basically I
> would like to implement the Ftplet interface or extend the DefaultFtplet
> class and implement/override the appropriate methods. For example, if I
> choose to go with extending the DefaultFtplet class, I would like to
> override the onDeleteEnd method, and within this method, I would like to
> determine if the Delete operation was sucessful or not. Based on the result,
> I would like to add a record to my audit log table (e.g. User xyz deleted
> file foo or User xyz tried to delete the file foo, but it failed for XYZ
> reason).
>
> However, I could not find a way to know the actual result of the command
> that was just finished. The only parameters we get in the call back method
> are FtpSession and FtpRequest. Neither of these parameters tell me what the
> result of the command was. Do you think we need to change the signature of
> the afterCommand method to include the FtpReply as well? Or add a new method
> in the FtpSession which will return the last FtpReply? (e.g.
> FtpSession.getLastFtpReply()).
>
> I look forward for your suggestions/comments.
>
> Thanks.
>
> Sai Pullabhotla
> Phone: (402) 408-5753
> Fax: (402) 408-6861
> www.jMethods.com
>
>