SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 61
  1. #1
    ********* Articles ArticleBot's Avatar
    Join Date
    Apr 2001
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Discussion thread for Build a File Download Script in Perl

    This is a dedicated thread for discussing the SitePoint article 'Build a File Download Script in Perl'

  2. #2
    Anonymous
    SitePoint Community Guest
    you forgot to include a screenshot of the finished work.
    what exactly would it look like in a browser? What would the form look like? and what prevent impolite people from "hot linking" this time around?

  3. #3
    SitePoint Member
    Join Date
    Jun 2003
    Location
    Cleveland
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You're right--sorry, no screen shot. However, you can see the script in action at freewebgrafix.com. What prevents the public from hotlinking is that the folder with the images is outside of ther servers document root--only the script can reach the files.

  4. #4
    Anonymous
    SitePoint Community Guest
    Did you forget to put in a check on the HTTP_REFERER? I don't see how this script stops people from hot linking to your script with the appropriate fileid

  5. #5
    SitePoint Enthusiast
    Join Date
    May 2002
    Posts
    75
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yup I absolutely agree with Anonymous. True. You hide the images folder from the public, but I can always point to your script with the appropriate parameters, and your script is still going to return me an image.

    Anonymous is right. You got to check $ENV{HTTP_REFERER} before advancing.

  6. #6
    Anonymous
    SitePoint Community Guest
    Yes, you are right. But, my problem was that other web sites were displaying images on their pages using a direct link. I was able to overcome that problem with this script.

    True, you can still call the script from another web site and get the file. But, rather than displaying the file in the browser window, users would still be presented with a "save as..." dialog box.

  7. #7
    Anonymous
    SitePoint Community Guest
    What's to stop me using a ".." dir path and downloading your passwords file? At the very least you should run the $ID through a regular expresion to ensure the user isn't trying to get at stuff they shouldn't be.

  8. #8
    Anonymous
    SitePoint Community Guest
    The passwords file and the photos are all outside of the document root. My goal was not to keep people from getting the files as much as preventing them from hot linking to them.

  9. #9
    Anonymous
    SitePoint Community Guest
    Add to script something like this:
    (this is not ready for copy-paste)

    $ID =~ s/.*[/\](.*)/$1/;

    and

    if ($ENV{HTTP_REFERER} eq www.mysite.com/download.html) { ... }
    else die;

  10. #10
    Anonymous
    SitePoint Community Guest
    Hi, I just have on suggestion: rather than "slurping" the entire file into an array, you're better of reading and print 1K chunks. "Slurping" will put the entire contents of the file in memory -- you probably don't want that for large files. I tend to use this type of setup:

    open ( FILE, "<$file" );
    print $_ while ( read( FILE, $_, 1024 ) );
    close FILE;

    -Brian

  11. #11
    Anonymous
    SitePoint Community Guest
    Dosen't present you with a download box on a mac just opens the pic in the browser? most annoying!!!!

  12. #12
    Anonymous
    SitePoint Community Guest
    I tried this approach, and in my case it didn't work very well. Why? Because when you need to transfer large files the process might be killed by system timeouts (esp. if you are like me on virtual hosting).
    I found out another way to do that download... First, store the documents in a restricted folder (chmod 0700). Upon request, my Perl script creates a separate folder, copies the selected file from the restricted folder into the temporary folder, and then opens up a window with the location pointing to the temp folder.
    Ok, I use a simple database (MySQL) to do some extra house-cleaning: my users are granted a time-limited access to the documents, and beyond that point my script will simply empty and delete the outdated temp folders.
    As for viewing or downloading the file, my experience is that IE does not behave like you would expect when you send the "download" headers. It will just show the document instead. Annoying but beyond CGI control, I'm afraid.

  13. #13
    SitePoint Enthusiast icrf's Avatar
    Join Date
    Jun 2003
    Location
    Tennessee
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This script does something that continues to amaze me. I realize some people just don't use CGI.pm for reasons unknown, but even more baffling are those that use CGI.pm for form parsing, but still manually generate headers. Was there something wrong with 'print header()' that you thought 'print "Content-Type: text/html\n\n"' is better? You can do the same thing with the content-disposition header:
    Code:
    print header( -type       => 'application/x-download',
                  -attachment => $ID,
                );
    Since the site is trying to be educational, please, it would be beneficial to properly generate headers with the module you've already loaded and imported into your namespace rather than introduce errors to people who forget to capitalize the C in Content and get very confused.

    And it seems lots of modern browsers look at either the filename's extension or the given mime type, and if it's not familliar with one of them, looks to the other. If you send it an application/x-download header, but it also sees a .jpg in the filename, it checks and see that it already has a default behavior for .jpg files and runs with that instead of this odd header it doesn't know about. We'd be hoping for too much to be able to control the client's browser from afar.

    I've seen other "download" mime's before, is there some generally accepted one? I've seen application/forced-download and application/octet-stream before, too. Any reason to use one over the others?

  14. #14
    SitePoint Member
    Join Date
    Apr 2004
    Location
    Canada
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    I follow exactly the article and here is my URL : http://www.nttran.freesurf.fr/cgi-bin/test/test.htm
    However when I click on the download link, I got this "ࡱ" instead of having a Save as dialog box. Does anyone have any idea about this problem? Please any help would be appreciate, thanx. -Kelly

  15. #15
    Anonymous
    SitePoint Community Guest
    Good script!
    But it doesn't help when we want to download ranges (HTTP Range).

  16. #16
    Alfred Simpson
    SitePoint Community Guest
    Thank you very much.
    It worked great.
    Simple and easy to use.

    Regards.

  17. #17
    SitePoint Member
    Join Date
    Aug 2002
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i definately dislike these 3 lines of code

    @fileholder = <DLFILE>; # read everything into memory?
    .
    .
    print "Content-Type:application/x-download\n"; # force download of ALL file types?
    print "Content-Disposition:attachment;filename=$ID\n\n"; # same as above
    .

  18. #18
    wouter
    SitePoint Community Guest
    This script doesn't do any input validation. It's a big security risk. On top of that, you load the whole file in memory, while you could print it directly to the browser.

    I'm not even going to rate this, please improve it. There is already enough insecure code in use on the web.

  19. #19
    pikki
    SitePoint Community Guest
    2 things :

    - Major security risk
    - If you have large files to download, the webserver will be killed if you have a frequently visited website

  20. #20
    SitePoint Member Smurfs Are Tasty's Avatar
    Join Date
    Aug 2004
    Location
    Nashville
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    I Agree.

    I Agree.

  21. #21
    rizal
    SitePoint Community Guest
    ya...this is nice script i think..so i want try to use this script..congratulations coz make a nice script

  22. #22
    Stretch
    SitePoint Community Guest
    Getting an error when trying the script - "The server can't open the file: No such file or directory".
    would this be because I have the absolute path wrong or because my server does not support this?

  23. #23
    Keith Alexis
    SitePoint Community Guest
    This tutorial was an answer to prayer. Thanks a ton.

  24. #24
    waneeta
    SitePoint Community Guest
    my compliments to the chef

  25. #25
    Paul Wayper
    SitePoint Community Guest
    This is disappointing. While it fills the need, it doesn't do it neatly. You're loading the entire CGI module, and yet you're generating your headers using print statements! For portability and standards compliance, you really should be using the CGI module's header() and start_html() methods. These can do all the things that you want here, and neatly integrate into the full scheme of using Perl and CGI.

    Regards,

    Paul


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •