Basic configuration of osCommerce, concluded - GZip Compression
(Page 4 of 5 )
GZipping is really a good way to reduce your usage of bandwidth. Basically it allows osCommerce to send compressed files over to the customer's browser, where they are rendered as normal. Most browsers support this feature, so you should not have too many problems with compatibility if you decide to enable this setting. The only thing to look out for here is whether your server supports Zlib, and is using a version of PHP later than 4.0.4. Incidentally, if you ever need to find out how your server is configured, this simple PHP script will help you out:
- <?
- phpinfo();
- ?>
Give the script a name and navigate to it in your browser, and it will automatically print out a list of all the configuration settings (alternatively, click on Server Info in the Tools section of the admin tool). This is useful if, for example, you need to find out whether your server supports Zlib.
The Compression Level default setting is 5, and this is fine for use in general, so unless you specifically want to play around to measure performance differences, it is recommended that you leave it as is if you are going to use it. Remember that some browsers might run into problems if you enable compression, so be wary of this when your site goes live.
Sessions
Sessions can be a complicated beast to understand. The 5c explanation is that sessions are what PHP uses to retain the state of a web application. What this means is that when a customer logs on to your website, PHP assigns him or her something called a session. This session holds information about this user and allows osCommerce to keep track of various important things. For example, without the use of session, how would osCommerce know which user was using which shopping cart? Since all users have their own chosen products added to their cart, osCommerce needs to be able to tell which user is which so that it can display the correct cart for each user.
This is obviously a critical function of an e-commerce site, because where money is involved, it is paramount that the right information is recorded for each transaction. In this case a transaction could mean anything from clicking on a link to purchasing a product.
Since sessions are such a critical part of osCommerce, some thought needs to go into how you want to configure your session support. We originally asked osCommerce to use database-based session support, so the first setting in the Sessions section should not affect you. If you have configured osCommerce for file-based session support, then simply set this option to the file where you would like osCommerce to record session information. You should keep this folder in your home directory for reasons of security.
The Force Cookie Use option determines whether or not we want to use cookies. Cookies are small files that are stored on the customer's browser. The information in these files can then be used for a host of different things, including making sessions more secure. The problem is that over the years many people have abused the use of cookies to the extent that a lot of people disable their use on their browsers.
If you feel you require cookies for your sessions, then osCommerce automatically inserts a page explaining to customers why and how they should enable cookies if it detects a browser that doesn't allow their use. For the moment, though, we can leave this setting as false because it is useful for us to view session information in the URL during development. Once your site has been deployed and is live, you will most likely want to make use of cookies.
While we haven't got to the stage of worrying about securing our site using SSL and many other wondrous things, it is worth discussing the Check SSL Session ID option briefly. Since we haven't got SSL enabled on our development machine, we cannot set this value to true for the moment, but it is worth considering the performance versus security tradeoff here. Enabling this setting means that osCommerce must check and validate the customer's session ID on every page call. This increases security because it helps prevent someone else sneaking in and hijacking a session, but because of the extra work involved, it slows down your site slightly. However, assuming that the performance degradation is acceptable, it is generally wiser to opt for higher security—it's really a case of "better safe than sorry!"
Check User Agent is simply another option that adds to the security of your osCommerce transactions. Enabling this forces osCommerce to check the customer's user agent for each page request. The user agent is simply a string that identifies the requesting browser to the server, so checking this every time can increase security; if you have a hijacked session, it is likely (but not definite) that the user agent of the hijacker is different.
The Check IP Address option does pretty much the same thing as Check User Agent, only this time it looks at the customer's computer's IP address. The IP address of a computer is a unique string of digits which identifies a given computer. Due to the way some Internet Service Providers designate IP addresses, enabling this setting may cause some unwanted problems for some people—AOL customers in particular are susceptible to this.
The Prevent Spider Session option is an interesting one. This basically stops automated programs from setting up a working session in osCommerce by not issuing them with a session ID. Obviously an automated program is not a real live customer, so wasting resources on tracking its passage over the site is a pretty futile thing to do; after all, it's not like it's going to buy anything. Accordingly, it is recommended that you set this option to true.
Finally, the Recreate Session option will force osCommerce to recreate a session ID whenever a customer performs a logon or a checkout. This can help to prevent customers logging into each others accounts.
For the development site, the following session settings were made:
Once we get round to deploying the site on the live server, we will need to come back to these settings and modify them appropriately. For example, the Check SSL Session ID option will be enabled on the live site, since if something is worth using SSL over, you may as well go that bit further and guard against session hijacking. So, once you have decided what settings you want, record them in your development notes for later.
Next: Summary >>
More Web Authoring Articles
More By PACKT Publishing
|
 This article is excerpted from Building Online Stores with osCommerce: Professional Edition, written by David Mercer (PACKT, 2005; ISBN: 1904811140). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 5 
