• What Were You Thinking? => Bimonthly Newsletters
• On the Web => Security and Privacy Made Simpler
• On the Blog => My January 2012 Non-Resolutions List
• Q&A => How do you go about designing the main OOP classes for a project?
• Larry Ullman’s Book News => “Modern Javascript: Develop and Design” Done!

What Were You Thinking? => Bimonthly Newsletters

In the previous newsletter, I asked for input on the idea of changing the newsletter from going out every 3-4 weeks but being longer to going out every 2 weeks but being shorter. You were also able to vote in an online poll. About two-thirds of the votes were for the change, although the more passionate responses were against the change, as those recipients already felt they received too many newsletters and emails. I think what I’m going to do, as a happy medium, is to shoot for a schedule where the newsletters come out slightly faster, like every 2-3 weeks, and are slightly shorter. This should be feasible for me to pull off without overwhelming you.

Towards that end, you may note that there’s no “What is Larry Thinking?” section in this particular newsletter. With the new plan for the newsletter, I’m not going to be quite so rigid about what goes into each newsletter, limiting myself to just five or so significant pieces. The bulk of this newsletter answers a question on OOP design.

My thanks to everyone for their input. And please always feel free to provide any feedback, questions, comments, etc., that you may have. (Postscript: Several of you rightfully pointed out that I misused “biweekly” in the text of the newsletter, despite correctly using “bimonthly” in the heading. I indeed meant “bimonthly”, although “biweekly” has the same inexactitude in that it can mean both every two weeks and twice a week.)

On the Web => Security and Privacy Made Simpler

When I was writing my Effortless E-Commerce with PHP and MySQL book, I naturally did a bunch of research, particularly with regards to the various laws that apply. Understanding the programming behind an e-commerce site is relatively simple; understanding all the applicable laws and implications of doing e-commerce is complex. One of the sites I found to be quite useful was the United States Better Business Bureau (BBB).

I’m currently going through some items in my “to read” folder, and am reading, or perhaps re-reading, the Better Business Bureau’s PDF titled “Security & Privacy – Made Simpler. If you do any e-commerce, or even just Web development, in the U.S. or not, it’s worth your time. It’s a 22-page document that discusses almost every facet of e-commerce, such as:

• Developing a security and privacy plan
• Creating and communicating your security and privacy policies
• Good employee screening and policies
• Common hack/theft strategies
• General Internet security
• Proper handling of customer data
• Payment processing
• What to do in the event of a data breach
• A preview of international e-commerce considerations

The document also has many resources listed in these and other categories. You can download the PDF from that page, but there are also related FAQs and more on the BBB’s site.

On the Blog => My January 2012 Non-Resolutions List

I’ve never been much of a New Year’s Resolution person: if something is important enough to do, start today, not on some arbitrary date that happens to be the first day of the year. (Or, you know, January 2nd, because the first is a holiday and all.) But this year I happen to have quite a long non-resolutions list. The timing is entirely coincidental: I just happen to be done with my “Modern JavaScript: Develop and Design” book around this time, and I always have a long list of things to do between books. I recently posted on my blog about my immediate plans (aka, my non-resolutions list).

Q&A => How do you go about designing the main OOP classes for a project?

While “diving into” Object-Oriented Programming development in PHP, Chris had emailed me about how one sets up the core classes for an OOP-based site. The specific example—user management with login/logout, roles, etc.—is common and not complex, but Chris didn’t know where to start. In my opinion, OOP is easy enough to use once the classes have been defined; the difficulties arise from coming up with the proper classes in the first place. So let’s look at that process, in the abstract.

Programming is a matter of taking actions with data. In a linguistic sense, it’s very much a noun-verb relationship: the user submits form data to a server; the server stores data in a database; the user requests another page; the server pulls data from a database. Whether you’re using OOP or procedural code, you need to identify both the actions and the data first. What are all the verbs that the user or Web site needs to be able to do? What are all the nouns that will be involved in those actions? Once you’ve identified those attributes of the site, procedural programming focuses first on the verbs, OOP focuses first on the nouns.

To start designing OOP classes, one must first organize the types of data the site will work with, in detail. In a user management system, there’s one obvious noun: a User. The properties of a User include: userId, username, userPass, userRole, dateRegistered, and so forth. (Conventionally, OOP uses camel-case for variable and property names.) When you think you’ve identified the nouns involved, go back and see if all of the actions now have the data that needs to be involved. When a new person registers, a User is created (as both a PHP variable and a record in the database). When a person logs in, a User is retrieved from the database and created as a PHP variable. When a person logs out, the User PHP variable can be destroyed. To see if a person has authority to do X, you’d check the User->userRole property.

