Setting Up the Catalog Administration Page

Setting Up the Catalog Administration Page
Before building any administrative pages, we need to put in place a security mechanism for
restricting the access to these pages. Only authorized personnel should be able to modify the
product catalog!
Security is obviously a large topic, and its complexity depends a lot on the value of the
data you’re protecting. While we don’t have the resources to create such a secure environment
as that implemented by banks, for example, when creating an online store, we still have a great
responsibility to make sure our data and our customers’ data is safe.
Our security implementation deals with these important concepts:
• Authentication: This is the process in which users are uniquely identified. The typical
way to identify users, which we’ll also implement in TShirtShop, is to ask for a username
and a password.
• Authorization: This concept refers to the process of identifying the resources an authen-
ticated user can access and restricting his or her access accordingly. For example, you
can have administrators who can only edit product names and descriptions and admin-
istrators who can also view customers’ personal data. The administrators of our little
shop will have access to all the restricted areas, but as the site gets larger, you may want
to delegate administrative tasks to more employees for both management and security
reasons.
• Secure communication channel: Of course, all of our authentication and authorization
efforts are in vain if it’s easy for a hacker to implement a man-in-the-middle attack,
which refers to the scenario where an individual listens to the traffic on a network to
intercept sensitive data. Such an attack could be made when an administrator logs in
while the attacker listens to the network traffic to intercept the administrator’s username
and password. To guard against this potential problem, we use the HTTPS protocol, which
encrypts the transmitted data and ensures a degree of confidentiality of the transmission.
Using Secure Connections
HTTP isn’t a secure protocol, and even if your site protects sensitive areas using passwords (or
other forms of authentication), the transmitted data could be intercepted and stolen. To avoid
this, you need to set up the application to work with Secure Socket Layer (SSL) connections
using the Hypertext Transport Protocol, Secure (HTTPS) protocol.
To be able to accept incoming HTTPS connections, a web server must be configured with
a security certificate. Security certificates are basically public-private key pairs similar to those
used in asynchronous encryption algorithms. You can generate these yourself, but if you’re not
a trusted certification authority (such as VeriSign or Thawte), this method may be problematic. 
Digitally signed SSL certificates that aren’t issued by trusted certification authorities will
cause browsers to doubt your security. When a user accesses secure pages whose certificate
isn’t issued by a trusted certification authority, the browser will show a warning message. This
isn’t disastrous when securing pages that are to be visited by your company personnel but would
certainly affect customer confidence if such a warning message shows up, for example, when
paying for an order. 
If you configured your system using XAMPP, as described in Chapter 1, your Apache web
server is already configured with a certificate. If you set up Apache on your own, we recommend

you check out the article at http://www.sitepoint.com/article/securing-apache-2-server-ssl.
For test purposes, you can also get an SSL-enabled Apache version from http://www.devside.net/
web/server/free/download.
For a production scenario, you need to buy a trusted certificate through your web hosting
company, or, if you manage the web server yourself, obtain a SSL certificate from a known and
respected organization that specializes in web security, such as these:
• VeriSign (http://www.verisign.com/)
• Thawte (http://www.thawte.com/)
• InstantSSL (http://www.instantssl.com/)
Web browsers have built-in root certificates from organizations such as these and are able
to authenticate the digital signature of SSL certificates supplied by them. This means that no
warning message will appear, and an SSL-secured connection will be available with aminimum
of fuss. For example, when loading such a URL in Opera, a little golden lock shows up next to
the address bar. Clicking that symbol shows the name of the company that registered the SSL
certificate (see Figure 10-5).