Where to modify download info?

I want to intercept an order for one of my downloadable products and
a) create a version of the file to be downloaded for the order that is encrypted
b) modify the email that is sent regarding the order to include the password that has just been assigned to the encrypted file
c) modify the download page to remove the temp file after a certain number of downloads, if possible

Can someone tell me what zen cart php files handle that piece of processing? I know what I want to call, but I don't know where I want to call if from.

Thank you!

khartley:

I want to intercept an order for one of my downloadable products and

Any form of 'interception' will require custom code.

khartley:

a) create a version of the file to be downloaded for the order that is encrypted

Mind if I ask why?
Are you planning to re-encrypt the file with a different seed for each customer? Why? What do you hope to achieve?

khartley:

b) modify the email that is sent regarding the order to include the password that has just been assigned to the encrypted file

Can be done, but again, you'll be needing to modify the code.

khartley:

c) modify the download page to remove the temp file after a certain number of downloads, if possible

Zencart already does this by default.

khartley:

Can someone tell me what zen cart php files handle that piece of processing? I know what I want to call, but I don't know where I want to call if from.

You'll be needing to modify several files to achieve what you are wanting to do, and as is generally the case, if you have to ask where and how then you probably don't have the skills to do it yourself anyway (no offense intended, it is just a simple fact).

I think I know why you are wanting to do this, but if so, then what you are asking for is a lot of work for very little or no benefit. You have no control whatsoever in regards to the downloaded file(s) after any given customer has decrypted it/them with the key that you supply, which makes 'unique' encryption for any given customer a bit pointless, and zencart itself is designed to prevent non-paying customers from downloading the files (and as mentioned, it will also remove the 'temp file' (AKA, the download link) after X number of days, or X number of downloads for the paying customers.

Just my 2cents worth.
Cheers
Rod

Well, the end goal in this is to do as much as we can to protect our products from theft... if a password is required to open the file, and it is unique for each order, at least there's some effort involved if someone wants to copy the materials (they'll have to give the password to others as well.) I've done this in the past with other pdf materials, and it's about the only way that I know of to at least somewhat protect our materials.

I know that I need to modify the code - that's why I'm asking WHICH php files are involved, so that I can speed up my modification process. (The last time I did this was with a site using VirtueMart, same idea but running under Joomla, so I've been through this before.)

I'm not a complete rookie, just a rookie as far as Zen Cart is concerned. I DO have the skills required to make the modifications. I just thought I'd ask to give myself a jump on the process - gotta start somewhere. So thanks for your help. Now, if we can skip the pontification and attitude, if someone can help me by just pointing me to which files are involved, I'll take it from there. If not, I'm sure I can figure it out.

There are a number of things to consider here.

First, if you've set up a downloadable product in Zen Cart, then you'll know that the file is assigned to the product in the order at the time the order is placed. And its download limits are assigned to that order based on the settings you've previously configured. Then at the end of order completion the customer has three ways to download their files: on the Thank You screen, in their My Account order-history screen, and via the order-confirmation email which points them to their My Account order-history screen. (Okay, maybe that's just two ways, with the email being a reminder of how to get to the information again if needed.)
When the customer clicks the supplied download links, a temporary link to the file is generated and the customer's browser is redirected to that temporary file. The temporary link is cleaned up later to prevent additional download via link sharing. Also, the number of allowed download counts is decremented each time the download link is pressed, resulting in some degree of theft-protection as well.

Various FAQ articles on downloadable products can be found here: https://www.zen-cart.com/tutorials/index.php?article=71

Second, as far as coding is concerned, you need to consider how the flow works if you intend to intercept things.

If you're going to assign a password to a file which you generate on-the-fly, and give that password out in the original confirmation email, then you need to do the generating and storing of that password, as well as stuffing it into the email while the order is being saved. To do that, I suggest writing an observer class which hooks the NOTIFY_ORDER_DURING_CREATE_ADD_PRODUCTS notifier point and appropriately adds the password to the $this->products_ordered_attributes variable when the specified product is processed. You can find some help text/comments in the /includes/classes/order.php class file, but DO NOT ALTER that file itself. This is the same type of code alteration that someone selling PIN numbers or software license codes or calling-cards-with-security codes, etc would do.

Next you need to also write an appropriate observer class to hook an appropriate notifier from the /includes/modules/pages/download/header_php.php script, to look up the password and the file source, process the stamping to prepare a temporary file for your customer, and deliver that file. And then come up with your own garbage-collection logic to remove the temporary file after you're absolutely certain they've successfully downloaded the file completely without any problems or need to resume etc.

khartley:

I'm not a complete rookie, just a rookie as far as Zen Cart is concerned. I DO have the skills required to make the modifications.

I'm terribly sorry. I really should have known this. After all, you made it abundantly clear in your post, didn't you?

khartley:

Well, the end goal in this is to do as much as we can to protect our products from theft...

Well, at least I managed to guess that part right.

khartley:

if a password is required to open the file, and it is unique for each order, at least there's some effort involved if someone wants to copy the materials (they'll have to give the password to others as well.) I've done this in the past with other pdf materials, and it's about the only way that I know of to at least somewhat protect our materials.

Sorry for this, but I'm afraid I need to repeat myself (or at least re-phrase my question). Other than making this difficult for yourself, how is providing a unique encryption key for each customer going to offer you any more protection than having the same encryption key for all customers? The entire premise relies on the trust you have with your customers. The fact that you even deem this neccessary indicates that you don't trust them at all.

Now lets take this one step further. Suppose I buy one of your downloadable products, complete with my own unique key to decrypt it. What is going to stop me passing on my decrypted copy to all and sundry? Nothing.
Just because you give everyone their own unique key doesn't mitigate this situation one iota.

The only time a unique key is going to offer any protection against theft whatsoever is if the downloaded/decrypted file makes use of said key. The questions you have asked and the comments you have made in regards to what you are wanting to do suggest that this isn't your aim. The aim being to provide a unique key to decrypt only.

khartley:

Now, if we can skip the pontification and attitude,

What is it about all the noobs that claim 'pontifiaction and attitude' issues simply because they don't get the answers they want?

khartley:

(The last time I did this was with a site using VirtueMart, same idea but running under Joomla, so I've been through this before.)

By "been been through this before." are you stating you've asked the same questions before (albeit for a different cart), OR, are you stating that you have found the relevent files and modified them before (Sorry, but I'm still not able to read your mind).

I'll assume the latter. I'll also assume that the folks in the VM forums were even less helpful in pointing out what files you needed to modify than we are. I base this assumption on my own experience in both forums. If these assumptions are correct , then I would also assume that you found the relevant files by other means.

As a "non rookie" I would also assume that you are familiar with (and use) one of the many IDE's for development purposes, and if this assumption is also correct (which I very much doubt), you will ALSO know how easy it is to enable the debugger and be able to 'walk' through the code and QUICKLY identify the files that you need to edit, and do so in less time than it took to ask the question in the first place.

OK, I'm making a LOT of assumptions here, partly based on my own experience, and partly by your own comments and statements.

khartley:

Now, if we can skip the pontification and attitude, if someone can help me by just pointing me to which files are involved,

IF what you are trying to achieve made any sense or had any actual benefit I probably would have taken a little more time and probably even given an answer that you wanted, otherwise it is just wasting my time and yours.

Nonetherless... since you supposedly know exactly what you are doing (as pointless as it is), you'll be needing to edit
orders.php & downloads.php. There may or may not be other files involved (see DrBytes response), but again, I'm not going to waste my time trying to help someone that doesn't appreciate additional input. I'm quite happy to send such folk down a path to nowhere if that is the path they insist on going.

Rod

Oy.

Rod, you raise some good questions. But delivering them with sugar makes better discussion than delivering them with vinegar.

khartley,
DRM is a pain for everyone -- vendors and customers alike. If only people would stop stealing. Then again, presenting one's products in such a way that there's less temptation to steal and more appealing to purchase legitimately is often a very effective model to transition to. Sometimes starting with price is best. Sell a million items for a buck each and, well, you do the math.
Or, one could encrypt their products and make it less convenient for the purchaser, and creates an income stream for the authors of the encryption software and various other cash outflows for the vendor, not to mention the time required to manage the encryption setup and execution processes or website coding.
Or one could watermark their products uniquely stamped for each customer with the customer's name, so that if they give it to their friends the friends' copy says, in effect, "Joe doesn't respect copyright and gave me this for free. Neither do I that's why I'm giving it to you too. Don't trust Joe, or me, as we're unethical." Then again if the customer provides a bogus name or throwaway email address then they're not defaming themselves after all.
Personally, I prefer no DRM at all. But if I needed to protect the digital goods I sell, then I'd use the personalization approach instead of encryption.

With Zen Cart's built-in download handling at least the customer's login account is required to do the download, and the number of download hits is limited.

What the customer does with the final product is out of your hands after that, as Rod says. If the customer redistributes the encrypted file of course it's useless to others. But if they decrypt and distribute the decrypted version then all protections are gone. Or if they share the password then it's a similar loss. But of course you know all this if you've been in the DRM business for any period of time.

I encourage you to try the built-in download delivery method before going too far into encrypting, to see whether Zen Cart's approach offers you some additional benefits your other platforms didn't provide. Maybe you can delay the DRM customization in favor of the built-in services or other suggestions offered such as minimizing the temptation to cheat and removing the barriers to actual purchasing by making the price more affordable to a broader audience, etc. I don't know your products, so I'm only offering suggestions as I see it based on a broad cross-section of merchants, not your case specifically.

/me hands the honey pot to Rod, with a large spoon :blush:

DrByte:

Rod, you raise some good questions.

Don't I always? :smile:

DrByte:

But delivering them with sugar makes better discussion than delivering them with vinegar.

Only if there are no diabetics in the audience.

DrByte:

/me hands the honey pot to Rod, with a large spoon :blush:

Way to sweet for my taste (like that's news to you). <g>

DrByte:

With Zen Cart's built-in download handling at least the customer's login account is required to do the download, and the number of download hits is limited.

If nothing else, I HOPE khartley understands this aspect of zencart, because in spite of my 'vinegar' response, this is probably all the 'protection' s/he needs.

The unique key encryption idea does have some merit, but in my opinion the work and effort involved to implement it can't be justified for the little added protection that it provides (which is basically none). IMO

It would be probably(?) be easier, and would offer far more protection if the code itself was modified to prevent it being executed without a valid security key, but I know that you already know this. Does khartley know it though?

Cheers
Rod

Thanks for the answers - I appreciate the help, truly! I'm protecting the products in this way at the request of the authors of the materials. I had done the same thing prviously for another person, also an author, and when they talked about their prospective sales ventures, this is how they all decided they want to do it - and I am not of a mind to argue with them. I got it working with no grief or compliants, and plenty of sales, on the VirtueMart site, and Zen Cart goes about things in a VERY similar manner, with all of the things to keep in mind that you both mention. And RodG, I thought that by keeping the question simple and just asking which pages were involved, I'd be pointing out that I knew I'd be making custom modifications to those pages. I didn't expect to be grilled on the whys of the situation - no offense, but let me take on the dangers, risks, trials and tiribulations without policing! For my part I promise not to bug you with any more questions on the topic.

So now I know where to start with the mods - thank you both again!

khartley:

I'm protecting the products in this way at the request of the authors of the materials.
<snip>

• and I am not of a mind to argue with them.

I guess this is where you and I differ greatly. I never have any problems with arguing with clients (obviously). I consider this as part of my job. Clients ask/request many things for all sorts of reasons, but very few of them understand the technicalities behind their requests, which is why they employ people like us in the first place. It is up to us to explain any issues or concerns that may arise from their requests.

In this case, my main concern (other than a lot of relatively useless work) would be to ensure that the client is made fully aware that this 'protection' really doesn't offer them any protection at all. To blindly go ahead with their request (undoubtedly at their expense) without telling them this, is not only unethical, but also leads them into a false sense of security.

No, I'm not suggesting that you are an unethical person, but if you, like your customers, are also unaware of this lack of protection, then it would be amiss of me to not also inform you of the situation.

khartley:

I got it working with no grief or compliants, and plenty of sales,

OK, so you have the skills to perform the changes needed, but why would the customers complain if it works as advertised. As for the plenty of sales, I don't see how this would have any real affect. I'll wager the sales would be the same regardless of whether the files were uniquely encrypted or not.

khartley:

And RodG, I thought that by keeping the question simple and just asking which pages were involved, I'd be pointing out that I knew I'd be making custom modifications to those pages.

Even if I were able to read this into your original posting, it doesn't in any way imply that you actually have the skills to perform the task. Of course, it doesn't mean that you don't have the skills either, BUT, what you were asking really doesn't have a simple answer (as you are hopefully aware by now), so on what grounds would any of us have of giving you a detailed response to a difficult question without first trying to determine if we are going to be wasting our time or not?

khartley:

I didn't expect to be grilled on the whys of the situation - no offense,

Again, you were asking a question that didn't have the 'simple' answer that you wanted. I think 'being grilled' is somewhat of an overstatement.

khartley:

but let me take on the dangers, risks, trials and tiribulations without policing!

I/we are more than happy to let you take on 'the dangers', as long as we know that you know what those dangers are, if any.

It would be amiss of us to let you accept this responsibility if your weren't aware of them.

khartley:

For my part I promise not to bug you with any more questions on the topic.

So now I know where to start with the mods - thank you both again!

You really have taken us the wrong way. You are more than welcome to 'bug us' with questions. In fact we'll even encourage you to do so.
Although you don't see it this way, but I/we don't sit here all day waiting to give people a hard time. Many of my replies in particular may come across that way, but that is simply because I don't believe sugar coating things or stating things that people want to hear. I really have no problems at all in stating cold hard facts, and/or asking further questions in order to be able to give a useful response.

In your case, the original questions were enough to let me know two things for sure.

1. You are/were planning some serious code modifications.

2. The end result of said modifications were probably not going to offer you the kind of protection that you actually needed.

Seriously, answer me this, before having this discussion were you really aware of how little protection the 'unique encryption' idea actually offers, or, have you gained a little insight as to the flawed logic in using this method?

Can you now explain why you believe a unique encryption is going to offer any more benefit over a single encryption, knowing that a software thief isn't even going to know that their encrypted file has a different key than the next customers encryption key?

Have you explained to your client(s) the flaw in this logic? (if not, why not?)

By all means, you do what you feel you need to do to keep your clients happy, this is entirely up to you, but please don't expect me to lead you blindly down a path to nowhere (or let others lead you down the same path), without at least turning on a light or two so that you can see exactly where you are headed.

If you still wish to follow the path, I'll help where I can - or in this case, perhaps not (depends on the question), because I firmly believe that this is giving your clients a false sense of security, and in my world (network security) a false sense of security is worse than no security at all.

Cheers
Rod