In some situations, there will be nouns with overlapping roles and properties, which would suggest that you should create a hierarchy of classes. I think of shapes as being the easiest example to comprehend. All two-dimensional shapes have some common attributes, such as area and perimeter, but triangles have three sides, rectangles have four, and circles have none (but do have a radius). When you find yourself in situations like this, you’ll want to design one master class, in this case, Shape, which you never create instances of. Then you define derived classes—Triangle, Rectangle, and Circle—that you would create instances of. Admittedly, knowing when to create a hierarchy can be tough. You might think with a user roles situation that you’d want common users and administrators as two separate classes, but the only difference between the two types is in what actions each can take, which is easily managed using Access Control Lists (ACLs) or the like. Or, put another way, everything about the two users is exactly the same except for the type, so there’s no need to create separate classes (unlike, by comparison, circles and triangles that have some overlapping properties but other very different ones).

Another common class to use on a site would be one for interacting with the database. You could create your own class for this purpose, or just use the MySQLi object or PDO or the like.

Even in a simple site with content and users, there are other clear nouns: the pages of content. Going back to the language analogy, there are some sentences that have a single noun—Johnny runs or A User logs out—but many have more than one noun—Johnny reads a book or A User views a page of content. The content, then, would also be represented by one or more classes, depending upon the variety in the content displayed. If the content is just information displayed within a template of HTML, then Content might have these attributes: contentId, title, body, createdBy, dateCreated, and dateUpdated. The createdBy could be as simple as a userID integer, or more formally be an actual User instance.

Depending upon how OOP-y you want to be, you may also create classes for generating the HTML pages (i.e., View classes) and for handling actions (i.e., Controller classes). Those move you into the realm of a true MVC architecture, which isn’t always necessary, though.

In asking the question, Chris didn’t originally know how to handle the logging in and logging out and registration and such, not knowing if one makes classes for those. Those are actions performed on, or using, objects, and don’t get represented as classes themselves.

Because I’m going to be writing the third edition of my “PHP 5 Advanced: Visual QuickPro Guide” this year, I expect I’ll be doing a lot of writing on the subject of OOP, design patterns, and the like. If anyone has any more questions or comments regarding these topics, let me know.

Larry Ullman’s Book News => “Modern Javascript: Develop and Design” Done!

I am very, very happy to say that my latest book, “Modern JavaScript: Develop and Design”, is officially done. Like done, done. Last week Monday, I submitted the last chapter to be written, Chapter 13, Frameworks. In it, I quickly discuss how to choose a framework, when you should use a framework, and some common libraries (as a framework alternative). The bulk of the chapter introduces and uses jQuery and the Yahoo! User Interface (YUI) Library. For both I explain how to perform common tasks—selecting DOM elements, DOM manipulation, event handling, and Ajax, and then walk through more advanced examples. For both, the chapter explains an autocomplete example, using a PHP script as the data source. For jQuery, I also discuss the DataTables plug-in. For YUI, I also discuss and demonstrate the Yahoo! Query Language (YQL). For it, I go through a couple of examples, including fetching a weather report and a stock quote. (For the record, I specifically target YUI3, which is an improvement over YUI1 and 2, even if some of the framework is currently in beta.)

Chapter 13 is the first chapter in Part 3 of the book, Next Steps. I already wrote Chapter 14, Advanced JavaScript, which has a heavy focus on closures. Chapter 15, A PHP and JavaScript Example, creates a pseudo-complete auction system. Auctions are set to expire on a certain date and time. Logged-in users can bid on items. All dates and times are shown using Coordinated Universal Time (UTC) or the user’s timezone, if the user is logged-in. Then, JavaScript used to enhance the experience. This includes using Ajax for the login and bid forms, retrieving the latest bids via Ajax (and updating the table of bids with them), and creating countdown timers that show the amount of time left in an auction, when that’s less than an hour. I think the chapter turned out well, and it emphasizes the various ways to pass data back and forth between PHP and JavaScript, a common point of confusion.

Not only is all of the initial writing is complete, but I’ve also done the rewrites on the entire book, and I just—moments ago—finished reviewing the PDF layouts, which is the last step before the book goes to the printer. (As you can tell, there are a lot of overlapping steps here at the end.) I believe the book will still ship, as originally planned, at the end of February.

In support of the book, I’ll also be writing a couple of articles (published online for free) and create some screencasts (to be provided in various places).

I’m currently going through some items in my “to read” folder, and am reading, or perhaps re-reading, the Better Business Bureau’s PDF titled “Security & Privacy – Made Simpler“. If you do any e-commerce, or even just Web development, it’s worth reading. It’s a 22-page document that discusses almost every facet of e-commerce, such as:

• Developing a security and privacy plan
• Creating and communicating your security and privacy policies
• Good employee screening and policies
• Common hack/theft strategies
• General Internet security
• Proper handling of customer data
• Payment processing
• What to do in the event of a data breach
• A preview of international e-commerce considerations

