Susmit Sarkar created SSHD-1094:
-----------------------------------
Summary: Help on User Exits before any SFTP commands operation
Key: SSHD-1094
URL: https://issues.apache.org/jira/browse/SSHD-1094
Project: MINA SSHD
Issue Type: Question
Reporter: Susmit Sarkar
Hello Team,
The query is about SFTP commands exits. Before the SFTP commands get executed
we want to hook custom java code during certain pre-defined operations.
For example:
*_IFtpServerUserExit_OnPutFileBeforeExecute_*
Allows you to execute custom java code when FTP server has received command to
put a file. This allows you to read the filename and you can use this to
perform validation and many more. In case your code returns 'false', server
will send a negative reply to client indicating file transfer failure. Also you
can specify error message to be displayed at client end with 451 response code.
*_IFtpServerUserExit_OnPutFileAfterExecute_*
Allows you to execute your code when FTP server has received file but haven't
committed into underlying storage (filesystem). This allows you to read the
file data from an input stream. You can use this to perform things like dumping
file to some temporary location, decline the transfer based on size, performing
content validation and many more. In case your code returns 'false', server
will send a negative reply to client indicating file transfer failure. Also you
can specify error message to be displayed at client end with 451 response code.
I am sharing the git link for your easy reference for my proof of concept,
shall be grateful if you guys help me know the ideal approach to cater the use
case
[https://github.com/Susmit07/sftp-poc/tree/main/sftpserver/src/main/java/com]
SFTPFileSystemAccessor or SFTPEventListener which will be best suited, I am
using both but I am confused which will be ideal to use for the above use-case
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
