On Wed, Jul 6, 2011 at 6:16 PM, Kirk Bailey <kbailey@xxxxxxxxxxxxxxxx>wrote: > ** > > On 7/6/2011 9:31 AM, Stuart Dallas wrote: > > On Wed, Jul 6, 2011 at 3:01 AM, Kirk Bailey <kbailey@xxxxxxxxxxxxxxxx>wrote: >> >> >> On 7/3/2011 4:53 PM, Stuart Dallas wrote: >> >>> Only allowing them to access the URL once is a bad idea. If their >>> download fails, is corrupt, or any number of other things go wrong (think >>> accelerators, browser accelerators, etc) then you end up with a lot of >>> support mail. Better to give them access for a short period of time. >>> >>> Ok, so it just got more complex- if we let them do it twice, ior three >> times, we have a more complex design specification; if we let them do it >> unlimited times, we just defeated thepurpose of the exercise. How about >> this: if it fails, the customer can email us, adn we can reply with a copy >> as an attachment; a ripoff artist will not be in the log, and a complaint of >> failure to download gets them nothing. > > > I don't see how it got more complex. > > IT IS SIMPLER TO IMPLEMENT IF IT WORKS EVERY TIME A LEGITIMATE CODE IS > PRESENTED IN THE URL. > Which part of my solution would cause that not to be the case? If there is a list of valid passwords and it does not change, the password > will work every time. A clever hacker makes 1 purchase and uses this over > and over to steal other products- not good. We need to remove the password > after it is used. > If you read back you'll note I said "generate a unique token linked to their account." At no point did I say the tokens would be shared between customers. IF the first time it is used the password code is deleted from a file, it > cannot work a second time. That is a mild increase in complexity. > > If we want it to work more than once, then we argue- how many is enough? > And how do we track uses? If they got product the first time, the second ( > and third, and fourth...) permitted uses are there waiting for a cleve > hacker to steal product. And if we build a mechanism to verify successful > delivery or product prior to deleting the password, it is more complex > still. So we need to take time to think about this in detail. > You don't track uses. When the URL is requested it looks up the unique token somewhere and gets the expiry timestamp. If the token doesn't exist or the expiry timestamp is in the past, access is denied. There's no need to verify successful delivery - the only way to do this is to ask the user which gives them an avenue to never say it was successful and therefore have the URL work indefinitely. Give the token an expiry timestamp 1 hour, 6 hours, 12 hours or 24 hours in the future. It doesn't really matter how long, as long as it's enough time for them to get the link (remembering potential email delays if it's sent by email), and for them to use it a few times (bearing in mind the size of the download and the effect that has on how long failed attempts could last. If we allow it once, and delete is as part of the vend process, we also can > offer a contact link should they have problems with the download. > This would likely cause an unnecessary increase in support costs. This may not be a concern of yours right now, but if you're in the business of making a profit I'd recommend it becomes a permanent fixture on your radar. Nothing about this is complex in my experience. I've built checkout systems that use this process, and I've found it to be straightforward to implement. Maybe I'm not explaining it very well, but it really is a simple, very well-used system utilising a very common concept of expiring tokens. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