The document also has many resources listed in these and other categories. You can download the PDF from that page, but there are also related FAQs and more on the BBB’s site.

• About This Newsletter
• What Are You Thinking? => Using JavaScript
• On the Web => Amazon Silk: A New Mobile Browser
• On the Web => Steve Jobs and Dennis Ritchie, in Memoriam
• On the Blog => Why There Are Few (No?) Good JavaScript Books
• Q&A => Could You Explain File Permissions?
• What is Larry Thinking => Sexism and Bad User Interface
• Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)
• Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

About This Newsletter

Life is busy here and I’m well behind schedule on all fronts, so this newsletter is getting out about a week to ten days late. I’m taking consolation in the fact that I’ve kept pretty close to a three-week schedule for the past year (about 15 newsletters sent in that time). Rather than blather on, let’s get on with the show!

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

What Are You Thinking? => Using JavaScript

So I’m working on my next book, “Modern JavaScript: Develop and Design.” As I write about in a blog post (also mentioned later in this newsletter), JavaScript is kind of a tricky language to write a book about, as a lot of information is required just to do a basic thing such as form validation. Like any of my books, I’m working hard to use lots of good, real-world examples to demonstrate the new information being taught. Thus far, with two real code chapters in the bank, most examples are based upon form validation and data manipulation. These are obviously crucial uses of JavaScript, and good ways to practice some of the early material. Some readers have let me know that they’re hoping to see lots and lots of examples, so I thought I’d go ahead and send a direct request out asking what, if any, specific examples or topics you’d like to see in the book. What do you know you need to use JavaScript for? What are you curious about? What have you seen that you know is confusing to you and you’d like clarification on?

All thoughts and suggestions are welcome and very much appreciated. As an incentive, I’ll go ahead and give away ten copies of “Modern JavaScript: Develop and Design” to people with the best responses.

On the Web => Amazon Silk: A New Mobile Browser

As you may have seen, Amazon announced their new lineup of Kindles recently, from the $79 base version to the $199 Kindle Fire, a rival to Apple’s iPad. One thing that piqued my interest about the Kindle Fire is that it includes a new, custom Web browser, named Silk. Amazon posted an introduction to Silk, along with a six-minute video, on their site, too. A lot on that page and in the video is marketing hype, but they raise some interesting points about the fact that Web browsers are fundamentally the same as they were 15 years ago, and aren’t ideal for today’s use, especially with all the mobile devices. Now the solution they came up with seems to be something akin to a reverse CDN: Whereas a CDN takes the load off of one server and shares it across a network of servers, Amazon Silk uses Amazon Web Services (AWS) to reduce the load on the device. From just what I’ve seen, it doesn’t seem like they’ve addressed a problem with browsers, but rather with the HTTP protocol, introducing their own gateway to improve the communications. It’ll be interesting to see what impact this new approach has, and how, if at all, it affects Web development in the years to come.

On the Web => Steve Jobs and Dennis Ritchie, in Memoriam

As I’m sure you’re all aware, Steve Jobs, one of the founders of Apple, passed away just recently. You may also know that I’m a pretty big fan of Apple. I first learned to program Basic on an Apple IIe, the first computer I purchased was a Macintosh Color Classic, and I’m probably on my 10th or 12th Mac by now. I’m not saying Macs are better than PCs, and they’re certainly not cheaper, but I definitely prefer them. A lot has been said and written about Jobs since his passing, such that I have little to add, except I would offer that I what I think was the most brilliant thing that happened during Jobs’s tenure was the ability to get non-Mac people to buy Apple products. For decades, if you purchased an Apple product, you were buying either a Mac or Apple software to run on a Mac. This accounted for at best about 5% of the computing population. Thanks to the iPod, iPhone, and iPad, almost all computer users and a majority of mobile phone users have one or more Apple products, whether or not they ever bought an Apple computer (and many of these people have since started buying Macs, too). Just brilliant, and the clear reason why Apple has become one of the most valuable companies in the world. Had you told me 15 years ago that Apple would become a dominant computer company and Bill Gates a prominent philanthropist, I wouldn’t have believed you.

Jobs’s other huge success was with Pixar, although he probably had less directly to do with Pixar’s success than the brilliant talents employed there. Jobs purchased what became Pixar from George Lucas, helped build it up, and when Pixar was purchased by Disney, Jobs became the single largest shareholder of Walt Disney. Quite the life. If you’d like one more little blip about Jobs, check out his Stanford commencement address from 2005. In it, Jobs talks candidly about work, life, and death.

