Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Graphics Security Software The Internet

Security for a Small Stock Photo Company 43

Posted by Cliff from the reliable-online-photo-delivery dept.
ExTex asks: "I am a commercial photographer, and I also run a very small stock photography company. Most of the sales that I make are to existing clients or from referrals. Currently, when I make a sale I upload a ZIP file of the image and create a unique web page for the customer to download. I pull the page shortly after the client has confirmed receipt. This is easy, when I'm in the office, but can be a challenge if I'm out in the field on a shoot. At some point I'd like to be able to have 400 of my best images already pre-zipped and loaded to my web host for quick download. I'm wondering how best to secure the images to prevent unauthorized download but also make it relatively easy for the typical un-savvy client."
This discussion has been archived. No new comments can be posted.

Security for a Small Stock Photo Company More

Security for a Small Stock Photo Company

Comments Filter:

  • .htaccess? (Score:2, Informative)

    by Anonymous Coward
    assuming you're using apache, .htaccess should do the trick
    • Or keep them out of the document root. Create a script that will allow you to select images, zip them up, and move them to a temporary directory within document root (and additionally create a .htaccess and .htpasswd file to protect the directory). Give the client the url and login, and have a cron script clean up the temporary files every day or two, or do it manually.

  • Porn site? (Score:2, Insightful)

    by gambit3 ( 463693 )
    Not to trivialize or suggest that the poster is a actually planning to run a porn site.. but doesn't this sound very much like just running a basic adult site? i.e., You already have the pics uploaded, and you just need a mechanism to provide access to specific areas. i.e., Porn site.

    • Re:Porn site? (Score:4, Informative)

      by gambit3 ( 463693 ) on Wednesday October 05, 2005 @09:19PM (#13726667) Homepage Journal
      Whoa.. thanks for the quick flamebait...

      why even bother reading the post? "I am mod, hear me roar!!"

      Read the original post:
      "At some point I'd like to be able to have 400 of my best images already pre-zipped and loaded to my web host for quick download. I'm wondering how best to secure the images to prevent unauthorized download but also make it relatively easy for the typical un-savvy client."

      Isn't that just calling for an adult-website-type solution? That's exactly what adult websites do: they have their posting of their product, be it pictures or videos, and when you buy access to those, you get provided with a username and password, which usually lasts only a few days. Isn't that what the OP is asking for?

      But, for the idiots who have their scripts set to mod "Flamebait" if it reads the word "porn" (pornpornpornpornpornpornpornporn!!!!), here's some simple javascript solutions (if you want more security, I would suggest .htaccess):

      http://javascript.internet.com/passwords/gatekeepe r.html [internet.com]
      http://www.javascript-page.com/passwords/ [javascript-page.com]
      • Do people really write scripts to parse slashdot?

        I thought reading this site was a pointless waste of time... writing scripts to customize what you see is a disturbingly excessive waste of time!
    • Unlike an adult site, the sale of stock photography is generally done one photograph at a time. The customer will purchase specific reproduction rights for a single shot. I don't want to offer access to more than one image at a time. Buyers chose a photo to purchase from my main portfolio site or from a printed portfolio of my work. Once they have committed to the purchase the buyer is directed to the site that holds only images for download. They won't even be able to view or preview the shot from the
      • I'd think you could write up a simple php script that'll use passthru() to send the contents of the file through. You'd have to send a header with the file type first and to specificy download. That way you can auth the user against your purchased database, and only if they've purchased it can they download that image. I'm sure there's software out there that does this already and is integrated into a storefront - A poster further down the thread mentioned OSCommerce, so check that out. It shouldn't be too
      • I think you're looking at the problem from the wrong direction. Rather then simply looking for a better way of delivering the content, I'd suggest looking at a better way of selling the images. I don't know how you currently market your images, but if you had a shopping cart system to actually sell the images online, you would probably increase your sales.

        I'd strongly recommend that you look at the various off-the-shelf shopping cart systems out there. I'm willing to bet that at least one of them gracefully
      • Since you want to do it one pic at a time, it should be relatively easy.

        Store image names, prices, and file locations (someplace not served up by your webserver, but accessable by the user your webserver runs as) in a database. Present the user with a "browse" page of thumbnails, each one linked to a "buy" script with the image identifier as a arg. On the buy script page, collect CC info, process it, and either serive the image up and force download/save (if CC can get OK "instantly") or email a unique UR

      • They won't even be able to view or preview the shot from the stock site.

        Why not? What you can do is have reduced quality photos with a watermark online so potential buyuers can see them then once an order is confirmed you can either upload it to a password protected directory, email it to them, or perhaps snailmail/Fedex developed photos and/or cd. Without a preview how will people even know what the photos are, having them on a website can be your porfolio.

        Also have you checked out Photo.net [photo.net]? If no

    • Not to trivialize or suggest that the poster is a actually planning to run a porn site.. but doesn't this sound very much like just running a basic adult site? i.e., You already have the pics uploaded, and you just need a mechanism to provide access to specific areas. i.e., Porn site.

      I hope this is an attempt to be funny. In case it's not, stock photo agencies typically sale individual photos, one two, or more at a tyme. These photos are used for ads, news, and pr amoung other things. And that's what

  • OS commerce shopping cart (Score:4, Informative)

    by enrico_suave ( 179651 ) on Wednesday October 05, 2005 @08:58PM (#13726543) Homepage
    you can do this with OS Commerce open source online shopping cart [oscommerce.com].

    You can create protected digital download store "items" and determine how many times they are able to download a give stock photo or whether it expires after a given amount of time.

    Add credit card processing and you have a reasonably fully automated system.

    e.
    • Except OsCommerce really sucks balls.
      • Well that's certainly constructive.... well creating a script to copy stuff back and forth [slashdot.org] from below the document root and back sucks balls too. Neeener neener!
        • maybe, maybe not. but oscommerce really does suck. Unfortunately, through references i've become the "Go To" man for any and all OsCommerce projects for way too many clients, for hacks, fixes, modifications and shit like that. I don't like this, I don't want it, and i'm sorry I know the code so well. Yeah, the scripts may work, but the code is such a jumbled cluster fuck that you can't tell heads from tails. To add to the enjoyment, nearly all of the code is duplicated in the /admin/ folder so you get
          • I agree. It's a complete mess. I use it to run a 4000 item store. I do almost all the administration via perl scripts and completely new (from scratch) php scripts (using PEAR::DB, not their horrible sql classes). It wasn't worth my time to try to fix the major deficiencies in the existing admin tools.

  • Looking for an off the shelf solution? (Score:5, Interesting)

    by ip_vjl ( 410654 ) on Wednesday October 05, 2005 @09:01PM (#13726556) Homepage
    Are you looking for an off the shelf solution for this?

    Because this kind of thing would be pretty easy with any scripting language (PHP, Perl, ColdFusion, .NET, what have you).

    Just issue a 'ticket' (token in URL) to the client when they purchase. That token can be stored on the site to allow access for a certain amount of time. You could also throttle it so that too many attempts on the same ticket trigger a lockout until you've had a chance to review it.

    Otherwise, send them the URL (with the token) and give them 24 (or whatever) hours to download the file. (If they try to download more than X times before the ticket expires - lock it out until you've made sure it isn't that they've given the ticket out to 10,000 of their friends).

    • Right now the sales volume is pretty low. Maybe five transactions per month. I'll get an order and upload the file to a site that is separate from my main photography portfolio site. The compressed .sit or .zip file generally weighs in at about 20 MB and can be uploaded via my consumer grade DSL connection via Mac FTP (Fetch) within about 8 to 10 minutes. Once it has been uploaded, I test the link from a browser and e-mail the buyer a link that would look something like this: www.mystocksite.com/Jones.

      • There is simple technology to begin your process by having you just put the file in a directory. It would:

        - Be informed when the file was dropped, and upon such event, compress w/pw, rename, and copy to newly-created customer-specific (web facing) dir. Then archive to another machine/dir

        - Passwords, like the dir names, should be something reflective of the customer, but not difficult to remember nor easy to discern. Perhaps their last name and last x digits of their [phone/zip cod
      • Do you know how to use any kind of scripting language? Even a shell script would make this much easier.

        Personally I'd probably store the files pre-zipped in a non-web accessible directory, then write a simple gateway application that limited access, and would feed the file to the client if they qualified for it. This could be backed with a database with actual client info (which you'd need to update when they made a purchase), or it could be as simple as a "passphrase" that you'd give them that is based o

      • Re:Reply from Original Poster re: off the shelf (Score:5, Informative)

        by ip_vjl ( 410654 ) on Wednesday October 05, 2005 @11:25PM (#13727223) Homepage
        I'll outline the shell of it here, but you'll have to do the legwork to complete it (or hire someone who can) as it it too detailed to put in a post here.

        Since PHP is pretty ubiquitous on webhosts, I'll assume PHP for the scripting.

        You could do this with or without a database. I'll outline a path for doing it WITHOUT a db.

        1) Make sure all your files have some sort of ID number for the filename (makes life easier).

        2) Store *all* your files in a non-web accessible directory
        ex. if your webroot is /username/public_html/
        store your pics in /username/photos/

        this way, they can't be downloaded directly from the browser.

        If you can't create a directory above your webroot, then make it inside your webroot, but protect it with .htaccess

        3) When a customer makes a purchase, you'll have an admin page that lets you create a 'download ticket' - when you load this page, you supply an email address and an image ID number (see #1) and it generates a 'ticket' that they can use to download the picture. (see 3a-b for details)

        3a) Since this isn't Fort Knox, security doesn't need to be super tight, just enough to prevent casual sharing.
        I would suggest a ticket be in a format like this.
        0000-12345abc-12345678

        where '0000' represents the image ID number
        12345abc is the 'expiration date' encoded into base 16 (to be shorter)
        12345678 - is every 4th digit of the MD5 (to keep it shorter) of the image number / date / and some secret string (that only is known to your web server)

        3b) The admin page sends an email to the client using the email you provided.
        "You can download your image at:
        http://www.example.com/get.php?t=0000-12345abc-123 45678 [example.com]

        This link will be functional until xxx-xx-xxxx blah blah blah"

        4) You have a page 'get.php' that looks at the $_REQUEST['t'] value and does a comparison.

        4a) Split the ticket into its parts ('0000' , '12345abc', '12345678')
        4b) Calculate the MD5 of part 1 + part 2 + 'secret string'
        4c) Get every 4th char, does it equal part 3? If not, DO NOT DOWNLOAD THE FILE, if so, continue
        4d) Check the date, has it expired? If so, DO NOT DOWNLOAD THE FILE, if not DOWNLOAD THE FILE (see fpassthru() in PHP)

        --

        Notes:

        With a database, you can record number of attempts per ticket to make sure someone isn't trying to brute force access by doing an incremental attack on the checksum (part 3) as there are only 4,294,967,296 possible combinations (16^8).

        You could also add some sort of logging so that you can see who has attempted to download the file, etc.

        You'd also want to make sure you're properly sanitizing the input as (at some point) you'll be translating the input value to a file path, so you need to make sure there are no potential attack vectors for walking the file system (which shouldn't happen if you check your MD5 first, but it would still be possible, especially since you're only using 1/4 of the check digits).

        You want to keep the URL as short as possible for downloading so that the ticket doesn't word-wrap in their email. If it breaks, it may not be clickable any more. You'll probably also want instructions so that they can enter the ticket manually on the page, if the link in their email breaks.

        Arguably, if someone figured out your secret phrase (the one you use in MD5 generation) they could generate tickets to download any of your files, but the only way they should be able to do that is if they have access to your box - which if they have access to your box they already have access to your files.

        --
        • This is all great info. One thing I'd do a bit different, though. If you add a username/password system, you can simplify the entire delivery system. Instead of emailing a link to the image, your confirmation would link to your login page where your buyer can download any images they have purchased. This is a minor improvement, but it will make the user experience better, particularly if they buy multiple images. This is also a necessary step towards making an actual shopping cart system. Keep in mind that
        • Now just go to rentacoder and pay some Indian firm about $50 to implement it for you.
      • At 20M you could probably just email it to them.
        • As what, 20 different email messages?

          Many ISP's have limits of 1-2 Megabytes per message, and a message encoded for sending via email grows by 33% (giver or take).

          Someone here already mentioned the best solution: a program which checks the credentials when the user attempts to download an image. The image is only supplied when the credentials match. The easiest way to implement it is with a fully functional store front, but you could make it simpler than that. (And, if this guy doesn't want credit card proc

  • Use an order-specific symlink (Score:5, Insightful)

    by akh ( 240886 ) <slashdot@alephnull . n et> on Wednesday October 05, 2005 @09:15PM (#13726642)
    Unix-specific solution:
    • Place the zipfiles into a directory readable by the webserver but not accessable over HTTP. Call it something like /webroot/private
    • Create a second directory, writable by your shopping cart script and HTTP-accessable. Call it something like /webroot/orders
    • When a customer places and order, have the script create a symbolic link from the private directory to an order-specific filename in the public directory (an MD5 sum of e.g. the time + process id might make an appropriate filename)
    • Provide a link to the symlinked file in the customer's receipt
    For example:

    In the script:
    ln -s /webroot/private/CONTENT.zip /wehroot/orders/RANDOM_FILENAME.zip

    In the receipt:
    <a href="http://example.com/orders/RANDOM_FILENAME.zi p">Click [example.com] here to download</a>

    (Thank you slashcode for clobbering that code - get rid of the space in 'zip' and the '[example.com]' string, above)

    This isn't foolproof since customers can still pass the URL on to others. If they do though, you'll know who did it based on the order-specific filename.

  • .Zip or .Rar supports passworded files, correct?

    Just have all of the files up on the site, and when a customer purchases one file, give them the password for it.
    • While noting that .zip security may be fairly easy to violate, if you create random names, unbrowsable directories (so the client needs to know the name of the file to download it) and password protected files, then it is easy to send ftp links with passwords for each purchase and be guaranteed fair security. As such, this is probably "good enough" for what is needed, and 100% security need not apply, if there is such a thing.
      • Not since the new winzips. Previous versions were easy to crack because they stored the password in each file. All you had to do was look for matching code in each file and you had the pass. The new one is much better. If you use a long enough password you can make it pretty secure. These are pictures anyway, not government secrets.
  • Stuff image in non-web-accessible directory. Write or find script to serve the image over HTTP from said directory based on parameters in HTTP POST, GET, cookies and/or sessions of some sort. Have script check user's authorization and such credentials, and proceed only if they are valid. Stuff script in script-able directory.

    A half-brain-dead code monkey could do this.

  • There is a solution provided by http://www.proofpod.com/ [proofpod.com] that might fit your needs. I know that you can use the tool to make images available to your client via authentication for reviewing and purchasing.
  • If you have a ISP that allows perl-cgi:s you could easily install OTP [freshmeat.net], and build a system where you have the files ready to go.
  • Why do you need to use a Web site, anyway? Why not carry your files around in a Flash device, and upload directly to the client?
  • booga woooga bzzzzbzzz dooodododododo do you make the kids laugh? Ever see the episode of the Little Rascals when Spanky "has to get his pitchur took" or living in oblivion?
  • I too am a photographer. Here's my website [jeffpflueger.com].

    I know well the problem that you are talking about.

    I use .htaccess. Means the client will need a user/password to access the files. No big deal.

    Just a week ago I was working on a Perl script to write the htaccess files automatically so that I could use the Perl based GUI web interface I wrote to upload images for clients to preview/etc. The idea is to upload the images and define a user/password for the clients via the web. Then just give the client the us
  • Common, Off The Shelf Solution...

    I would look into a digital asset management solution designed for this task.

    Oloto [oloto.com] or Cumulus [canto.com] will do exactly what you want - plus offer you plenty of room for growth.

    When you look at the time and effort involved in rolling something like this yourself, you can save a lot of money by purchasing a pre-rolled solution, plus you then don't need to maintain (or hire people to maintain) it all yourself.
  • I'm not posting to any one solution because they all mention this.

    If the purchaser is going to share the images with someone else, they're going to. Make it too obviously difficult to do it through the site, and they'll just do it offline. This all depends on how much you trust people and how far you want to go to keep on top of things...

    If you want to be smart, and keep on top of things, then you don't want to make it *too* obvious that the link won't continue to work - but you definitely want to tie a u

Slashdot Top Deals

Without life, Biology itself would be impossible.

Close