Just to add this whole point of security with regard writing out to files, if someone has access to the shell and is able to browse around on your disk looking for such files, then i would say you have lost the security battle anyway !
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Gravagno Sent: 03 September 2010 07:43 To: [email protected] Subject: Re: [U2] running ftp from UV (Windows) > From:George Gallen > Using curl is fine... > But I'm guessing there isn't anyway to load the input stack > like you can with unix. > From: Gregor Scott > GCI...This would allow you to create an interactive program to > control and react to the Windows FTP command, rather than the > blind execution approach you currently have to use on Unix. That reminds me that the libcurl DLL/module might be linked with U2 over any OS via GCI so that you can get better performance than repeatedly executing an out-of-process function. My knowledge of GCI is minimal but I believe some people here have mentioned that they've already done this. About "blind" execution - I know concern has been expressed for writing files to the host OS before executing. At one level I share those concerns, if for security as much as elegance. However, when working outside of the DBMS I've also overridden my own instincts and embraced the usage of files. So for outbound FTP, one implementation I wrote (and have used in many sites) has a .cmd file, a .err file redirected from stderr if required, and a .out output file from stdout, which sometimes needs to be parsed for valuable info. In short I write the delete all files (usually named with a reference to the port/pid), then I write a ..cmd file, then Execute it, then read the other files for the results. Since all MV platforms can write to the host OS as natively as a hashed file, reading and writing this data can all be done in BASIC as though it's "in" the DBMS. Most MV environments can also do this in a secure manner, with proper directory permissions. The requirement to "SH" or "DOS" a command like "cURL" is the only obvious sign that we're doing something outside of the box. Sure, performance of OS I/O and execution is an initial thought but in the big picture such concerns are trivial in this case - and again, many of these external libs can be linked to the DBMS anyway. One of my clients has been using the paradigm described here in a very high profile, high volume environment for something like six years and has never hinted at a performance concern. I'm not strongly encouraging the use of cURL or OS-level utilities, etc. This "side" post is just to encourage everyone to challenge their own preconceptions about why we shun such things. Obviously the rest of the world is successfully using these tools, so I think we should also be thinking more outside of the box, and questioning why we usually don't like to go there. Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! http://Twitter.com/TonyGravagno _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