Days after Steve Jobs passed away, Dennis Ritchie died, garnering much, much less media attention. Dennis Ritchie arguably had a bigger impact on computing and the world than Jobs, but is no household name. If you’re not familiar with Ritchie, all he did was create the C programming language, and helped develop the Unix operating system. C is one of the most important programming languages of all time. It has greatly influenced many other languages, and is still used widely today. In fact, PHP, Python, and Perl are all written in C! Unix, and its inspired variants such as Linux, is running most of the Internet, along with Apple’s iOS devices, Tivo’s, and many other devices.

On the Blog => Why There Are Few (No?) Good JavaScript Books

Just yesterday, I posted a blog article discussing my thoughts on why there are so few good JavaScript books. In part this post stems from time spent skimming through other JavaScript books and thinking “Really, you’re doing that in this book?” And, in part, in formally writing a JavaScript book now myself, I’m aware of some of the unique challenges that JavaScript poses for writers.

Q&A => Could You Explain File Permissions?

File permissions and file paths are probably two of the things that I get the most questions on, and that beginners are most often confused about. Some time back, Martin had asked if I’d explain file permissions, and even though a previous newsletter touched upon the subject, it’s worth going into again and in more detail. For a couple of reasons, I’m going to ignore Windows permissions and focus on *nix, which includes Unix, Linux, and Mac OS X. First, all these operating systems share the same permissions scheme. Second, statistically, most Web servers are running one of these operating systems. Third, permissions in Windows rarely need to be altered or cause problems, in my experience. And, fourth, you’re much more likely to be confused by *nix permissions, which are as follows…

File and folder permissions are an operating system’s way of dictating who can do what to that file or folder. There are three permissions that can be granted or denied: read, write, and execute. For files, read means the ability to literally open and read the file; write means the ability to modify the file; and execute means the ability to run the file (e.g., as an executable or a script). For directories, read means the ability to see the names of the files in the directory; write means the ability to modify the directory (such as create, rename, or delete files and folders therein); and execute means the ability to traverse the directory (i.e., be able to go into it). You’ll see these permissions represented by both letters—r, w, and x—and octal (base-8) numbers: 4 (read), 2 (write), and 1 (execute). These numeric values correspond to bits, meaning that different sums from 0 to 7 represent unique permission combinations. For example, 5 has to be read plus execute; 6 has to be read plus write; and, 7 is all three (5, 6, and 7 are the most common permissions digits you’ll see).

Now for every file and folder, these permissions can be set for three types of users: the owner, the owner’s group, and everyone. For example, on a Web server, you may have an account under the username trout. Your username will also be associated with a group, such as clients. Other people with accounts on the same server will have different usernames but may be part of the same group. There will also be other groups, such as staff or mysql. The permissions on any file or folder can be set as three octal digits, where the first digit represents the owner’s permissions, the second represents the owner’s group’s permissions (i.e., the permissions for other people in that group), and the third digit represents the permissions for everyone else. 644 permissions mean that you can read from and write to that file or folder, while everyone else can only read from it. Written using letters instead of octal numbers, you’ll see a file or folder’s permissions represented using 10 characters: the first reflects other details about the file or folder (I won’t get into that here); the next three are for the owner’s read, write, and execute permissions; the next three for the owner’s group’s read, write, and execute permissions; and the last three for everyone’s. Thus, the octal 644 becomes -rw-r–r–. The octal 755 is -rwxr-xr-x.

So there are the basics and the hieroglyphics you’ll occasionally see; what does this mean in actual application? For starters, you need to understand that the third category—everyone else—means everyone else on the computer, not everyone else in the universe. For example, if you create a directory with open permissions—777 or -rwxrwxrwx, that doesn’t mean anyone with an Internet connection can modify that directory’s contents. No. You can only modify a directory’s contents if you have access to the server’s file system, which means you’ve connected to the server via FTP or command line (SSH, telnet) access. And that kind of access requires using an account recognized by the server. But what about loading a Web page in the browser? Well, that is a type of server access, but not file system access. When a user goes to a Web site in the browser, the user isn’t interfacing with the server’s file system, but actually with the Web server software, such as Apache. Apache then does the actual accessing of the file system. So don’t fret that assigning open permissions to a file or directory means that anyone in the universe has access. That’s not the case.

But it is the case that an open file or directory on the server is accessible by any valid user on that server, assuming that other restrictions are not in place and that the user knows about its existence. For examples of restrictions, PHP can easily be limited as to which directories it can access and which it cannot. The same goes for Apache. In fact, the biggest security concern isn’t that people can access and manipulate your files and folders, but rather that software running on the server can. And this is where you have to be careful. Many hacks take advantage of security holes in scripts or applications to make Apache and PHP—the software already running on the server—do something malicious. All things considered, this doesn’t mean you should be cavalier about assigning open permissions, but it does mean that it’s not out-and-out irresponsible to use them when needed. Speaking of which…

