This is a great explanation of how to do SSL certificates.
To speed up an AJAX page load, particularly with a toolkit such as dojo, you can do the following:
- Set the cache headers on the server for ‘far-future’ dates on toolkit files, and any other files that don’t change often. Use the directory name and a FilesMatch directive
- Use compression (mod_deflate). If you have a large initial page load, followed by many small AJAX requests, the compression overhead may not be worth it.
- Use dynamic loading to defer the loading of content until it is needed where possible
Use the YSlow plugin for Mozilla Firefox to check for other performance improvements.
Dual Page Population
Often there is some server-side logic that runs the same for the initial page load and later AJAX requests. One approach is to send a flag that indicates whether it is an AJAX request, and to use json_encode followed by an exit() to return the results for AJAX, or Smarty variables to return a full HTML page.
Here are some tips for cleaning up after your site/server has been hacked.
Look at the files that don’t belong - find a common pattern. Most have one.
Use grep -rl pattern * to find all the affected files. If you pipe the output to a file, you can turn it into a script that can automatically delete them. However - be careful to leave any files that are important. Those will have to be cleaned up manually.
If you run into permission issues, where the files were created by ‘nobody.nobody’ or ‘apache.apache’, you can use PHP’s system command to execute the rms - like so:
Check your error logs and access logs, as well as your stats to find any additional files.
Avoid chmod 777 - although there are times when it is necessary. This is a hazard of administering a site through the web. An excellent alternative is to always chmod 755 after you edit those files, if possible. This won’t work for caches, template compilation directories, or file upload areas.
Don’t forget to escape the input, for both command lines and SQL statements, and validate on both the client and server side.
Be sure to identify how the hacker got in, whether it was an outdated application with security holes, SSH, your code, or some other failure. Resolve that issue.
Remember that there may be more than one symptom of the hack. My server was being used to distribute files, run a phishing scam (no page requests were processed when I found it), and links to other servers in hacked templates.
If you have a hosting company, it is good to contact them for help - especially if there is any sort of phishing or other financial scam involved.
Finally, sometimes it is better to delete a corrupted application, or reinstall it.
Template engine - Smarty (http://smarty.php.net)
Scripting language - PHP (http://php.net)
AJAX toolkit - dojo (http://dojotoolkit.org)
ACL library - phpGACL (http://phpgacl.sourceforge.net/)
Windows AMP server - XAMPP (http://www.apachefriends.org/en/xampp.html)
Audio Processor - SoX (http://sox.sourceforge.net/)
Content Management System - eZ publish (http://ez.no)
ecommerce - X-Cart (http://x-cart.com)
Timecard - timesheet.php (http://freshmeat.net/projects/timesheet.php/)
Project Management - dotProject (http://www.dotproject.net/)
Browser - Firefox (http://mozilla.org) + Firebug plugin
Hosting Company - (http://hostforweb.com)
Map API - Google (http://code.google.com/apis/maps/)
No matter what is running on your server, you should periodically check the web stats.
It may be the only way you find files that shouldn’t be on your server.
No application is unhackable. Hackers are smart and persistant.