Home > Archive > Smalltalk > October 2004 > [VW7.2] Virtual FTP Server
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[VW7.2] Virtual FTP Server
|
|
| Andre Schnoor 2004-10-05, 8:58 pm |
| I'm currently evaluating the implementation of a (pseudo) FTP server that I
can use to deliver downloads wich are created on-demand. Perhaps someone
could point me to some useful information.
The client (IE or Netscape in most cases) is invoked by clicking on an URL
on a web page, where the URL includes a (temporary) user id and password in
the "FTP://..." link. The authentication is only valid for a few minutes, so
subsequent uses of the URL will fail.
The main purposes are:
1. Download URLs must time out (no public sharing)
2. Download access requires authentication (one-time tokens)
3. Downloaded content is personalised
Question: Are there any ST components in existence which I can build upon?
Would it make sense to start from VW's FTP client implementation? While the
control connection is a plain TCP connection, I'm afraid the Data connection
could be quirky.
Or should I just use VW's tiny HTTP server and transfer files via this
protocol? (however, these files are quite large > 12MB).
Thanks in advance for any advice.
Andre
| |
| Ng Pheng Siong 2004-10-06, 4:00 am |
| According to Andre Schnoor <andre.schnoor@web.de>:
> The client (IE or Netscape in most cases) is invoked by clicking on an URL
> on a web page, where the URL includes a (temporary) user id and password in
> the "FTP://..." link. The authentication is only valid for a few minutes, so
> subsequent uses of the URL will fail.
Why not use a so-called capability URL?
ftp://my.server.dom/abdskl8dasjdsaljds/thisfile.zip
The string "abd..." is randomly generated, preferably by a crypto PRNG.
> 1. Download URLs must time out (no public sharing)
That's decided by your server.
> 2. Download access requires authentication (one-time tokens)
A capability is supposed to confer _authorisation_, so with the above
capability, a user X can download thisfile.zip. No need to create a virtual
account for user X nor an access control list that says whether user X is
allowed access to thisfile.zip. Your server decides if said capability is
single-use only or replayable.
> Question: Are there any ST components in existence which I can build upon?
> Would it make sense to start from VW's FTP client implementation? While the
> control connection is a plain TCP connection, I'm afraid the Data connection
> could be quirky.
The data connection is also a plain TCP connection. To be firewall-friendly
you'll probably have to do passive mode.
> Or should I just use VW's tiny HTTP server and transfer files via this
> protocol? (however, these files are quite large > 12MB).
Modern HTTP has features like byte-range fetching and chunking which
facilitate smart clients. Using HTTP should be more client-friendly than
FTP's case of pumping a 12MB file over another TCP connection as an
all-or-nothing proposal.
Does VW's HTTP server supports these? Or any other Smalltalk HTTP server?
Cheers.
--
Ng Pheng Siong <ngps@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
| |
| Andre Schnoor 2004-10-06, 8:57 am |
|
"Ng Pheng Siong" <ngps@netmemetic.com> wrote:
According to Andre Schnoor <andre.schnoor@web.de>:
URL[color=darkred]
in[color=darkred]
minutes, so[color=darkred]
>
> Why not use a so-called capability URL?
>
> ftp://my.server.dom/abdskl8dasjdsaljds/thisfile.zip
The idea is good. But the "files" do not exist. They are created on
demand by ST and ST is the only instance capable of creating them.
Using these URLs with a standard FTP server would involve a lot of
shell scripting with calls to ST. So I thought, a pure ST solution would
be better.
upon?[color=darkred]
the[color=darkred]
connection[color=darkred]
>
> The data connection is also a plain TCP connection. To be
firewall-friendly
> you'll probably have to do passive mode.
It was the "12MB in one piece" you mentioned, which scares me, not
the protocol.
> Modern HTTP has features like byte-range fetching and chunking which
> facilitate smart clients. Using HTTP should be more client-friendly than
> FTP's case of pumping a 12MB file over another TCP connection as an
> all-or-nothing proposal.
As a web user, I experienced more trouble with HTTP downloads
than with FTP downloads over the years. However, this may not be
representative.
> Does VW's HTTP server supports these? Or any other Smalltalk HTTP server?
The TinyHTTP server is not meant to be used in a production environment
as far as I remember.
Andre
| |
| Doug Swartz 2004-10-06, 8:57 am |
|
On 6-Oct-2004, "Andre Schnoor" <andre.schnoor@web.de> wrote:
>
> The idea is good. But the "files" do not exist. They are created on
> demand by ST and ST is the only instance capable of creating them.
In this situation, I have Smalltalk create the file on-the-fly, using an
MD5 hash, or some such, for the URL. Then I redirect the browser to the
URL.
> Using these URLs with a standard FTP server would involve a lot of
> shell scripting with calls to ST. So I thought, a pure ST solution would
> be better.
If you use a redirect, there isn't any scripting involved in the download
itself. The redirect can be to either an HTTP or an FTP server. I use a
script to clean up the files after their lifetime has expired, but the
script is very simple and run by cron every n minutes.
Doug Swartz.
| |
| Ng Pheng Siong 2004-10-06, 4:00 pm |
| According to Andre Schnoor <andre.schnoor@web.de>:
> "Ng Pheng Siong" <ngps@netmemetic.com> wrote:
>
> The idea is good. But the "files" do not exist. They are created on
> demand by ST and ST is the only instance capable of creating them.
> Using these URLs with a standard FTP server would involve a lot of
> shell scripting with calls to ST. So I thought, a pure ST solution would
> be better.
Oh yes, everything is in Smalltalk. These urls are generated and handled by
your Smalltalk FTP server, not by a "regular" FTP server. The advantage of
these urls is that no user accounts are involved.
Your original proposal was a url like this:
ftp://user:password@my.server.dom/thisfile.zip
To handle this in your Smalltalk FTP server, you'd need to implement FTP's
username/password protocol (because that's the protocol the client end is
going to speak when given such a url) and (presumably) code to check that
'user' and 'password' are correct, and also that 'user' is allowed access
to thisfile.zip.
My suggestion,
ftp://my.server.dom/abdskl8dasjdsaljds/thisfile.zip
does away with all that user/password gob. Your server need only implement
anonymous login. Possession of the url is the authorisation to retrieve
thisfile.zip. It doesn't matter whether thisfile.zip is dynamically
generated and streamed by your Smalltalk server or exists as a real file in
the filesystem.
>
> As a web user, I experienced more trouble with HTTP downloads
> than with FTP downloads over the years. However, this may not be
> representative.
Heh. Doubtless caused by smart client software that is too smart by half!
Cheers.
--
Ng Pheng Siong <ngps@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
|
|
|
|
|