Interesting solution and since we have our own server, very doable.
(musing ) Though since the user would needs an ID and log in to
access the server (which one must send to them some how, by email,
fax, telephone) not sure how much more that gets you than just
giving the them the FTP log ins directly (which you would need to
give them the same way... if it was not in the stack)... i.e. why not
just give them the FTP log in ID and PASS in the first place? I
suppose because it is less like that single user log in is less
likely to get distributed. and if it did, you would know right away
which user's log in was being abused...(assuming your CGI keeps a log
of the first tier authentications) where as if you distribute the
FTP log ins, then from a given log.. you will never be able to tell,
who is abusing it.
In this case I would open up the FTP access to a CHROOT virtual
domain on the server that was not even on the global DNS matrix, to
be accessed strictly by IP, with all PERL, PHP, and SQL processes
turned off... pretty hard to abuse, other than a service attack
(start uploading gigabytes of stuff...)
tks
Sivakatirswami
On Jun 03, 2005, at 2:54 AM, Dave Cragg wrote:
Where I've had to do this before, I had the the client app load the
FTP credentials from a stack held on a web server. The stack was
obtained through a CGI which authenticated the request. In this
case, the client app itself also had a login system with ID and
password, and these login credentials were used as part of the
authentication process in the CGI.
It wasn't completely secure, but by keeping the credentials on the
server instead of embedded in a local stack, it enabled changing
the FTP user name and password at any time.
Dave
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