The last real-world issue you’ll come across, which is a big complication for many, is establishing the correct permissions to allow for file uploads, or for PHP to write a text file, and the like. When you upload files to the server using FTP, or even create a directory using FTP, the owner of the uploaded file or folder will be you. The PHP script that needs to write to that text file or directory (in this case, “write” means to modify the directory by moving a file into it), will be running as a different user, namely the user that the Web server software (e.g., Apache) is running as (Apache commonly runs as “nobody”). In order for PHP to do what it needs to do, permissions need to be modified so that the Apache user can write to it. Normally this means using 755 as the permissions.

If you do need to create open directories and files, there are ways you can improve the security of using them, most of which I highlighted in that previous newsletter. For starters, always try to put these directories outside of the Web root directory, and then use a proxy script to safely fetch the contents. By doing so, you’re able to mitigate the increased security risk of having open directories and files by adding a layer of protection against accessing the content therein.

What is Larry Thinking? => Sexism and Bad User Interface

About fifteen years ago, when I was working at Borders bookstores (RIP), a co-worker got married. Afterward, she was talking one day about how she had gone into her bank to add her new husband to her account. The bank added her husband to the account and let her know that her husband would have to come in and authorize her before she could access the account herself. Wait, what? Yes, she went in, added her husband, and was no longer able to use the account that only moments earlier had been hers. This is because the bank’s policy was for men to be the primary account holders. As soon as her husband was added to the account, it became his account. This is just a lovely bit of institutional sexism, I think, especially when you consider that I’m talking about the mid-1990’s here, not 1950! I do not know what happened beyond that—I would hope she’d change banks, but beyond the sexism, it amazed me that a system was in place in which a person has the power to disempower themselves. A very strange concept.

My wife works in the field of education, which in the United States is known for many things, among them having broad, institutional dictums imposed upon schools and faculty. A frequent cause of problems is the software people are forced to use. Having software forced upon you is a hazard all employees face, but given the situation of public schools, such software is inevitably created under the worst of all possible situations:

• The software needs are identified by a committee of people, none of whom will actually be using the software.
• Undoubtedly a requirement is that the software can run on old, outdated computers.
• The budget will be tight.

Take these three things together, and you can plan on getting software that takes way too long to complete, that will be outdated and impractical upon its released, and that will be used for far too long from there. This sounds jaded, perhaps, and I’m certainly exaggerating some, but this is essentially the situation the American education system, if not the entire American government, is in when it comes to developing custom software.

The reason I’m thinking about this now, is that my wife was using one of these less-than-ideal applications the other day. The application itself is kind of like project management software and she was responsible for maintaining a project’s particulars through this system. Due to a lack of good documentation, she had misidentified her role on the project (within the system) and went back in to change her role. She selected what she thought was the right role for her account on that project and ended up removing her own administrative ability to manage the project. In other words, she locked herself out, and she was ostensibly the project manager! Again, why would someone create the ability for an administrator to de-administer themselves? And, what’s worse, absolutely no warning was given to my wife (i.e., the user) that this would be a consequence of the action about to be taken.

By comparison, my role on a project was just turned over to someone else, and part of that project involved making use of Amazon’s resources. Amazon, which I feel generally does everything right, did not allow me, the administrator, to just remove my name and email address from the system, thereby shutting out anyone’s access. Instead, to make the switch from me to this other person, I had to add her to the system and give her administrative access. She, then, could go in and remove my administrative access. Was this a bit more complicated? Yes. But it was the right way to handle this scenario and it worked without problem.

This, then, is a call to you: the next time you’re working on a Web site or application, think about the user interface and make sure it makes logical sense. Write the functionality so that administrators cannot disable their own access to the system. And include great documentation, and provide many, clear warnings when actions are about to be taken that are permanent. Oh, and if you’re running a bank, how about letting a person know that she is about to be blocked out of her own account? Or, you know, just make your policies less sexist.

Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)

As I expected, there was a wonderful response to my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th edition) giveaway. Unfortunately, I haven’t yet had the time to respond to everyone, or really anyone. For this I apologize, and I hope to do that within the week. So if you wrote in hoping for a book, rest assured that just because you haven’t heard from me yet means you won’t be getting a copy (conversely, it doesn’t mean you necessarily will, either). What really happened is that I’m just swamped. Apologies again!

I’ll be able to give away a few more copies of this book in a future newsletter.

Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

I just submitted Chapter 5 of “Modern JavaScript: Develop and Design”, which means I’m about 30% done with the first draft (well, first submitted draft: there are multiple internal drafts prior to that). Progress is going more slowly than I’d like, but I’ve had sick kids and other personal issues making it harder to get to work. I always hope I’m about to turn a corner and speed up. One of these days, I will!

