Slashdot Mirror
Security for a Small Stock Photo Company
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."
assuming you're using apache, .htaccess should do the trick
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.
Watch the Teaser Trailer for "The Lightning Thief" Her
you can do this with OS Commerce open source online shopping cart.
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.
Build Your Own PVR/HTPC news, reviews, &
Are you looking for an off the shelf solution for this?
.NET, what have you).
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).
- 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: /webroot/private/CONTENT.zip /wehroot/orders/RANDOM_FILENAME.zip
ln -s
In the receipt:i p">Click 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.
Accept Eris as your Fnord and personally sate her
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.sit The buyer, Ms. or Mr. Jones would then download using any browser. Usually the next day I'll pull the file.
The issue that I'm now having is that I spend quite a bit of time in the field and can't quickly or easily pull the file, compress it, upload it, test it, and then notify the buyer that it's now ready. Last month I had three sales that took place while I was out of town and I had to work from a wifi spot as well as my hotel room to close the sales.
I'm not looking for a turnkey ecommerce set up since I'm always paid by check adn I really don't want to get involved with a merchant credit card system or PayPal.
Right now it's a pretty secure system because of the unique file name scheme that I'm using that is specific to the buyer. Not to mention the fact that the files are removed pretty quickly. This won't work for 400 files that require a consistent naming scheme.
Another option is that the stuffed or zipped file can be password protected upon creation. I'm concerned that individual passwords might be too hard to remotely manage (remember) but a global password might be too insecure.
Other things about my set-up:
-I'm a Mac operation and have no Linux experience.
-I have 10 GB storage from my web host.
.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.
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 stock site.
Do you know how to use any kind of scripting language? Even a shell script would make this much easier.
.htaccess-style password protection for your zipped files, with a different username-password for each file. You don't have to remember them -- just print out a reference copy and check the chart when you make a sale, or use a formula that you can calculate based on the filename. This would work pretty well. You could mix in the idea above -- and change the passwords automatically, daily. This would make your chart more complicated... but still chartable.
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 on the date and the filename, and the script would decode it.
Next level down -- you could write a script that ran every night at 2am, and changed your directory names based on the current date (using a formula which you could duplicate on a calculator, to pass out valid one-day links to clients). (This script would be pretty easy -- if you don't know anyone who'd do this for you as a favor, your web host might help).
OR -- you could actually set up
These are all "security through obscurity" methods -- but honestly as long as you put it together thoughtfully and you don't have a huge risk to worry about, that's okay.
At the very least, I'd advise you to learn the basics of Linux/UNIX command line navigation -- if you have all of your zipped files already on the server in a directory OUTSIDE of your web directory, it's quite trivial and very quick to use telnet to copy one zipped file from your archives to "jones.sit" in your web directory, then delete that later; e.g.,
[ssh to your host]
cp archives/people/jumpingman.sit webroot/jones.sit
then the next day:
rm webroot/jones.sit
Other nice commands to know: ls, cd, and cwd (show directory listing, change directory, and show current working directory).
From what you said, you can probably fit all of your zipped images on the server, right?
A half-brain-dead code monkey could do this.
The World Wide Web is dying. Soon, we shall have only the Internet.
There is a solution provided by http://www.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, and build a system where you have the files ready to go.
because most code-monkeys ARE half brain-dead.
I want to delete my account but Slashdot doesn't allow it.
Try lighty its one of the features it has that apache doesn't... its not the only needed feature by many sites that apache is missing there are about a gazallian more... I don't know why it doesn't have apache market share as so many things about it makes it better from lower memory footprint to being able to handle a slashdotting VERY VERY well.
.htaccess support... well read why thats a good thing and it has something better than .htaccess support to replace it
Its under the revised BSD license so its license is better than Apache's.
And before you say it doesn't have
Oh yea most of the biggest torrent trackers are using lighty.
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?
Sig Hansen?
I too am a photographer. Here's my website.
.htaccess. Means the client will need a user/password to access the files. No big deal.
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 user/password combination and the URL for them to retrieve the image.
Common, Off The Shelf Solution...
I would look into a digital asset management solution designed for this task.
Oloto or Cumulus 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.
Specialist Mac support for creative pros, Melbourne
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? If not maybe you can get more help there. Besides /. Photo.net is one of my fav sites.
FalconShould there be a Law?
I'm not posting to any one solution because they all mention this.
.zip so they don't spot that the link is different. Most people will re-test the link before passing it on.
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 unique identifier to it. That way, they can pass the link on to their friends, and you know they're sharing it. Feel free to make it expire - that will prevent said others from actually getting the content - but by leaving that link functional you can actually track who is trying to pass the content around. Make it so after the expiry period, it instead sends a zipfile that has a text file that says "please contact FOO to regain access to these files, they have expired" - that way the link will still "look good". Chances are they won't need to download it but once anyway, but you can always re-enable it for them if they really need it / etc. Heck, make the filename it sends slightly different so they don't accidentally overwrite their old copy - but you want to leave it a
If you make it a login based system, then you're less likely to catch it right off - just make it a simple link they can forward in email. This is all super-paranoid and about catching would-be thieves, hopefully the real world isn't this bad - but that's not my experience.
Protecting these at the distribution level is tricky enough, and it will take time looking over things, but it will at least limit your losses.
cyn, free software and *nix operating systems enthusiast.