Now that we have a basic e-commerce framework constructed in Django, we will begin enhancing it with additional functionality. The first obvious need is a method of tracking our customer's information, especially their orders, and providing them with access to information about their accounts. Django will once again help us with these features. Utilizing some popular third-party modules, the Django community will be playing a part as well. In short, this chapter will explain:
- The Django authentication framework and User model
- Use of third-party modules, django-registration, and django-profiles to simplify the account creation process
- Creation of an ordering system, including a model to track customer orders
- A very simple customer product review tool
First, we will discuss Django's built-in module for handling authentication, users, and permissions. We will implement an account creation system using django-registration and django-profiles, two third-party modules that have a significant adoption rate in the Django community.
Once we've established accounts for our customers, we can begin associating orders with them. In fact, we will build a very general order framework that will not only support orders from registered users, but also anonymous ones. To assist in these goals, we will build a classic shopping cart tool and discuss how to implement it using Django's session framework. We will also survey the requirements of a more powerful payment processing system, which we will ultimately create in Chapter 4, Building Payment Processors.
Finally, we will end the chapter with a discussion of Django's comments framework and how to employ it as a rudimentary customer feedback tool. This feedback tool will allow our customer's to provide feedback for any product in our database.
One of the most tedious and error-prone tasks of a web developer is managing account details. The reason this is so difficult is because it has to be perfect. If a user cannot log in, most sites are useless. It's also really important to maintain the security of user accounts, allow users to update their information, change their passwords, and many other administrative tasks.
This functionality must be present in almost all major websites and applications. This is another area where Django can save a lot of time and effort, while improving the quality of your software. By providing a standard user account system, developers can avoid the headaches inherent in writing their own user code or developing an in-house library.
All Django sites can use the same authentication interface, thus relieving developers not just of the burden of developing their own interface, but also of maintenance. Django's auth module is heavily used and rigorously tested, so when bugs are found, especially critical security problems, they are generally fixed very quickly. An in-house module or a one-off utility generally will not have this many eyes looking at it, monitoring it for changes, and testing any additions.
The auth module, like many of Django's built-in tools, is also very flexible. It supports a pluggable authentication back-end that allows developers to write custom authentication sources. This means if you have a system of authenticating users already, you can very easily replace the default authentication back-end with one that supports your system. Possible systems include LDAP, SQL, or almost anything that can be accessed via Python code. Django can even support multiple back-ends that are accessed depending on the user. More information on custom authentication back-ends is available in the Django documentation at: http://docs.djangoproject.com/en/dev/topics/auth/#other-authentication-sources.
Django's default authentication system uses a database table to store user information, including passwords. Passwords are not an ideal authentication mechanism, but it's the standard idiom for most networked software. As a result, one of the most important security concerns is to protect user passwords at all costs. Often users use the same password for multiple sites or applications and their password is only as secure as the weakest site they use.
To ensure that a user's password is kept secure, a website or application should never deal in plaintext passwords. This means it should never e-mail passwords in plaintext or display a password in plaintext on an account profile, and it definitely means passwords should never be stored in a database in plaintext. It may come as a surprise to many developers (and users!) how often passwords are passed around in plaintext.
It is unfortunate, but true, that many web-based login forms are accessed via standard HTTP connections and not a secure SSL connection. This means that passwords are sent across the Internet in plaintext. Though it requires a small degree of skill, the implication of this is that anyone listening on a connection can retrieve a user's login password.
It is highly recommended that any serious e-commerce system secure their login process, at the very least. If your site displays any kind of sensitive data, it is also recommended that you secure those connections using HTTPS. SSL Certificates are required to use secure HTTP, but for trivial or intranet applications, it is possible to generate your own certificates. However, for anything public-facing that will be used by a large number of people, it is recommended you purchase a certificate from one of the well-known, trusted root certificate authorities. Further discussion of this issue is beyond the scope of this book, but you can find much more information on the Web. A good place to start, for Apache users, is the Apache SSL/TLS Encryption page: http://httpd.apache.org/docs/2.0/ssl/.
The other cases of plaintext passwords are easily mitigated, either automatically by Django, or using some simple best practices. For example, Django's auth module automatically stores user passwords in the database using a salted hash technique. By default, Django uses the standard Python sha1 hash algorithm. This ensures that no passwords are readable simply by browsing the database, by making sure they are not stored in plaintext. And, the salt ensures the stored hashed value is not decipherable without knowing the password.
The case of sending plaintext passwords in e-mail is easily avoided: just don't do it! If you need to implement a password reset function, there are many ways to do so using simple URLs that can be included in an e-mail. The third-party django-registration tool handles this automatically, as we will see later in this chapter.