The first three chapters cover Part 1 of the book, which represents the fundamentals of JavaScript. Chapter 1 is a bit of an introduction to JavaScript overall. Chapter 2 provides a sneak peak at how JavaScript is used in a Web browser. Chapter 3 discusses and demonstrates several tools you’ll want to use.

The second part of the book is the heart of JavaScript as a true programming language. Chapter 4 covers simple data types (numbers, strings, and Booleans). Chapter 5 is on control structures: conditionals and loops. Now I’m turning to the fun stuff, and the topics that differentiate JavaScript from other languages. This includes objects (Chapter 6), functions (Chapter 7), events (Chapter 8), and the browser (Chapter 9). Hopefully by the next newsletter I’ll have those four chapters written. Hopefully!

What you’ll want to do to create a cookie is create a new object of type CHttpCookie: Yii’s class for cookies. Here, then, is the syntax for setting a cookie in Yii:

Yii::app()->request->cookies['name'] = new CHttpCookie('name', 'value');

You must use the same name value in both places, replacing it with the actual cookie name. Remember that the cookie’s name, and value, are visible to users in their browsers, so one ought to be prudent about what name you use and be extra mindful of what values are being stored.

Tip: Because the cookie’s name must be used twice in the code, you may want to consider assigning the cookie’s name to a variable that is used in both instances instead.

Once you’ve created a cookie, you can access it (on subsequent pages, because cookies are never immediately available to the page that set them), using Yii::app()->request->cookies['name']->value. You have to use the extra ->value part, because the “cookie” being created is actually an object of type CHttpCookie (and Yii, internally, takes care of actually sending the cookie to the browser and reading the received cookie from the browser).

To test if a cookie exists, just use isset() on Yii::app()->request->cookies['name'], as you would any other variable.

To delete an existing cookie, just unset the element as you would any array element:

unset(Yii::app()->request->cookies['name']);

To delete all existing cookies (for that site), use

Yii::app()->request->cookies->clear();

By default, cookies will be set to expire when the browser window is closed. To change that, you need to modify the properties of the cookie. You can’t do so when you create the CHttpCookie object (i.e., the only arguments to the constructor are the cookie’s name and value), so you must separately create a new object of type CHttpCookie, to be assigned to Yii::app()->request->cookies later:

$cookie = new CHttpCookie('name', 'value');

Then adjust the expire attribute:

$cookie->expire = time() + (60*60*24); // 24 hours

Then add the cookie to the application:

Yii::app()->request->cookies['name'] = $cookie;

You can manipulate other cookie properties using the above syntax: domain, httpOnly, path, and secure. Each of these correspond to the arguments to the setcookie() function. (You can also manipulate the value of the cookie through $cookie->value and the cookie’s name through $cookie->name). For example, if you want to limit a cookie to a specific domain, or subdomain, use domain; to limit it to a specific folder, use path; and to only transmit the cookie over SSL, set secure to true.

You can also improve the security of your cookies by setting Yii’s enableCookieValidation to true, in the Yii configuration file:

return array(
    'components'=>array(
        'request'=>array(
            'enableCookieValidation'=>true,
        ),
    ),
);

Cookie validation prevents cookies from being manipulated in the browser. To accomplish that, Yii stores a hashed representation of the cookie’s value when it gets sent, and then compares the received cookie’s value to ensure they are the same. Obviously there’s extra overhead required to do this, but in some instances, the extra effort is justified by the extra security.

Finally, one good reason to use cookies in a Yii-based site, even if the site is otherwise using sessions, is to prevent Cross-site Request Forgery (CSRF) attacks. A CSRF works like this: malicious site A has some code on it, such as an image tag whose src attribute points to a page on site B that does something meaningful: http://www.example.com/page.php?action=this. When any viewer loads the page on site A, the use of that src attribute has the effect of that user performing a request of the page on site B.

As an example, let’s say that an administrator at your site logs in and does whatever but doesn’t log out. The administrator therefore still has a cookie in her or his browser indicating access to the site (i.e., the user could open the browser and perform admin tasks without logging in again). Now let’s say that the src attribute on malicious site A points to a page on your site that deletes a blog posting. If the administrator with the live cookie loads that page on site A, it will have the same effect as if that administrator went to your site and requested that page directly. This is not good.

To prevent a CSRF attack on your site, first make sure that all significant form submissions use POST instead of GET. You should be using POST for any form that changes server content anyway, but a CSRF POST attack is a bit harder to pull off than a GET attack.

Second, set enableCsrfValidation to true in your configuration file:

return array(
    'components'=>array(
        'request'=>array(
            'enableCsrfValidation'=>true,
        ),
    ),
);

By doing this, Yii will send a cookie with a unique identifier to the user. All forms will then store that same identifier in a hidden input. The form submission will only be handled then if the two identifiers match. With the case of a CSRF attack, the two identifiers will not match because the form’s identifier will not be passed as part of the request (I hope this is clear; if not, let me know). Note that this only works if you’re using CHtml to create your forms (if you manually create the form tags, Yii won’t insert the necessary code for preventing CSRF attacks).

