web notes - a blog

After reviewing the log files for this blog, I noticed many attempts to log into it, and send bogus contact form data.

This is my blog, registration and comments are disabled. To all those who would post helpful comments and legitimate information, I’m sorry.

I access the blog administration from a very limited set of IP addresses, so, instead of wasting my time blocking access from IPs that shouldn’t be logging in, I decided to block all accesses to the administration interface, except my IP address.

This is done using server configuration directives. Refer to the appropriate documentation on blocking access.

After making the changes, be sure to test the effect. The link above is for a nice proxy service that will allow you to visit your pages with a different IP address. The pages should display fine for all navigation through the blog, except things like logging in, and perhaps the contact form. Check anything that’s important to you.

This works if you have a site, blog, or system where the authorized users are from a limited set of IP addresses. It can’t be used to protect against ‘bots and spammers on a forum or contact form. In those cases, I recommend BotScout.

For all those who have been trying to login, please go away.

Cool scripts that are worth buying. The purchase price is far less than the cost of the time you’d have to spend to write them yourself, and, in my case, the code’s much better, too. :)

http://jetscripts.com/sanitizer.htm - This is a much improved version of script that’s been shared and used by many people. It protects your code, data, and server. I’m using this on several systems.

http://jetscripts.com/geotool/ - This script allows you to prevent people from various locations from visiting your site. If your target market is the United States, and you don’t sell to or serve other people, there’s no need to serve pages to the rest of the world. You can customize the interface so the message.

http://jetscripts.com/captcha/ - Most people don’t like CAPTCHA forms - the images are difficult to read, and the code can be bothersome to integrate. This one’s easy to read and easy to work with.

http://jetscripts.com/jetbanners.htm - Awesome. Check it out.

This block of text, from the link above, describes a form input for a username element.

#
; username element
user.login.elements.username.type = "text"
user.login.elements.username.options.validators.alnum.validator = "alnum"
user.login.elements.username.options.validators.regex.validator = "regex"
user.login.elements.username.options.validators.regex.options.pattern = "/^[a-z]/i"
user.login.elements.username.options.validators.strlen.validator = "StringLength"
user.login.elements.username.options.validators.strlen.options.min = "6"
user.login.elements.username.options.validators.strlen.options.max = "20"
user.login.elements.username.options.required = true
user.login.elements.username.options.filters.lower.filter = "StringToLower"

This is the code in the Form which uses the .ini settings:

      $config = new Zend_Config_Ini($configFile, 'development');
      $form   = new Zend_Form($config->user->login);

And the entire form is displayed with:

      <?php echo $this->form ?>

With the routine, repetitive, and time-consuming exercise of writing XHTML eliminated, you can focus on the business logic, and build applications lightening fast.

You retain complete control of the output, decorators are used to apply the XHTML to the form elements. You can create one decorator for the entire system, and your whole application will have a consistent interface.

• Use the transport mechanism to send debug information. For example, if you’re sending back an array of data, add a new element (or several), and put in the SQL query so you can see exactly what’s being executed.
• Store the returned data in global variables on the client side and use Firebug to examine them. console.debug and alert are helpful, too.
• Use var_dump and echo if you get frustrated. They’ll probably throw an error on the client side, but you’ll get to see what you want to.
• Use var_export($variable,true) if you want to do a var_dump to a string or to a file. file_put_contents(’/tmp/file’,$data,FILE_APPEND); is a great way to monitor script execution. Open a new SSH window and use tail -f /tmp/file to see it.
• Cut and paste output into Notepad so you can easily verify it. Often you need several chunks of text and data to truly understand what is happening and why.
• Develop complex pieces in a standalone environment. This is good for assembling arrays of data out of complex SQL queries. Simplifying the task so you can focus on the difficult parts will speed development.
• Watch out for extra commas in object assignments. IE will crash.
• If you have Visual Studio, use it. It can save you a tremendous amount of time when debugging under IE.
• Test for the presence of variables, objects, and attributes before using them. It isn’t really right, but you can use if (variable_exists) to see if the variable has been set up. A better solution is to initialize everything, or to use if (typeof variable != ‘undefined’).
• To remove something from a page, use style="display:none". It works, it’s simple, and it’s very low risk. If anyone is playing with your code, they’ll find it, but it shouldn’t be an issue unless it had security issues, or restricted content.
• Add a debug setting to your code that allows you to receive more information when errors occur. You can disable it for the production release.

Sometimes, code doesn’t do what it is supposed to, or what you expect. This is particularly common with open source code you didn’t write.

You can’t change the basic code architecture or data structures.

Key techniques to adapt and recover with javascript are instanceof and typeof. This allows you to test if an object or property has been created or assigned, and what type it is, then you can use it properly. Often, the best way to find out what types are being used is FireBug.

Take the time to look for examples in the code, so you don’t have to figure it all out from scratch. Usually, modifications to open source code involve code similar to that which is already in there, for example reassigning values.