Slashdot Mirror

I've done something similar myself, in a corporate intranet environment. It was Perl both ends, not PHP, but it'd work with PHP. It relied on installing some scripts on the client workstations, but you can certainly serve up something like <form action="http://localhost/cgi-bin/stuff"> and/or mix images and iframes from the client and server with wild abandon.

But this requires a webserver (needn't be Apache, even hibachi [link is to old, PD version] will do) and your favourite interpreter on every client machine. Easy to do in the office; probably much harder to do in the big world.

Wrong browser for that joke.

You're not wrong anywhere really. But HTTP was only ever designed to upload one file at a time. What you really want is somehow to embed an FTP client within a web browser {or, locally select a bunch of files and tar them up to upload in one via HTTP}. I had the tech for doing stuff like this a couple of years back. Never got it anywhere bigger than my own intranet, but maybe it's time it had an airing in public and see what other people make of it.

My solution was blindingly simple: have a local Apache server on the client end. Then you can have a server-side application call up something like http://localhost/cgi-bin/foo in an iFrame or pop-up window. This is a script running on the client machine. If you have setuid enabled, so the script can do anything its owner is permitted to do, then the script has access to your bit of the local filesystem. Crucially, it's also not tied to the HTTP connection between your machine and the web server. It could open up an FTP connection of its own, if it wanted to. Or SMTP, POP3, whatever.

As far as security goes, it's not as terrible as it sounds. If we're talking Big Bad Internet, the local machine is almost certain to be behind an ADSL router with NAT, so its apache server is invisible to the world at large. A .htaccess file will make sure. You have to be root to install the scripts properly. They are scripts, so you can audit the source code. If you're really paranoid, you can arrange for your CGI processes to run in a chroot. It should be fully cross-platform, as long as you can persuade a httpd implementation and a suitable programming language to compile on the target platform.

The downside is that people tend to install their web servers with wildly different configurations, and there is no canonical httpd.conf. You could, of course, package a quick and dirty web server. Something like hibachi would do the job; note you would be best using v1.0 {which is in the Public Domain} as the later versions have a rather restrictive licence.

I actually quite liked Hibachi. And not just for the animated logo! You can even run multiple instances on separate ports, and use NAT and port forwarding to get a poor man's virtual server setup.

I'd recommend you stick to v1.0 {which is actually PD}, for licencing reasons. The v2.8 licence is unnecessarily restrictive.

http://hibachi.snert.org:8008/

:0
* ? formail -xFrom: | fgrep -iqsf $FILTER_WHITELIST
{
# Learn this message as non-spam for the bayesian classifier. This is
# better than depending solely on SA's autolearn feature.
:0c:
| sa-learn --ham

# Add a header so that I know this email address was in the whitelist.
:0f: whitelist-header.lock
| formail -A 'X-Whitelisted: Yes'

# into the INBOX.
:0:
$DEFAULT
}

If you're using sendmail you should give milter-sender a look.

It is not a perfect solution, but is sure cuts out a ton of crap from making it into my server.