The most important thing to remember about cookies, which I’ve already stated, is that cookies are visible to the user in the browser. And unless you’re using SSL for the cookies, they are also visible to anyone else while being transmitted back and forth between the server and the client (which happens on every page request). So be careful of what gets stored in a cookie! If the data is particularly sensitive, use sessions instead of cookies.

• Maintaining Secure Passwords: Five Critical E-Commerce Security Tips in Five Days
• Securely Handling File Uploads: Five Critical E-Commerce Security Tips in Five Days
• Have a Emergency Plan: Five Critical E-Commerce Security Tips in Five Days
• Validate, Validate, Validate: Five Critical E-Commerce Security Tips in Five Days
• Understand Your Hosting, Five Critical E-Commerce Security Tips in Five Days

The postings are in concert with my “Effortless E-Commerce with PHP and MySQL” book, although the information provided, from theory to actual code, should be useful whether you’ve read that book or not.

After you’ve downloaded the code and put it on your server, you use it like so:

require('/path/to/EmailAddressValidator.php');
$emailValidator = new EmailAddressValidator();
if ($emailValidator->check_email_address('test@example.org')) {
    // Email address is technically valid.
} else {
    // Email not valid.
}

The second part of this analogy is that while it’s important for a restaurant to look clean (so people will eat there), it’s more important that it’s actually clean (so that diner’s don’t get sick, so that the inspector doesn’t shut you down, etc.). And so your Web site must actually be secure, so that nothing bad can happen to the users, your clients, the Easter bunny, and so forth.

The final reason I think this analogy works is that like security, like cleanliness, isn’t an absolute and the amount of effort you put into it should depend upon the situation. Your front porch doesn’t need to be that clean, but your bathrooms and kitchens sure do. And maybe you’re the kind of person that would thoroughly clean monthly, weekly, or daily. Maybe you’re the kind that will take cleaning to the disinfecting level. There’s no right answer in these situations: there’s better and there’s worse and there’s what’s right for you and your situation. The same goes for security. A site that handles no money has one level of security requirements; a site that performs online banking has a totally different level. Most importantly, just because you cleaned today, doesn’t mean your place will stay clean forever. And the Web site or application you ship today without any issues could become vulnerable tomorrow (most likely because of a found concern with underlying software or third-party applications).

So there’s my simple, yet overly-described, analogy for Web site or application security. Hopefully it’ll help you in the way you think about your Web site (or the next meal out!).

You really have to start thinking about security from the get-go, which means the database. Secondary column properties make a big difference to the reliability of the stored data. This means identifying columns as NOT NULL, UNSIGNED, a particular number of decimals, and applying a UNIQUE index (all of these as appropriate, of course). These settings will prevent bad data from getting into the database, such as negative quantities or duplicate email addresses (the PHP code will need to handle those MySQL rejections, though).

In your PHP code, you’ll want to use regular expressions to validate data when you can. And all strings should be run through an escaping function like mysqli_real_escape_string(), prior to using them in a database query. I would do this even if the data already passed a regular expression (you cannot be too careful). You can also consider applying strip_tags(), too.

For numeric values, I strongly recommend type-casting:

$something = (int) $_POST['something'];

Type-casting to numbers will make the data safe to use in queries. If you type-cast a string as an integer, the result will be zero, so you can type-cast, then check for a valid value (i.e., greater than zero). Valid numeric values will just be formally converted from a string with that value to a number with that value.

With variables, it’s also best to assume the values are invalid or not present at all, then prove otherwise.

When you get to your HTML, there’s not much you can do to guarantee security, but you can encourage it. For example, you can limit the length of a text input to whatever is the maximum size of the corresponding column in the database. Or you can use drop-down menus with preset values. Client-side validation using JavaScript is nice for the end user, but is not a real security tool as JavaScript can easily be disabled.

Once you’ve done all that (and hopefully you already are doing most of these things), you can run some tests to find potential security holes. To start, I think about the three kinds of people that use the site: those that use it perfectly, exactly as intended; those that use it without malicious intent, but that might cause problems; and those that are trying to hack the site. In the first category you have pretty much just me. I’m developing the site, I know what it’s supposed to do and how I think it’s to be used, and I’m not likely to break it. In the second category is almost everyone. They just want to use the site, they may make mistakes, they may have apostrophes in their names, and they just expect the site to work regardless. For these people, the goal is to provide a proper user interface, point out mistakes when they occur, and insure that clean, proper data is used at every step of the way. For the third category of user, they’ll do everything they can, include taking extraordinary steps, to try to break your site in order to get some information they deem useful.

