In the interest of understanding more about how all this works, and with an open invitation from TMitTB, you attend a meeting of the programmers.
Here’s what he shows you: To gather an e-mail address and a name, you can make a Web page using HTML.
Here’s the HTML—make changes below!
<html>
<body>
<h1>Make an account</h1>
<form method="post" action="/">
Name: <input type="text" name="name">
<br/>
Email: <input type="text" name="email">
<input type="submit">
</form>
</body>
</html>And that looks like this:
Make an account
Name:Email:
SUBMIT QUERY
On today’s agenda: How to make sure that registration is a positive experience for users but also a secure experience for the company. The questions to be discussed, the programmer tells you, are along the lines of, “Where will you put this data? Will you put it in a text file? What will you do with it? How will you act upon it?”
Enter the remaining two programmers. Programmer A, who is senior, takes her place at the whiteboard. …
Programmer A: “Let’s just start with e-mail validation.”
Programmer C: “A well-formed—”
—well-formed via a regular expression test?
—or well-formed according to RFC 5321 and RFC 5322?
Let’s assume a library, OK?
Do we send everyone who submits a form a confirmation message?
We should, right?
Is it in the spec?
No.
Then we shouldn’t do it.
Well, wait, ma
maybe we should update the spec.
It’s best practice.
Can I say what worries me?
Wait–capture that. We need to check on confirmations.
Got it.
What really, really worries me are “temporary” e-mail services, right? Like Mailinator.com, which allows you to give out “disposable” e-mail addresses.
So don’t let anyone enter a Mailinator address.
[Typing.]
Right, but Mailinator.com doesn’t have just one address. It has, like, 300.
So get a list.
There’s no list actually. You have to go and reload the Mailinator page and make a list and cross your fingers.
Yeah, we looked at this. There’s no list.
Can we not rathole on Mailinator before we talk overall security?
I mean, if we’re counting on the library validation, is that good enough? No one is going to enter a 500-page e-mail.
Russians will.
Very possibly.
But we can set upload limits, right?
Sort of, but we also allow people to upload large images for their profiles–up to 2 megabytes.
So?
No, he’s right. Those all come as a lump, so someone could enter a 500-page-long e-mail, and we need to check it.
I’ll take that if you want, because it’s going to relate to the overall database schema.
Can we catch it at the database?
That’s why I’ll take it.
Someone take a picture of the whiteboard?
Sure.
And we should talk about account expiration?
Is that in the spec?
No, but it’s a dependency for the password-expiration admin tool.
Who owns that?
Programmer A, the leader, seems very professional. She’s at the whiteboard, scribbling, erasing, scribbling, erasing. Lists, arrows, boxes, lines. She wrote RUSSIANS? on the board. But after an hour you realize: This is just e-mail. One field. One little bit of data. You haven’t even hit names yet. What if the user has one name? What if Bono or Cher signs up for an account? What if it’s the Chinese Bono? Do we want to allow sign-ups in Chinese? What browsers do we need to support? Do the call center people need to be able to manage accounts?
It’s hard not to think of barrels of cash burning.
Programmer B is entering things into a tracking system, creating issues, assigning tasks to people. A flurry of e-mailed assignments is emerging from this meeting. Programmer C is young and annoying and very programmery, but the others seem to like him well enough.
How do we ensure that credit cards are valid, that physical addresses are real? Will we perform financial transactions ourselves? Which external systems will integrate with our systems? Who will get the sales reports? We didn’t talk about the mailing list software. We didn’t talk about password length, the number of letters and symbols necessary for passwords to be secure, or whether our password strategy on this site will fit in with the overall security profile of the company, which is the responsibility of a different division.
So this is the work. It goes on for days.
It gets turned into specifications and user stories, then reviewed with TMitTB, who right now is away at a conference (but tells you he’s overjoyed you attended this meeting).
Not a line of code is written throughout this process.
No comments:
Post a Comment