Thanks for making the change and sorry for the long delay in replying. Originally, we were looking for a solution where a server would sit in the DMZ that would handle all transfer connections (FTP, FTPS, SFTP, and HTTPS). For security purposes, we did not want authentication done there or have the files persisted in the DMZ, so we needed a way to have the DMZ server stream all data to a server that resided behind the second, internal firewall. This design is seen in products like Tumbleweed's EDGE and Secure Transport servers and Standard Network's MOVEit product.
So I had tried using the Apache FTP server as the front-end connection manager, but implement a RemoteFileSystemView and User manager implementation which made remote EJB calls to get the information it needed. For file retrieval and uploads, I created an FTPLet that would talk to a customized Servlet to download files and a special upload Servlet to upload files. I ran into a snag using Servlet uploading because up through 1.4, the server would buffer the entire file upload before sending it to the server. I had to get around this by making repeated calls to the Servlet with a flag specifying whether it should create a new file or append it. The thing is, we'd actually prefer to have the FTP server behind the firewall now. It would allow users behind the firewall to access the server, and then the SSL endpoint doesn't exist in the DMZ. The other issue is that the FTP server needed to make a call into the secure network to access the EJB server. We'd rather have the "inside" server call out to the DMZ server. I don't know if that's clear or not, but the gist is that we are looking for a design that will allow us to stream uploads and downloads through the DMZ rather than store files there. Gary T. Mui * Vice President * SunGard Transaction Network * 445 Hamilton Avenue * 2nd Floor * White Plains, NY 10601 Tel 914-989-3118 * Fax 914-422-3693 * [EMAIL PROTECTED] * www.sungard.com/stn SunGard Institutional Brokerage Inc. * Member NASD/SIPC CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this email from your system. Thank you. -----Original Message----- From: Rana Bhattacharyya [mailto:[EMAIL PROTECTED] Sent: Thursday, May 18, 2006 12:19 PM To: [email protected] Subject: Re: Access to RequestHandler in ftplet? Hi, Thanks for pointing this. You will fix it asap. FtpRequest should have one method to return the data type. EJB backend idea is interesting. Can you please describe this. It will help us to analyze and define the ftp server interface well. Thanks, Rana Bhattacharyya --- [EMAIL PROTECTED] wrote: > Hi, > > > > Is there a way to get the RequestHandler from within > the invocation of > an Ftplet? I've found that in my onUploadStart, > which uses a > combination of EJB calls and streaming to a Servlet, > I would like to > know if the transfer type is set to binary or ascii. > The STOR command > uses is in streaming data and is gotten out of the > RequestHandler - is > there any way of doing this from our Ftplet which > needs to override that > functionality? > > > > This is my first post so I'd also like to say thanks > for this project. > I implemented an EJB backend to this so that the FTP > Server could sit > safely in the DMZ while doing all user > authentications and file > streaming (via a Servlet) to an application server > sitting behind the > internal firewall. This allows us to not ever store > data in the DMZ. > We are probably going to end up using a different > commercial product > because we need SFTP support, but developing a > potential custom solution > was much easier because of the existence of this > project. > > > > If anyone is interested in an EJB backend, I'd be > happy to discuss. I'm > limited to the code I can post because it is tied to > some of our work > related infrastructure, but I can discuss generally > what was done and > provide some code snippets. If I ever get the time, > I might try to > build an app server backend that would make this a > more > enterprise-friendly option (i.e. streaming to a > backend server outside > the DMZ). > > > > Thanks again, > > > > Gary T. Mui * Vice President * SunGard Transaction > Network * 445 > Hamilton Avenue * 2nd Floor * White Plains, NY 10601 > > Tel 914-989-3118 * Fax 914-422-3693 * > [EMAIL PROTECTED] * > www.sungard.com/stn > <blocked::http://www.sungard.com/stn> > SunGard Institutional Brokerage Inc. * Member > NASD/SIPC > > > > CONFIDENTIALITY: This email (including any > attachments) may contain > confidential, proprietary and privileged > information, and unauthorized > disclosure or use is prohibited. If you received > this email in error, > please notify the sender and delete this email from > your system. Thank > you. > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
