Re: VFP 9: Help with sending/receiving XML via FTP

John Dandy schrieb:

It seems web service would be overkill for what I'm attempting to do.
Thought so - but sometimes tackling a problem with a slightly "overcharged" solution teaches a bit - you are certain you are fit for other probs afterwards.

Each user on the system would have their own unique FTP login and directory. The VFP application connects to the FTP server and directory for the user. Once connected, XML files are exchanged.

ANY server is a slight risk - it depends on the calibre of the admin and the OS used.

One potential problem would be a user logging onto the server with FTP client. Once connected with his login and password, he could navigate other user directories and might even cause some damage.

IMHO security aspects are better controlled by email approach. Especially if you have to give access to more than a handful of people -
remember the risk is 1 - (1-risk1User)**Nuser. The result often surprizes when calculated.

The information is not so sensitive that data encryption would be necessary.
Hint from someone in the same industry in germany - think about it, play around with it, if you happen to read about it, get your brain into "working mode" to remember better. Be prepared to answer the coming questions - I have seen too many setups where security was slapped on in a hurry. I think no security would be better than some of the easy breakable things, as it gives a false sense of security.


Based on the security built the VFP application and how it connects to the FTP server and the risks of someone connecting with FTP client, would you still recommend email?
Yupp. Technology in itself is so used that "administration" can be handled by almost anybody - less need for admin knowledge. Security level much higher, much of the intended fuctionality (ACK, protocol) already built in. The metaphor is probably closer.

Enough pre-built code on the vfp side availabe. A well rounded (although perhaps a bit dated) overview of possible technologies is in megafox by Akins,Kramek &Schummer, where you find also some base classes solid enough to grow upon. Recommended, if you don't have a familiar starting point already: you save many H checking out the different routines available and have more surrounding commentary than any possible routine. And the technology hasn't changed that much - it is often sold only under a different name <g>.

We have Webservices and email integrated, and the email parts are always easier to handle <g>. For instance we use different email recient adresses for different marketing campaigns and each agent sends back his answer on participation, number of leads asked for and so on. We identify the agent by parsing the automatically created email text -
so there is no need to create a couply of thousend return adresses.
YMMV here, but the originating adress helps a lot if anything goes wrong. You still can search along the entire mail slot tree...

my 0.04 (I've done it <g>) EUR

thomas

.

Relevant Pages