There’s really no point in testing the site as I’d use it, so I quickly start imitating the behavior of the second group of users. First, I test my PHP scripts by submitting forms without doing anything at all. The result should be appropriate error messages to the end user, without ANY “undefined index” or similar PHP errors. The same goes for scripts that expect to receive values in the URL: test them without sending any values in the URL and see the result. Second, I fill out forms using invalid values: numbers for strings and vice versa. What is the result? Third, I fill out the forms using potentially valid, but complicated values, such as strings with apostrophes and quotation marks, possibly even with HTML.

As I said, I’m not maliciously-inclined (or I’d like to think I’m not), so it’s hard for me to think like a hacker. Much of what a hacker might try to do will be caught by the previous set of tests, though. If your site handles invalid data, apostrophes, quotation marks, and HTML tags properly, you’ve already done a lot to prevent bad things from happening. Hackers might take things further though, like creating their own HTML form that submits data to your PHP scripts (you can POST data without using a form at all, too). What if a hacker were to create a copy of your form, and replace your “quantity” or “states” drop-down menu with a text input, so they could use their own values? How well would the PHP script handle that contingency?

Hackers also like to get into places they shouldn’t, so try directly accessing scripts or directories that should be protected. Also try directly running scripts that are meant to be included, such as a configuration file. If you’re serving files to only authenticated users, can those files be viewed directly?

Sometimes the goal of a hacker is to find out information about your server, so you have to be extra careful that the site does not give too much away, specifically, too much about PHP, Apache (or whatever Web server), and MySQL. Towards that end, you have to make sure that MySQL errors are handled properly, without revealing anything to the end user. To do this, you may need to temporarily break your database scripts to see the result. For example, you’ve got a site working and it’s not giving away any secrets, whether or not the user behaves themselves. But what if the database server goes down or is to busy or something else happens to prevent your PHP scripts from connecting? What would the user see then? Hopefully nothing but a generic “system is done/come back later” apology.

With practice, developing sites to properly handle all of these situations and types of users becomes second-nature (not that you shouldn’t continue to test them). But I know that as you’re just getting going, it’s natural to feel like you haven’t done enough or tested enough. I hope that these few paragraphs provide a better feel for the process.

The most effective results came from using ROT13 encryption, in which the source code has the email address in an encrypted format, with JavaScript then dynamically creating a legible, and clickable, mailto link by decryption. Of course, the JavaScript method won’t work if JavaScript is disabled, but I don’t personally worry about that too much.

There are also two very interesting CSS techniques (this code comes from http://techblog.tilllate.com/2008/07/20/ten-methods-to-obfuscate-e-mail-addresses-compared/):

<style type="text/css">
span.codedirection { unicode-bidi:bidi-override; direction: rtl; }
</style>
<p><span class="codedirection">moc.elpmaxe@emanym</span></p>

and

<style type=”text/css">
p span.displaynone { display:none; }
</style>
<p>myname@<span class=”displaynone”>null</span>example.com</p></p>

The first example says that the backwords HTML text should be displayed from right to left order. The second adds an invisible null to the example address. Unfortunately these two routes won’t allow for clickable links and make your site less accessible. Which leads me to a main consideration in this battle: There’s no perfect solution sometimes!

One option that I like is to just use a contact form that sends an email upon submission. This only really works if you have just a single email address associated with a site and it does limit what content can be sent (e.g., no attachments without some extra form work). On my own site, I use an image representation of an email address. But like the CSS methods, a link won’t be clickable and the accessibility is degraded. You can minimize the latter concern by making the ALT tag descriptive, like my first name plus my first initial at this domain. But also keep in mind it’s possible for bots to read images, which is why CAPTCHA text has to be so strange. That being said, I’ve been using this technique for a couple of years now and I don’t think I’ve gotten any spam on that address yet.

Those are relatively simple routes. If you want a really thorough solution, A List Apart has a detailed client- and server-side approach you can try.

As for what I’ve done lately, on a recent Web site I created, dozens of email addresses are listed for the different people involved with the project, so using a contact form wasn’t possible. The project itself involves people for whom accessibility is key, so the CSS techniques were out, too. In the end I went with a JavaScript solution, using jQuery and PHP, which the site is built with. This particular technique—and I have no hard data for how effictive it is—uses a PHP function to create a somewhat-obsfucated HTML source of an email address, then uses a jQuery Plugin to turn that source into a readable, and even clickable, link. For this project right now, it seems to be a reasonable compromise.

Of course, bots keep learning and they’ll figure out how to get around these techniques, which is why we all need to stay informed and try new things. That, and get rid of our email addresses every couple of years!

• Handling JSON Data Securely
• Debugging XML/JSON Requests
• Choosing a JavaScript Framework
• Performing Cross-Domain Ajax Requests
• Loading JavaScript Faster