Security for a Small Stock Photo Company 43
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."
.htaccess? (Score:2, Informative)
Re:.htaccess? (Score:1)
Porn site? (Score:2, Insightful)
Re:Porn site? (Score:4, Informative)
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
http://javascript.internet.com/passwords/gatekeep
http://www.javascript-page.com/passwords/ [javascript-page.com]
Re:Porn site? (Score:2)
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!
From Original Poster Re:Porn site? (Score:2, Informative)
Re:From Original Poster Re:Porn site? (Score:1)
Re:From Original Poster Re:Porn site? (Score:2)
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
Re:From Original Poster Re:Porn site? (Score:2)
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
selling stock photos online (Score:2)
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
Re:Porn site? (Score:2)
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)
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.
Re:OS commerce shopping cart (Score:1)
Re:OS commerce shopping cart (Score:1)
Re:OS commerce shopping cart (Score:1)
Re:OS commerce shopping cart (Score:1)
Looking for an off the shelf solution? (Score:5, Interesting)
Because this kind of thing would be pretty easy with any scripting language (PHP, Perl, ColdFusion,
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).
Reply from Original Poster re: off the shelf (Score:1)
Re:Reply from Original Poster re: off the shelf (Score:2)
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
Lots of options, but what do you know? (Score:2)
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)
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
store your pics in
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
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.
--
Re:Reply from Original Poster re: off the shelf (Score:2)
Re:Reply from Original Poster re: off the shelf (Score:2)
Re:Reply from Original Poster re: off the shelf (Score:1)
Re:Reply from Original Poster re: off the shelf (Score:2)
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)
In the script: /webroot/private/CONTENT.zip /wehroot/orders/RANDOM_FILENAME.zip
ln -s
In the receipt:i p">Click [example.com] here to download</a>
<a href="http://example.com/orders/RANDOM_FILENAME.z
(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.
this may seem over-trivial but... (Score:2)
Just have all of the files up on the site, and when a customer purchases one file, give them the password for it.
Re:this may seem over-trivial but... (Score:2)
Re:this may seem over-trivial but... (Score:2)
trivial (Score:2)
A half-brain-dead code monkey could do this.
Good thing (Score:1)
Re:trivial (Score:2)
Photo proofing - 3rd party solution (Score:1)
One time download (Score:1)
If you are uploading from out of the office (Score:2)
Say what? (Score:1)
.htaccess is perfect (Score:1)
I know well the problem that you are talking about.
I use
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
COTS (Score:2)
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.
paranoid enough? (Score:2)
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