IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New "Securing" online data to be easily accessed by a few for a
while.

We want to be able to send email blasts (NOT SPAM) to CURRENT customers.

We want to be able to automatically fill in their name, email adress, physical adress in our online order screen when they click "BUY" in the email.

Choices are embed a shitload of info into the links (many in the email) (not sure the max) or to have a code in the email that allows the lookup and have the data on the website in a database.

In order to disallow people from seeing other people's stuff, each email will have several unique identifiers that need to be presented (via URL) to the web server. These identifiers are generated weekly, and will be expired after a couple of weeks so old emails would not be able to access the data. Also, the identifiers are generated randomly in a very large space (10 alpha numerics) and must match the person's email address and another token to be valid. No way to auto generate them (at least not in a reasonable amount of time) for brute force.

There is no CC data, but we are very protective of our customer data so I'm double checking.

Is this reasonable? Is there anything else I can do? Is there any alternative way that I haven't explored that I should?
New I'd leave it to the backend server(s)
Unless you are offering only a single package, doing it via links in the mail will make for a rather choppy experience. At least, I can't see how a customer could order from distinct linkswithout going through the order process multiple times. It may function for a webmail user, but a dedicated e-mail client will likely cause the browser to just open separate pages/tabs/windows. (At least, that is what just happened as I tried an offer we got.)

I think a single encrypted customer ID and a hash of the offer sent in the e-mail should be enough assuming your company is not using homebrew algorithms... (you can throw more tokens in, but if the first one can't be broken, the rest doesn't really matter.)
New Good advice, but yes, mostly single
My product is a very expensive seminar to a certain set of industry professionals who have already taken a course with us.

So when they click on a link in this email, it is listing a calendar of events, in their local area, and they almost always will choose just one. But when they do choose it, the 1st screen they see is the screen we would present as if they just added it to a cart on our site. Then they can "shop some more" or go to checkout.

The checkout screen has the various information we want to avoid having them type.
New Definitely go for the code, not embedding.
Regards,
-scott
Welcome to Rivendell, Mr. Anderson.
New That's what I decided a month ago
Then the CTO flipped out over my decision to put the customer database on the webserver.

Sigh. More political than anything else. He wanted to assert some authority over me. I invited him to cancel the project and do a full redesign, since I can't fix him and can't drag him to a psychiatrist.

Owner got involved, we did a design review, everyone decided my method made sense and they were ok with it.

Twitch twitch twictch.
New I was busy so I didn't answer before.
But I agree. Your approach is the accepted best practice.

Wade.
Just Add Story http://justaddstory.wordpress.com/
New Another answer late to the party
What problem are you trying to solve? Does each customer get custom pricing? A different list of seminars to select from? What customization do you NEED on the web order form? Have you considered just putting the forms up with ugly generated URLs and assume that anyone who shows up must have received an offer?

If the pricing etc is different do the same thing but pre-generate ALL the pages with the customization already built in. That has the risk that someone will forward their e-mail to someone else, so you'd have to decide if you have the kind of customers who would do that.
--

Drew
New Hmm
Don't care about most of that.
Same prices, same calendars.
We simply want a bit of control over competitors who would scrape our site for customers.
New Then generated, expiring URLs might be all you need
--

Drew
     "Securing" online data to be easily accessed by a few for a - (crazy) - (8)
         I'd leave it to the backend server(s) - (scoenye) - (1)
             Good advice, but yes, mostly single - (crazy)
         Definitely go for the code, not embedding. -NT - (malraux) - (5)
             That's what I decided a month ago - (crazy) - (4)
                 I was busy so I didn't answer before. - (static)
                 Another answer late to the party - (drook) - (2)
                     Hmm - (crazy) - (1)
                         Then generated, expiring URLs might be all you need -NT - (drook)

Shiny buttons are human catnip.
99 ms