Re: Download images/movies
Hi Andy,
Yup, that was it. I was using a relative path, not abslute. That fixed
it. I script now works great in Netscape and Safari, but not in IE.
(All on a Mac - I'll check out the PC tomorrow). IE just displays the
graphic but doesn't download it. The script does not seem to be
overriding whatever the settings are in IE regarding MIME types and
what to do with them -- I'm guessing. Is there a way to override that?
Thanks again for your help.
Mark
On Aug 24, 2004, at 6:17 PM, Andrew Mace wrote:
$path is a system path, right? As in, like, not relative to the
webserver? Just making sure...
Also, I messed up and used $length in one place and $size in another,
though that doesn't explain your troubles.
I mean, you could do a lot of things to debug. A quick thing you could
do would be to change the content type to image/jpeg and remove the
Content-Disposition and see what gets put into your browser. Since
you're writing the HTTP headers before attempting to open the file, my
suspicion is that there's something wrong with the path to the file and
your script is exiting prematurely.
Andy
On Aug 24, 2004, at 8:23 PM, Mark Wheeler wrote:
Hi Andy,
Thanks for the input. I should have check the read/write method --
my bad.
I tried both the slurp and the read methods, but the same thing still
happens. On a PC the save dialog comes up but the file saved is 0k,
and on a Mac, the the progress bar is just a spinning barber poll. Any
ideas?
Thanks,
Mark
On Aug 24, 2004, at 3:56 PM, Andrew Mace wrote:
Hey Mark -
A few things.
- You want to open the file for reading, not to write.
- You should undef $/ to slurp the file if you're using to read.
- You should stat the file before opening it to add the
Content-Length header, if you want.
- For larger files, it would make more sense to use read() calls
instead of slurping the entire file into memory.
So here's an updated version:
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
my $filename = param('picname');
my $path = /images/$filename;
my $length = (stat($path))[7]; # the size, in bytes
binmode STDOUT;
print Content-Length: $size\n;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
open (FILE, $path) || die(Can't open($filename): $!);
binmode(FILE);
# slurp method:
undef $/;
my $data = FILE;
close (FILE);
print $data;
# read() method would be:
while(read(FILE,$data,4096)) {
print $data;
}
close(FILE);
exit;
Good luck
Andy
On Aug 24, 2004, at 6:19 PM, Mark Wheeler wrote:
Hi all,
Here is my first attempt to write this script. I will be adding the
protection/whitelisting/etc. after I get the basic this running.
Here is what I have so far, and here is what happens. On a PC, the
dialog box comes up and saves the file, but it is 0K -- nothing in
it. On a Mac, the Downloads dialog box comes up, but the progress
bar keeps spinning and nothing happens. Below is the HTML that calls
the script and the CGI script itself. What did I forget/do wrong?
Thanks,
Mark
-
html
head
titleUntitled Page/title
/head
body
a
href=javascript:window.location='cgi-bin/download.cgi?
picname=Upload-Background.gif'picture link/a
/body
/html
-
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
my $filename = param('picname');
my $path = /images/$filename;
binmode STDOUT;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
open (FILE, $path) || die(Can't open($filename): $!);
my $data = FILE;
close (FILE);
print $data;
exit;
-
On Aug 23, 2004, at 2:45 PM, Joel Rees wrote:
I think that's what I'm looking for. One question. What do you
mean whitelist the filepaths. My only reference point is email.
Whitelist for me means that email address on my whitelist
always get through, even though the spam software might initially
think it's spam. Can you clarify?
If the script I posted was readable, you might have noticed that it
accepts one parameter and sets the directories only if that
parameter matches correctly. It looks like a waste, but it's one
way of what he was calling whitelisting in a fairly strict way, but
allowing the same script to be used on multiple sets of images. You
do have to add a little code for each set of images, of course.
That script needs some comments.
--
Joel Rees
Getting involved in the neighbor's family squabbles is
dangerous.
But if the abusive partner has a habit of shooting through
his/her roof,
the guy who lives upstairs is in a bit of a catch-22.
Brand New Empty Mac
This is a not-strictly-Perl thing again, but I'm just about to inherit a G4 desktop from up the food chain at work, and it's been so comprehensively messed about with that I'm going to low-level-format the HD completely and start from scratch. Apart from anything else, this will mean I can install Panther and only Panther and I won't have any of those 'which perl' issues or multiple copies of modules. But I just thought I'd get the opinions of the list on the best way to set up such a brand-new machine -- do you partition your hard-drives? Do you have the system on one partition and documents on another and so on? Any issues around the installation of Perl and other things like C libraries that I should be thinking about? Have You Validated Your Code? John Horner(+612 / 02) 9333 2110 Senior Developer, ABC Online http://www.abc.net.au/
Re: Brand New Empty Mac
On Wed, 25 Aug 2004, John Horner wrote: [D]o you partition your hard-drives? Do you have the system on one partition and documents on another and so on? No. I did that with my first Macs, but always regretted it. Just leave it as one volume -- there's very little to gain by partitioning it. Any issues around the installation of Perl and other things like C libraries that I should be thinking about? http://www.mail-archive.com/macosx%40perl.org/msg05736.html Quoting the relevant bit there -- There's an unpatched bug with the system Perl that prevents some modules (notably DBD::mysql) from building properly. ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' with ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc' Other than that, things should Just Work. -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/blog/ np: 'Hill Street Blues' from 'Television Theme Songs'
Re: Download images/movies
IE just displays the graphic but doesn't download it. The script does
not seem to be overriding whatever the settings are in IE regarding
MIME types and what to do with them -- I'm guessing. Is there a way to
override that?
You could try changing the Content-Type to application/download. The
problem is Mac IE will show the save as prompt, but it will be the name
of your script (download.pl) and not the filename you specified in the
HTTP header. I haven't found any workaround for this. When I've done
things like this in the past I've ended up using Apache conf settings
like Chris' suggestion, though I'm realizing as I'm writing this that
using $ENV{PATH_INFO} instead of the query string might solve that
problem - take a look at the other Andy's suggestion for how to use
that:
a
href=javascript:window.location='cgi-bin/download.cgi/Upload-
Background.gif'picture link/a
my $filename = $ENV{'PATH_INFO'};
Good luck
Andy
On Aug 24, 2004, at 6:17 PM, Andrew Mace wrote:
$path is a system path, right? As in, like, not relative to the
webserver? Just making sure...
Also, I messed up and used $length in one place and $size in another,
though that doesn't explain your troubles.
I mean, you could do a lot of things to debug. A quick thing you
could do would be to change the content type to image/jpeg and remove
the Content-Disposition and see what gets put into your browser.
Since you're writing the HTTP headers before attempting to open the
file, my suspicion is that there's something wrong with the path to
the file and your script is exiting prematurely.
Andy
On Aug 24, 2004, at 8:23 PM, Mark Wheeler wrote:
Hi Andy,
Thanks for the input. I should have check the read/write method --
my bad.
I tried both the slurp and the read methods, but the same thing still
happens. On a PC the save dialog comes up but the file saved is 0k,
and on a Mac, the the progress bar is just a spinning barber poll.
Any ideas?
Thanks,
Mark
On Aug 24, 2004, at 3:56 PM, Andrew Mace wrote:
Hey Mark -
A few things.
- You want to open the file for reading, not to write.
- You should undef $/ to slurp the file if you're using to read.
- You should stat the file before opening it to add the
Content-Length header, if you want.
- For larger files, it would make more sense to use read() calls
instead of slurping the entire file into memory.
So here's an updated version:
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
my $filename = param('picname');
my $path = /images/$filename;
my $length = (stat($path))[7]; # the size, in bytes
binmode STDOUT;
print Content-Length: $size\n;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
open (FILE, $path) || die(Can't open($filename): $!);
binmode(FILE);
# slurp method:
undef $/;
my $data = FILE;
close (FILE);
print $data;
# read() method would be:
while(read(FILE,$data,4096)) {
print $data;
}
close(FILE);
exit;
Good luck
Andy
On Aug 24, 2004, at 6:19 PM, Mark Wheeler wrote:
Hi all,
Here is my first attempt to write this script. I will be adding the
protection/whitelisting/etc. after I get the basic this running.
Here is what I have so far, and here is what happens. On a PC, the
dialog box comes up and saves the file, but it is 0K -- nothing in
it. On a Mac, the Downloads dialog box comes up, but the progress
bar keeps spinning and nothing happens. Below is the HTML that
calls the script and the CGI script itself. What did I forget/do
wrong?
Thanks,
Mark
-
html
head
titleUntitled Page/title
/head
body
a
href=javascript:window.location='cgi-bin/download.cgi?
picname=Upload-Background.gif'picture link/a
/body
/html
-
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
my $filename = param('picname');
my $path = /images/$filename;
binmode STDOUT;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
open (FILE, $path) || die(Can't open($filename): $!);
my $data = FILE;
close (FILE);
print $data;
exit;
-
On Aug 23, 2004, at 2:45 PM, Joel Rees wrote:
I think that's what I'm looking for. One question. What do you
mean whitelist the filepaths. My only reference point is
email. Whitelist for me means that email address on my
whitelist always get through, even though the spam software
might initially think it's spam. Can you clarify?
If the script I posted was readable, you might have noticed that
it accepts one parameter and sets the directories only if that
parameter matches correctly. It looks like a waste, but it's one
way of what he was calling whitelisting in a fairly strict way,
but allowing the same script to be used on multiple sets of
images. You do have to add a little code for each set of images,
of
Re: Download images/movies
Andrew Mace wrote: IE just displays the graphic but doesn't download it. The script does not seem to be overriding whatever the settings are in IE regarding MIME types and what to do with them -- I'm guessing. Is there a way to override that? You could try changing the Content-Type to application/download. The problem is Mac IE will show the save as prompt, but it will be the name of your script (download.pl) and not the filename you specified in the HTTP header. Doesn't it save it to disk with the correct name though? (IIRC) Of course I'd just hope the number of Mac IE browsers is dropping everyday... Pete
Re: Download images/movies
Just a few nosy comments --
html
head
titleUntitled Page/title
/head
body
a
href=javascript:window.location='cgi-bin/download.cgi?picname=Upload-
Background.gif'picture link/a
Not sure why you want to bother with javascript in there. ICBW, but I
don't think it buys you anything. And some of your family may decide to
turn javascript in their browsers off.
/body
/html
-
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
I didn't notice that you had used anything from CGI in the script.
Might as well comment it out.
my $filename = param('picname');
Did you follow what was said about ../../ someodd with /etc at the end?
It's a good way to dump all sorts of things about your machine into
someone else's browser, including user names and ids, the entire
httpd.conf file, and so forth.
That's why I don't usually accept filenames in scripts. But if you do,
you need to check for / at the top or ../ anywhere, and balk if you get
those. It can get kind of tricky, since \/ is /.
my $path = /images/$filename;
For instance, somebody puts this in their browser:
http://your.domain.com/cgi-bin/download.cgi?picname=../etc/httpd/
httpd.conf
binmode STDOUT;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
If you _had_ been using CGI, the above two lines could have created
some subtle conflicts.
open (FILE, $path) || die(Can't open($filename): $!);
This is why you got the attempted download that stalled, of course.
That die statement won't do much useful. Well, if it were going out
STDOUT, it might have shown up as your downloaded file.
You'll want to look into using a logging file or the http version of
carp.
my $data = FILE;
close (FILE);
print $data;
exit;
--
Joel Rees
Nothing to say today
so I'll say nothing:
Nothing.
[OT]Re: Brand New Empty Mac
But I just thought I'd get the opinions of the list on the best way to set up such a brand-new machine -- do you partition your hard-drives? I usually do. But on a Mac, I have decided not to to be play too smart. I'll usually format a gig or two for classic and leave the rest to the boot drive. I have not satisfied myself that there is any advantage to a swap partition, and I won't mention why here. On the other hand, Apple may have decided to let fstab have some so in Panther, in which case a separate swap partition can help smooth the virtual memory system a bit. Some of your Mac OS X applications may throw a hissy if they are not on the boot partition, or if the users are not on the boot partition, so you lose most of anything you'd gain with separate /home or /usr. And the automount puts everything under /Volumes, anyway. However, if you plan to serve the web with that box, a separate partition for web stuff might give you warm fuzzies and maybe even some real protection. Just make sure you format any partition(s) for web as Unix File System, instead of HFS+. That way you should actually get the permissions bits to work right. I might also have another UFS partition for PostGreSQL and other such. I also keep a spare hugh partition if I can, for downloads and large images. If you have a bigfiles partition it should be HFS+, of course. Do you have the system on one partition and documents on another and so on? No, that just buys you heartache in Mac OS X, of present. Any issues around the installation of Perl and other things like C libraries that I should be thinking about? I like to have multiple users, one for doing serious work in, one, perhaps with limits on it, for surfing, and, of course. I also like to make two administrator accounts, just in case something goes haywire in one. Most people don't really need to bother with anything fancy, just let the install set up run. -- Joel Rees If God had meant for us to not tweak our source code, He'd've given us Microsoft.
Re: Download images/movies
Hi Joel,
Thanks for your input. In regards to filename, I'm assuming you are
talking about the filename passed within the HTML, right? I think what
I will probably do is pass an ID number to the script and then process
it that way. I will still check for ../ andywhere the passed ID, as
well as / at the beginning of the ID. You mentioned that V is /.
Im afraid you lost me there. Can you explain?
Thanks,
Mark
On Aug 25, 2004, at 8:16 AM, Joel Rees wrote:
Just a few nosy comments --
html
head
titleUntitled Page/title
/head
body
a
href=javascript:window.location='cgi-bin/download.cgi?
picname=Upload-Background.gif'picture link/a
Not sure why you want to bother with javascript in there. ICBW, but I
don't think it buys you anything. And some of your family may decide
to turn javascript in their browsers off.
/body
/html
-
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
I didn't notice that you had used anything from CGI in the script.
Might as well comment it out.
my $filename = param('picname');
Did you follow what was said about ../../ someodd with /etc at the end?
It's a good way to dump all sorts of things about your machine into
someone else's browser, including user names and ids, the entire
httpd.conf file, and so forth.
That's why I don't usually accept filenames in scripts. But if you do,
you need to check for / at the top or ../ anywhere, and balk if you
get those. It can get kind of tricky, since \/ is /.
my $path = /images/$filename;
For instance, somebody puts this in their browser:
http://your.domain.com/cgi-bin/download.cgi?picname=../etc/httpd/
httpd.conf
binmode STDOUT;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
If you _had_ been using CGI, the above two lines could have created
some subtle conflicts.
open (FILE, $path) || die(Can't open($filename): $!);
This is why you got the attempted download that stalled, of course.
That die statement won't do much useful. Well, if it were going out
STDOUT, it might have shown up as your downloaded file.
You'll want to look into using a logging file or the http version of
carp.
my $data = FILE;
close (FILE);
print $data;
exit;
--
Joel Rees
Nothing to say today
so I'll say nothing:
Nothing.
Re: Download images/movies
Hi Andy,
I'll give it a try and let you know. I just tried the current version
of the script (the one that IE Mac has a problem with) on a PC and it
works great. So it seems to just be IE Mac. So I'll try the new thing
and let you know.
Thanks,
Mark
On Aug 25, 2004, at 5:47 AM, Andrew Mace wrote:
IE just displays the graphic but doesn't download it. The script
does not seem to be overriding whatever the settings are in IE
regarding MIME types and what to do with them -- I'm guessing. Is
there a way to override that?
You could try changing the Content-Type to application/download. The
problem is Mac IE will show the save as prompt, but it will be the
name of your script (download.pl) and not the filename you specified
in the HTTP header. I haven't found any workaround for this. When
I've done things like this in the past I've ended up using Apache conf
settings like Chris' suggestion, though I'm realizing as I'm writing
this that using $ENV{PATH_INFO} instead of the query string might
solve that problem - take a look at the other Andy's suggestion for
how to use that:
a
href=javascript:window.location='cgi-bin/download.cgi/Upload-
Background.gif'picture link/a
my $filename = $ENV{'PATH_INFO'};
Good luck
Andy
On Aug 24, 2004, at 6:17 PM, Andrew Mace wrote:
$path is a system path, right? As in, like, not relative to the
webserver? Just making sure...
Also, I messed up and used $length in one place and $size in another,
though that doesn't explain your troubles.
I mean, you could do a lot of things to debug. A quick thing you
could do would be to change the content type to image/jpeg and remove
the Content-Disposition and see what gets put into your browser.
Since you're writing the HTTP headers before attempting to open the
file, my suspicion is that there's something wrong with the path to
the file and your script is exiting prematurely.
Andy
On Aug 24, 2004, at 8:23 PM, Mark Wheeler wrote:
Hi Andy,
Thanks for the input. I should have check the read/write method --
my bad.
I tried both the slurp and the read methods, but the same thing
still happens. On a PC the save dialog comes up but the file saved
is 0k, and on a Mac, the the progress bar is just a spinning barber
poll. Any ideas?
Thanks,
Mark
On Aug 24, 2004, at 3:56 PM, Andrew Mace wrote:
Hey Mark -
A few things.
- You want to open the file for reading, not to write.
- You should undef $/ to slurp the file if you're using to read.
- You should stat the file before opening it to add the
Content-Length header, if you want.
- For larger files, it would make more sense to use read() calls
instead of slurping the entire file into memory.
So here's an updated version:
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
my $filename = param('picname');
my $path = /images/$filename;
my $length = (stat($path))[7]; # the size, in bytes
binmode STDOUT;
print Content-Length: $size\n;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
open (FILE, $path) || die(Can't open($filename): $!);
binmode(FILE);
# slurp method:
undef $/;
my $data = FILE;
close (FILE);
print $data;
# read() method would be:
while(read(FILE,$data,4096)) {
print $data;
}
close(FILE);
exit;
Good luck
Andy
On Aug 24, 2004, at 6:19 PM, Mark Wheeler wrote:
Hi all,
Here is my first attempt to write this script. I will be adding
the protection/whitelisting/etc. after I get the basic this
running. Here is what I have so far, and here is what happens. On
a PC, the dialog box comes up and saves the file, but it is 0K --
nothing in it. On a Mac, the Downloads dialog box comes up, but
the progress bar keeps spinning and nothing happens. Below is the
HTML that calls the script and the CGI script itself. What did I
forget/do wrong?
Thanks,
Mark
-
html
head
titleUntitled Page/title
/head
body
a
href=javascript:window.location='cgi-bin/download.cgi?
picname=Upload-Background.gif'picture link/a
/body
/html
-
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
my $filename = param('picname');
my $path = /images/$filename;
binmode STDOUT;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
open (FILE, $path) || die(Can't open($filename): $!);
my $data = FILE;
close (FILE);
print $data;
exit;
-
On Aug 23, 2004, at 2:45 PM, Joel Rees wrote:
I think that's what I'm looking for. One question. What do you
mean whitelist the filepaths. My only reference point is
email. Whitelist for me means that email address on my
whitelist always get through, even though the spam software
might initially think it's spam. Can you clarify?
If the script I posted was readable, you might have noticed that
it accepts one parameter
Re: Download images/movies
On Aug 25, 2004, at 10:59 AM, Mark Wheeler wrote:
Hi Joel,
Thanks for your input. In regards to filename, I'm assuming you are
talking about the filename passed within the HTML, right? I think what
I will probably do is pass an ID number to the script and then process
it that way. I will still check for ../ andywhere the passed ID, as
well as / at the beginning of the ID. You mentioned that V is /.
Im afraid you lost me there. Can you explain?
I'm curious, I've seen the ../ thing mentioned many times over the
years but I've never successfully created a script that would open a
file that way. I use a Clean Name sub-routine (that I got from
Lincoln's CGI book) just to be safe on files I want to process or
return to a client;
sub clean_name {
unless ($selected_file =~/^[\w\._\-]+$/) {
print STRONG$selected_file has naughty characters. Only ;
print alphanumerics are allowed. You can't use absolute
names./STRONG;
die Attempt to use naughty characters;
}
return $selected_file;
}
Still, I've tried scripts without it and they will never open a file
name input from a form like:
http://site.com/server.cgi?file=../../../../../../../etc/passwd
Maybe it's because I usually append the $file to a $path or never input
the right combo of ../ (path info) but I've never seen it work. Can
someone actually show me a cgi script example that does this? It seems
to me that the file permissions for etc/passwd should prevent this
from working in the first place.
Kindest Regards,
Bill Stephenson
Re: Download images/movies
On Aug 25, 2004, at 10:59 AM, Mark Wheeler wrote:
Hi Joel,
Thanks for your input. In regards to filename, I'm assuming you are
talking about the filename passed within the HTML, right? I think what
I will probably do is pass an ID number to the script and then process
it that way. I will still check for ../ andywhere the passed ID, as
well as / at the beginning of the ID. You mentioned that V is /.
Im afraid you lost me there. Can you explain?
I'm curious, I've seen the ../ thing mentioned many times over the
years but I've never successfully created a script that would open a
file that way. I use a Clean Name sub-routine (that I got from
Lincoln's CGI book) just to be safe on files I want to process or
return to a client;
sub clean_name {
unless ($selected_file =~/^[\w\._\-]+$/) {
print STRONG$selected_file has naughty characters. Only ;
print alphanumerics are allowed. You can't use absolute
names./STRONG;
die Attempt to use naughty characters;
}
return $selected_file;
}
Still, I've tried scripts without it and they will never open a file
name input from a form like:
http://site.com/server.cgi?file=../../../../../../../etc/passwd
Maybe it's because I usually append the $file to a $path or never input
the right combo of ../ (path info) but I've never seen it work. Can
someone actually show me a cgi script example that does this? It seems
to me that the file permissions for etc/passwd should prevent this
from working in the first place.
Kindest Regards,
Bill Stephenson
Kindest Regards,
Bill Stephenson
417-546-5593
Re: [OT] Brand New Empty Mac
--- John Horner [EMAIL PROTECTED] wrote: But I just thought I'd get the opinions of the list on the best way to set up such a brand-new machine -- do you partition your hard-drives? Do you have the system on one partition and documents on another and so on? Any issues around the installation of Perl and other things like C libraries that I should be thinking about? Generally speaking I haven't had need to install any libraries (or other *nix goodies) other than those from the developer tools. I needed libraries for OpenOffice and TeXShop, and occasionally for specific Perl modules (expat, libxml2). Other *nix stuff I've done include lynx/links/elinks (for webdesign testing) and CVS. I'd say, do the stuff for OOo and TeXShop if you're into that, otherwise just install them as you need them. I'm all for partitioning. I haven't had the issues that a bunch of others apparently have (I am still on Jaguar though). My current partitions are something like System (4GB), Volatile (8GB), and Static (25GB). System holds most boot and / stuff along with developer tools; Volatile holds most of my documents, /Users, and /Applications* (and perl's site_lib incidentally); and Static holds my media that change rather infrequently (MP3s, movies, developer tools documentation, some images). The upsides to this arrangement are: if I toast my system I can just wipe the partition and reinstall the OS without needing to reinstall all my applications (*nix programs will need reinstall, but they're smaller, by and large; and OOo will need reinstalling) and without damaging preferences, user files, etc. On a production rather than development box this would be less important. Also if I want to search for something I can pretty reliably limit where I'm looking to about 8GB out of 40. And it helps keep things looking clean since I have a bunch of files that are shared and /Users/shared has other purposes according to various installers. (Though I suppose you could just dump them all in a folder on your single partition.) The downsides are that you need to watch your free space when considering partition size: make sure you have enough swap space on System (so on Panther that'd be 3~10GB after all the OS, C libraries, *nix programs, Xtools), and make sure you have enough free space on Volatile for any large downloads and for the iTunes preferences/library (iTunes gets quite persnickety if you run out of space, and can start harming the system too). And you need to bear in mind the limitations of moving /Applications off the boot partition. * Moving /Applications is considered by most to be a _bad_ idea. Since I have about 5GB of Aqua/OSX applications the ability to avoid reinstalling them is worth it to me. There are a few different methods of doing so, I chose the one resembling moving /Users-- namely just put it where you want and make a symlink (for /Users you'd also have to go in and mess with NetInfo)-- because it seemed to have the fewest/least severe issues involved with it. The biggest problem I've noticed with this method is that Software Update doesn't always respect the symlink and will occasionally overwrite it with a folder of the same name and drop whatever in there (not always a whole .app bundle either; e.g. Safari 1.0.1 to 1.0.2), or sometimes just won't work at all (e.g. the iTunes 4.4 to 4.5 update appears to have gone to /dev/null every time until I made the /Applications folder and moved iTunes into it). This has been annoying but since I knew about it getting into things it hasn't surprised or bothered me too much; again, it doesn't happen reliably, just often enough to bear in mind. The only other downside I've noticed is that Disk First Aid can't properly scan the disk it's running on. If you were to follow this method, I'd suggest installing that first huge batch of Software Update stuff before moving /Applications over, just to avoid any possible problems since there're so many updates on a brand new system. FWIW, YMMV, etc, ~wren ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
@INC gone weird after repair
My iBook just came back from repair. The first thing I wanted to do was back up stuff that hadn't previously been. So I call psync into action and get the following: [solidgoldpig:~] alexr% sudo psync -r /Pictures/ /Volumes/192.168.0.40/SGPBACKUPS/Pictures/ Password: Can't locate MacOSX/File.pm in @INC (@INC contains: /usr/local/cb/perl5.8.4/lib/5.8.4/darwin-thread-multi-2level /usr/local/cb/perl5.8.4/lib/5.8.4 /usr/local/cb/perl5.8.4/lib/site_perl/5.8.4/darwin-thread-multi-2level /usr/local/cb/perl5.8.4/lib/site_perl/5.8.4 /usr/local/cb/perl5.8.4/lib/site_perl .) at /usr/local/bin/psync line 14. BEGIN failed--compilation aborted at /usr/local/bin/psync line 14. Which is somewhat surprising seeing that before the repair everything was fine using the stock 5.8.1 that came with my Panther installation. What is this /cb/perl5.8.4? Is it from the CamelBones bundle that I may have installed just before I had the hardware failure? Or is it something else entirely? That aside, how can I get my @INC back to the default so that all my installed modules will work again? Or rather so they'll work again after I've reinstalled them again since Apple has obviously reinstalled the OS and wiped /Library/Perl.
Re: @INC gone weird after repair
On Aug 25, 2004, at 5:44 PM, Alex Robinson wrote: What is this /cb/perl5.8.4? Is it from the CamelBones bundle that I may have installed just before I had the hardware failure? Or is it something else entirely? The Fat Camel bundle includes Perl 5.8.4, installed in /usr/local/cb/perl5.8.4/. That aside, how can I get my @INC back to the default so that all my installed modules will work again? Pick one: Delete /usr/bin/perl, which is currently a symlink to /usr/local/cb/perl5.8.4/bin/perl, and replace it with a symlink to /usr/bin/perl5.8.1. This will only affect scripts that use #! - CamelBones apps will continue to use the libperl that's installed under /usr/local/cb/. Add 'use lib qw(/Library/Perl/5.8.1 /Library/Perl/5.8.1/darwin-thread-multi-2level)' to your scripts. Install the missing MacOSX::File module under Perl 5.8.4. IMNSHO, the third listed option is best. Now that you've installed a newer Perl, there's little reason not to use it to run your scripts. And, forcing a Perl to use modules that were installed under an older Perl version is chancy - we're talking about minor revisions of 5.8.x, so it's very likely to work, but why take chances? sherm--
Re: Download images/movies
Thanks for your input. In regards to filename, I'm assuming you are
talking about the filename passed within the HTML, right?
If I know what you meant be that, I'd be more able to say.
So I'll dodge and try explaining it this way: Any script that could
potentially be called by someone typing it's URL into their web browser
is subject to getting input you don't want. If you accept file names
directly in such scripts, there are several bad things that can happen:
An attacker can gain information you may not want him or her to get
about the structure of things in your site (ergo, by checking the
status bar). Worse, an attacker could pass a complex path giving access
to files you don't want him or her to be able to access. Another bad
thing is that an attacker could pass a huge string that contains lots
of escape characters to hide the complex path. (I regularly see zombies
posting 32k parameter strings to my home server.) If I tried to put one
of those strings into a limited space buffer (usually more of a problem
in C than in perl), it could blow up my program or allow a buffer
overrun attack.
I think what I will probably do is pass an ID number to the script and
then process it that way.
If the file name contains the ID number or name string, you'll still
need to clean the http parameters.
If you have a hash (not an array) that you use the ID to index into and
get the real file name, that is one good way to clean the parameter. An
if-ifels condition that compares the IDs to a (small) set of valid IDs
could be another way.
But whatever you use to map the IDs to file names, you'll want to check
for weirdness like escape characters and long strings, just to avoid
stressing your machine.
I will still check for ../ andywhere the passed ID, as well as /
at the beginning of the ID. You mentioned that V is /. Im afraid
you lost me there. Can you explain?
The backslash is an escape character and can be used to hide things.
For instance, ../ will go up one level in the directory, but so will
\.\.\/.
Have fun. I gotta go to work.
Thanks,
Mark
On Aug 25, 2004, at 8:16 AM, Joel Rees wrote:
Just a few nosy comments --
html
head
titleUntitled Page/title
/head
body
a
href=javascript:window.location='cgi-bin/
download.cgi?picname=Upload-Background.gif'picture link/a
Not sure why you want to bother with javascript in there. ICBW, but I
don't think it buys you anything. And some of your family may decide
to turn javascript in their browsers off.
/body
/html
-
#!/usr/bin/perl -w
use strict;
use CGI ':standard';
I didn't notice that you had used anything from CGI in the script.
Might as well comment it out.
my $filename = param('picname');
Did you follow what was said about ../../ someodd with /etc at the
end?
It's a good way to dump all sorts of things about your machine into
someone else's browser, including user names and ids, the entire
httpd.conf file, and so forth.
That's why I don't usually accept filenames in scripts. But if you
do, you need to check for / at the top or ../ anywhere, and balk if
you get those. It can get kind of tricky, since \/ is /.
my $path = /images/$filename;
For instance, somebody puts this in their browser:
http://your.domain.com/cgi-bin/download.cgi?picname=../etc/httpd/
httpd.conf
binmode STDOUT;
print Content-Disposition: attachment;filename=$filename\n;
print Content-Type: application/octet-stream\n\n;
If you _had_ been using CGI, the above two lines could have created
some subtle conflicts.
open (FILE, $path) || die(Can't open($filename): $!);
This is why you got the attempted download that stalled, of course.
That die statement won't do much useful. Well, if it were going out
STDOUT, it might have shown up as your downloaded file.
You'll want to look into using a logging file or the http version of
carp.
my $data = FILE;
close (FILE);
print $data;
exit;
--
Joel Rees
Nothing to say today
so I'll say nothing:
Nothing.
