Posts tagged Practices
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.
