web notes - a blog

Tricks for debugging web pages under IE, if you don’t have any tools.

• Comment out all but the code that doesn’t work. Often the code that’s not working is broken because of something else.
• Have a separate CSS file, just for IE
• Use alert to halt javascript execution. This lets you see which command was executed prior to the failure.
• If you have a complex page, use View Source, then paste the text into a file under vi. Use grep “<div” | wc -l, and grep “</div” | wc -l to count the number of open and close divs.
• If you are using a template language such as Smarty, hard-code values for quick tests.
• Be sure to clear the cache, aka delete the temporary Internet files. Otherwise, CSS and javascript changes may not take effect.
• Refer to w3schools.com to check for supported attributes for various browsers.
• Be creative. If .style.display=’none’ doesn’t work, try removing the node.
• Limit the versions of IE you will support, and alert the user. IE6 is a good starting point.
• Accept some problems. For example, IE6 and Apache sometimes have trouble with .png transparency. Either make those images a different filetype, or allow them to display as the server delivers them and the browser displays them. It is not worth striving for perfection to support software that will eventually become obsolete.
• Use server-side logic to deliver the best code for the browser. Again, this should be limited to that which is absolutely necessary, but it is often easier to prepare the page well on the server, than to adjust it once it has been delivered to the browser.
• Use FireBug. It is bundled with dojo, and probably available as a stand-alone component.

These aren’t specific courses, the intention is to provide a rough parallel. They aren’t in a particular order, and multi-semester study is implied for some areas.

• Operating Systems - Particulary Linux. Appreciation of the hardware that makes the system work, especially the server. Understanding of the commands, organization, processing. Use of log files.
• Computer Architecture - Key concepts - physical elements that make up the machine. Capabilities and limitations. CPUs, memory, disks, interrupts, timing, queues, caching. Performance considerations. Requirements awareness.
• OOP / Data Structures - Ability to abstract a system into components that can be efficiently operated on. Queues, linked lists, trees, arrays, multi-dimensional arrays, matrices, classes and objects. Methods, properties and events. Vital for server and client side.
• Algorithms - Appreciation for the impact of how code is written on performance. This is especially important because many web applications are written in interpretive languages. Awareness of high overhead operations (which can be avoided or performed by existing library functions).
• Logic - The ability to break a problem in to manageable pieces and write efficient code.
• Systems Analysis - Developing a high level perspective to understand how system components interface and interact. Distribution of requirements.
• Technical Writing - Written communication is vital to describe the work that will be performed.
• Assembly Language - A view inside the processor. Although not necessary, it is valuable to understand what the processor is, what it does, how it does it, and how to control it. Complements the OS and Computer Architecture courses.
• Data Communications / Introduction to Networking - Writing code for the Internet is heavily influenced by its distribution. It is important to know how the data gets from the server to the client and back again. This affects how pages are constructed. Key elements, difference between form and content, compression, bandwidth.
• Security - Use of encryption, OpenSSL, protecting data, web application firewalls, passwords, ports, server firewalls, watchdogs, etc.
• Server Software - IIS or Apache. How requests are received, protection of data, efficient use of disk space and bandwidth. Caching. How to create and manage accounts. Use of web stats to monitor sites. Use of log files.

• Current Industry Trends - Frameworks, template systems, AJAX, toolkits, CDNs.

A web site is the most visible part of a companies Internet presence, but not the only part.

The following issues must be continually addressed and frequently monitored:

• Content Maintenance This includes all content changes. It may also require navigation changes. Many sites use content management systems such as eZ publish, Drupal, or Joomla. These make editing content easier, but still require some training. The content itself is important, but its presentation must also be considered. Web pages should be easy to read, and informative. They should be attractive and consistent with the other pages on the site. The content should be consistent with the language of the target site visitors. If it is a professional site, everything should be spelled properly, cased properly, and with valid grammar. Slang language should be avoided.
• email Careful use of email accounts and forwarders is important. Forwarders allow the same address to deliver messages to multiple people. In addition, a forwarder can ease personnel transitions, the email address does not have to change if a different person is handling it. email accounts must be budgeted. Disk space is cheap, but it isn’t free. In most cases, the disk space used by email is deducted from the available space for the site. For that reason, one must keep track of the number of accounts and how big each mailbox is. Notification should be set up to ensure people are alerted when their mailbox is full. Issues that can take alot of time include recovering if the domain or server is blacklisted, blocked emails for various reasons, client configuration issues.
• Contact mechanisms First, one must comply with the anti-spam laws http://www.ftc.gov/bcp/conline/pubs/buspubs/canspam.shtm. Newsletter content can also be a valuable part of a site. In addition, contact mechanisms must be protected from abuse. Tools available include CAPTCHA http://www.captcha.net/, Akismet http://akismet.com/, http://ostermiller.org/contactform/, and custom code.
• Logs Error and access logs should be checked at least weekly for any unusual entries, for example missing pages or images. Some hacking attempts will show up in the error logs, as file not found errors - usually with distinct URLs, repeated requests into forbidden areas. Restricted areas should not be served, if they are, the web server configuration should be updated to protect them. IP address patterns should be observed to see if requests (potential attacks) are from a specific area. These can be blocked with a firewall. If you have access to the email logs and the server level logs, particularly the SSH and MySQL logs, they should be reviewed as well.
• Application Management It is extremely important to ensure the applications are up to date. Application upgrades range from a simple button click with Fantastico to complex database and patch or upgrade sequences. As a rule, the cost of these upgrades should be included in maintenance allowances.
• Security In the unfortunate instance when an application is hacked, it must be cleaned up, and usually the application must be upgraded. These tend to be emergencies and often result in outages. Careful Application Management (above) can greatly reduce these. Credit card and personal data must be handled very carefully (ideally by someone well-qualified :yes: ). https://www.pcisecuritystandards.org/
• External Interfaces Many sophisticated sites have complex interfaces into payment gateways or web services. This type of code usually requires strong engineering skills.
• SSL Certificates To support HTTPS for ecommerce and secure access to information, certificates must be purchased, approved, installed, and then renewed as required. Renewal requires reinstallation.
• Web stat checks Periodic review of the web stats allows an evaluation of the site’s search engine positioning, sources of traffic, keywords, and pages accessed.
• Performance Site visitors expect a timely display of a site. There are many ways to ensure a site performs well, the best solutions vary by the type of site, however, the following issues are clear: client-side caching should be used, content delivery networks are valuable for offloading the server and the network, images must be optimized - delivered properly through the server and displayed properly by all supported browsers, javascript should be portable and efficient, page construction should be evaluated with tools like http://websiteoptimization.com prior to launch and after major changes.
• Custom code Custom code should be carefully audited for security. http://phpsec.org, http://www.fortify.com/security-resources/rats.jsp. It should be protected by a web application firewall such as http://modsecurity.org.
• Quality Assurance Time must be taken to check the site for problems like broken links to external resources, and any problems within the site itself.
• Technical Quality The quality of code used on a site is visible to all visitors. How it looks in the browser, and the code that delivers it should be high-quality, with current technologies applied properly. Poor displays and bad code can harms a companies reputation and professional image.

There are times when an anonymous report is appropriate. It is usually when you are reporting something and don’t need to be involved further.

In that case, completing a contact form with bogus information and an email address at anonymous.com or example.com should pass validation to deliver the message.

I don’t think email validation should discard anonymous reports, unless they are attempts to spam.

http://anonymous.com/
http://www.example.com/

The following architecture with Smarty and dojo allows you to the client and server synchronized for validation for RIA/PHP applications.

Each input has 4 characteristics defined in a (PHP) .ini file -

V_input_name = regExp (usually includes length)
L_input_name = max length
R_input_name = true or false (required or not)
T_input_name = type of input data in database, used to support documentation

Each input also has 3 characteristics defined in a Smarty .conf file, and there is a .conf file for every language (.ini be under languages)

E_input_name = error message
I_input_name = invalid message
P_input_name = prompt message

Smarty constructs the input tags like so:

<input type="text" dojoType="dijit.form.ValidationTextBox"
    name="input_name" id="input_name"
    regExp="{#V_input_name#}"   
    errorMessage="{#E_input_name#}"
    promptMessage="{#P_input_name#}"
    invalidMessage="{#I_input_name#}"
    length="{#L_input_name#}" />

There is a simple javascript validation that accepts an array of inputs and tests if they are valid with input_name.isValid(), displaying input_name.errorMessage if not, and cancelling the submit.

On the server side, there is a loop that tests the inputs against the same strings:

foreach ($aInput as $k => $v)
  if (isset($aIni['V_'.$k]))
  { 
    $sInput=trim($v); 
    if (isset($aIni['R_'.$k])
    if (($aIni['R_'.$k]=='true') && ($sInput=='')) /* Test for required */
      return false;
    if (!filter($aIni['V_'.$k],$v))  /* flter ensures data complies with regexp */
        return false;
   }

This allows the client-side code to help the user enter valid data, and allows the server-side code to protect the server by disallowing or discarding data that isn’t valid.

Please note that page-level validation, where the required state and content of data may vary based on other inputs must be reflected at both the client and server side.