Practices
Why you should be using VirtualEnv
Jun 24th
One of the more annoying things when writing any code is when libraries change. Either deprecating functions, or changing how you expect functions to be handled. In some languages and platforms this isn’t a very large issue, libraries made by large companies seldom change. But now, so many libraries are community driven, updates are happening almost daily. New releases are happening monthly in some cases.
There is a solution, VirtualEnv allows you to create an environment for python and all its libraries. This environment is separate from the rest of your system libraries, anything installed is only accessible from within the environment. I am planning on writing a few articles related to VirtualEnv, everything from setting it up, using it, and deploying a website using django with it.
Installing VirtualEnv is fairly simple, I am assuming that you already have easy_install installed.
sudo easy_install virtualenv
Once easy_install has done its thing, and virtualenv is installed there’s really only 2 main commands you will want to familiarize yourself with. The first command is used for creating a environment, making sure to use distribute (–distribute) for installing new packages and telling virtualenv to not use the systems already installed packages (–no-site-packages). Finally at then end will be the path (full or relative) to the project location.
virtualenv --no-site-packages --distribute ./project/ cd ./project/
Now that your environment is setup, all there is to do is enter the environment, this is easily accomplished
source bin/activate
From here you will notice that your prompt has changed, adding the project name at the start, anything you install from here is now installed on your environment and will only be accessible from with in. Installing new packages is easily accomplished using the PIP installer.
pip install django
To access your environment all you must do is execute a deactivate command anywhere from within the shell
deactivate
Although this might seem like a bit more work then your standard work flow, the benefits severely outweigh the extra work involved. The entire environment is portable, meaning you can dump a list of all libraries (including versions) to a file which allows anyone to completely build your environment on there computer without requiring you to upload the entire set of libraries to them. I will cover this later in the series, stay tuned.
Website Image Caching
May 9th
In a previous post titled Django Json Woes I mentioned setting response headers for caching for Json responses. This was done to make sure that data that was sent was always refreshed and the browser didn’t use cached content. Most times this is accomplished with a technique called “cachebuster”, which means adding a pseudo random string to your request. This is done because your web browser, performs caching on your content based on urls including any parameters that are passed. By adding a random string onto the URL, your tricking your browser into thinking its a totally different URL and the browser will bypass the cache and download it.
I personally am not a huge fan of using the “cachebuster” because deciding if something should be cached or not should be decided on by the site and less by the connection to the site for 90% of requests.
This kind of cache bypassing can be useful when trying to get a bit more performance from a image heavy website. By hosting your images with a cache set to essentially never expire, and having your website pass “cachebuster” type information at the end.
<img src="/images/background.jpg?1273456709" >
The data at the end of the image url could be anything that indicates that the image has changed. When a request comes in the first time the browser would download the image based on the given url, each time afterwards it would continue to use the cache image. When you modify or change the image the data on the url would change and any hit from cached browsers would see the change and download the new copy of the image.
I am currently working on a template command for django that can do this easily, once its completed ill update this post.
Password Rules!
May 2nd
Most websites in some way or another, utilize a user authentication system. Sites that decide not to implement existing systems such as OpenId should be written to follow a few important Rules.
Very often people use the same username and/or password across all the sites they use. Although not a good practice and highly frowned on, it should be taken into consideration while rolling your own authentication system. Here are a few basic rules I try and follow:
- Passwords should contain more then 5 characters.
- Passwords should have no real limit in max size.
- Passwords should be case sensitive.
- Passwords should contain both alpha and numeric values.
- Passwords stored in the database should not be reversible.
- Passwords should be Salted and hashed, I usually add to both begin and end of original.
- Password resets should not be sent via email, due to being insecure
There are many other Rules that can be implied. These are mostly what I follow with outside of any specific business rules. By not storing the original password in the database, it will require that you add some sort of system for resetting forgotten passwords, using a combination of user email and/or confirmation questions. Also during login it would require taking the password the user enter to be salted the same way and compared against in the database.
In basically comes down to, if you are capable of retrieving users password as they typed it, its more then likely that you may have a potential security risk. Simply encrypting the username can be cracked easily if a hacker is already on your system, using a salted hash is much more secure.
