Oatmeal Cookies, No Wheat

4 cups Rolled Oats
3/4 cup Canola Oil (more omega-3 and less allergens than corn or soy oil)
1/3 cup Honey (raw, unfiltered, more nutrients and more flavor)
Mix and let stand 8 hours

1 tsp vanilla extract
4 tsp ground cinnamon

If you want cookie shape instead of oatmeal crumble:
2 eggs, well beaten
1/2 tsp salt (dissolve in eggs, or get salty bites)

Add to taste:
raisins
chocolate chips or
1 tbsp chocolate powder (natural and Dutch processed, no added sugar)
raw almonds or walnuts, finely chopped

Preheat oven to 350F
Lightly coat baking sheet with butter, or natural cooking spray
Spoon mixture onto sheet (about 1/2 inch thick; if making cookies, about 2 dozen)

Crispy: bake 17 minutes, store in a non-airtight container

Moist: bake 14 minutes, store in airtight container

Original recipe (“Awake Oatmeal Cookies”) was much sweeter. 2 cups brown sugar instead of honey, 1 cup oil (use less oil when use honey).

Security from Bad User Agents

One way to protect your site is blocking bad “User Agents”.

A user agent is the way your browser identifies itself to your server. Your server could use this to send different versions of your site to the browser; for example, not sending images to a Lynx browser that only displays text, or to a browser that is a screen reader for blind or low-vision people. My Firefox browser has this user agent:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0

Search engines also make requests of your server and identify themselves with a user agent, as do hacker bots.

The User Agent can be changed. Some browsers pretend to be a version of Internet Explorer. Some hacker bots pretend to be any major browser they like, switching for different requests. Some pretend to be Google’s search engine bot.

Web site developers will use browser plugins to send a different user agent string, so they can test what their web site sends to people with other browsers. (I’m using the Firefox “User Agent Overrider” plugin to change my browser’s user agent; on my server I detect user agent, which lets me know the browser type and version, operating system, whether it is a mobile device, and more, using a PHP script from http://techpatterns.com/downloads/php_browser_detection.php which I think is much nicer than using javascript since I only send to the browser the best HTML/ CSS for it.

So the User Agent isn’t a good field to check for security. There are other fields that bad bots can’t fake, for example bad words/phrases in the URL they are looking for on your site.

But checking the user agent is good for blocking nuisances that waste your site resources.

How Do You Block a User Agent

Almost all shared hosting accounts are on Apache servers.  Microsoft IIS is much harder for most people to use, so I’ll give Apache .htaccess examples.

The “Better WP Security” plugin for WordPress has a good-sized list of bad User Agents that it can add to your site’s list.

Here’s some of their code for blocking user agents (all the other examples I’ve seen use the exact same approach):

RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [NC,OR]

The ^ means “at the start” of the User Agent, the [NC,OR] says not case sensitive and any one or the other will match.

Here’s how I do the same thing, but allowing me to set exceptions to the security rule, and to log what specifically triggered the rule:

SetEnvIfNoCase User-Agent (eirgrabber|emailcollector|emailsiphon|emailwolf) badUserAgent=$1

For User-Agent values that have multiple values (the | separates them) and that contain special characters, you must use substitutions:
\s for spaces, \. for period, @ : ! are permitted
For this User-Agent: Bot mailto:craftbot@yahoo.com use this in your .htaccess: Bot\smailto:craftbot@yahoo\.com

Then I send bad user agent requests to a page this way:

RewriteCond %{REQUEST_URI} !/shared/bad-webbot.php$ [NC]
RewriteCond %{REQUEST_URI} !/shared/403.php$ [NC]
RewriteRule (.*) /shared/bad-webbot\.php [E=badUserAgent:%0,L]

First I check that the file being requested isn’t one of  my “error” pages. The user agent doesn’t change when I redirect to an error page, so if I don’t make an exception for my error page, the server has a security conflict (you told me to display this page with that security rule, but the page violates the security rule) and gives up by showing a bare “500: Server Error”.  Then I redirect the requested file to my “you’re a nuisance” page.

The E=badUserAgent:%0 sets an environment variable that my bad-webbot.php page can read.

The ,L says this is the Last thing to check in .htaccess, go right to the page.

My bad-webbot.php just displays minimal HTML, with no style sheet. But it also logs the IP address and what makes me think they’re a nuisance, in this case which phrase in their user agent triggered the security script. If something is being blocked incorrectly, I can see it in the log.

One exception I found for user agents was for LinkedIn. “Jakarta” is one of the agents suggested for blocking, but LinkedIn uses this user agent. Another I made an exception for is Alexa.

LinkedInBot/1.0 (compatible; Mozilla/5.0; Jakarta Commons-HttpClient/3.1 +http://www.linkedin.com)

Here’s how I made the exceptions:

SetEnvIfNoCase User-Agent ia_archiver\ \(+http://www\.alexa\.com\/site\/help\/webmasters;\ crawler@alexa\.com) !badUserAgent
SetEnvIfNoCase User-Agent LinkedInBot/1\.0\ \(compatible;\ Mozilla/5\.0;\ Jakarta\ Commons-HttpClient/3\.1\ +http://www\.linkedin\.com) !badUserAgent

Notice how I put a backslash before all spaces, periods and slashes inside the user agent string.

The ! before the variable (badUserAgent) un-sets the environment variable.

Don’t Use HideMyWP

Quick look: HideMyWp changes the URLs (“Change WordPress permalinks” and the URLs for plugins and administrative pages). Whoop-tee-doo.

Hackers getting in from server-level security breaches don’t use a URL, they are already inside the security system.

Hackers from bad plugins know the internal location they are run from (a necessary PHP function), and easily get the location of all other plugins, with a single database query; they’re already inside the security system.

HideMyWP thinks that’s “good security”. The site says, “This means you can install unsafe plugins without worry about security.” — they are lying or incompetent. An unsafe plugin can change the content of your post/pages/comments, ruin your database, install malware, collect your user names and passwords, send out emails, etc. Continue reading

Checking if Plugins Pass Basic “Good Programming” Test

On http://wordpress.org/ideas/topic/plugins-and-theme-repository-thorough-bug-update-and-security-review/ there is discussion about adding to WordPress a “system of testing and making sure that plugins and themes work, are up to date (no plugins over a year old, say) and are bulletproof secure. The plugin and theme repository should demand that every single plugin and theme should be rigorously reviewed and screened for security.”

My suggestions for a Partial solution, that could Easily be checked for by the Plugin repository and by the WordPress Core:

1) /wp-admin/network/plugins.php shows if are using the latest version of each plugin. But it doesn’t indicate the Date of the latest version, or if the latest version date is a long time ago. Adding the date would be extremely easy.

2) On plugins.php display the version of WordPress the plugin was written for, just like the plugin repository page does. Display the user rating from the repository, for your installed version of WordPress with your installed version of the plugin.

3) Plugin repository could list results of installing the plugin in a default configuration, with full error reporting on, testing for a) syntax errors, b) obsolete function calls, c) database errors, d) direct MySQL calls (e.g. bypassing WordPress security and roles), e) multi-site initialization errors (e.g. are tables created for the plugin when create a site? Does the plugin put data in wp_options or in wp_SITEID_options? ).

The test site would be restored to default state after each plugin test. The test would be run at each plugin update posted to the repository. This sounds like something that could be easily automated.

Not a guaranteed security or quality test, but a good check of the basics.

@Ipstenu replied “We have yet to manage to do it in a way that didn’t net a bajillion false positives that we have to look at them all manually anyway :/ ”

Nope. Purely objective reports.

Have PHP error logging set to maximum, use software to count each category of error, report the findings. Already includes obsolete WordPress functions, obsolete PHP functions, syntax errors, mismatched variable types, uninitialized variables, and more.

Look for occurrences of the most common MySQL function calls (instead of WordPress database functions), report the number.

Get a list of tables after adding a new site (single MySQL query). Software subtract the list of tables started with. Report the difference (or maybe a little more secure, the # tables).

Another test: Any plugin using wp_ instead of the actual table prefix, isn’t programmed well.

Similarly, # rows in [tableprefix]_options before and after (shouldn’t change, plugins should use [tableprefix]_[siteid]_options).

Show the whole list in a new tab in the Repository, for each version, and watch plugin authors clean up their act!

Check Plugins are Multi-Site Compatible

As a WordPress Multi-Site administrator, make sure a plugin works with multi-site before installing it. Plugin authors should state if the plugin works with multi-site.

Testing is best done on a separate installation of WordPress (the one good reason for having multiple WordPress installations), so if there is a problem it doesn’t affect your production site.

Plugin Authors: If you have tested the plugin with multi-site, then claim the feature in your marketing. I would not use a plugin that doesn’t say it works on multi-site, since even though I am technically qualified to do that testing it is much too much work to have to do.

Does the plugin always request the table prefix from WP? (One immediate clue is a plugin that uses ‘wp_’, the default, even though that isn’t what you used when installing WordPress; then WordPress appends the site ID to that prefix for all user data.)

Does the plugin always request the folder locations from WP? In multi-site mode, each site gets a unique file upload location.

Does each site of the multi-site get its own set of plugin tables, for plugin options and for user data?

When a plugin is activated on an existing site, are tables checked for, and created if needed? (Or do thousands of error messages about missing tables clutter the error log? Yuck!)

When the plugin is network activated, and a new site is created, does the plugin activation work? Is there a reminder in administration panels, to configure the plugin for the site?

When a site is deleted, does the plugin deactivation work?

If the plugin creates file (for example, a podcast creating plugin would have the podcast episodes listed in a .xml file), does each site get a separate result file, or separate collection of files?

Improper multi-site use would assume the table prefix, or assume the folder locations, or use one set of plugin tables for all users, or use one folder for all user’s media files, or allow unauthorized people to include in their post or results some information from other users, or allow unauthorized people to modify someone else’s tables or files.

Plugin Author: State in the installation instructions or FAQ whether the plugin is safe to use in a multi-site installation. State whether the plugin can be network activated or must be activated on each site. State in the change log when multi-site features are added or fixed.

Configuring XAMPP for Multiple Web Sites

To use XAMPP for developing multiple web sites, specify a ‘host name’ for each web site to use. Each web site will have its own folder on your computer. Link a host name, to a folder with your web site files. Edit the web site files, view them on your web browser (skipping the normal FTP step for each change); when the page is working, publish it to the Internet.

You can define your own host names. Some people use .local for their naming convention (http://www.yourdomain.com on the Internet, http://www.yourdomain.local on your development computer). Or use local.yourdomain.com, which should be looked for on your computer before on the Internet. I like a simpler one, since I’m doing it only for me: yd.c (Yes, you can name it anything you want, on your own computer only). Two or three letter abbreviation, and .c, you’d be amazed how typing 4 characters instead of a long domain name, again and again, matters in developing and testing a web site.

You define “your own host name” in two places, one for XAMPP, one for Windows. Continue reading

IIS Servers Do Not Always Set Document Root

IIS servers doesn’t always set the PHP standard variable, $_SERVER['DOCUMENT_ROOT']

How do you set that in one place, your configuration file that you include in all your php programs, so the rest of your code has the document root set like on Apache servers?

Output $_SERVER to see what IS given that you might be able to use:

echo "<br>_SERVER:<br><code>";
print_r($_SERVER);
echo "</code><br><br>_ENV:<br><code>";
print_r($_ENV);
echo "</code><br><br>";

In this example, the SCRIPT_FILENAME and SCRIPT_NAME are set.

Modify the code below to use what is given to get DOCUMENT_ROOT:

if (!isset($_SERVER['DOCUMENT_ROOT']) || $_SERVER['DOCUMENT_ROOT'] === '') {
  $_SERVER['DOCUMENT_ROOT'] = substr($_SERVER['SCRIPT_FILENAME'], 0, -strlen($_SERVER['SCRIPT_NAME']));
  putenv('DOCUMENT_ROOT='.$_SERVER['DOCUMENT_ROOT']);
}

Now you can use $_SERVER['DOCUMENT_ROOT'] normally:

$docroot = getenv("DOCUMENT_ROOT"); 
include_once "$docroot/folder/yourfile.php";

Should Big Banks be Split?

I support businesses making profits, growing the business, employing people, making the owners money. But bad decisions in business have consequences. Huge bad decisions in huge businesses should have huge consequences.

Banks used to be valued based on the value of the loans they held. The laws were changed, so banks are valued based on the value of the collateral for the loans. A drop in housing prices of a few percent, which happens regularly, now meant that banks with highly leveraged mortgage loans could be bankrupt — a 3% drop in housing prices in a bank lending 33 times more than the cash they had, is bankrupt in the new accounting. (Insurance companies invested essentially identically to banks, but are still valued based on the loan amounts, and insurance companies didn’t fail.)

The big banks say they didn’t know that changes in how their business was valued meant their investments were at such risk — they therefore acted recklessly (ignoring the changed financial environment, ignoring potential consequences to their business), or they did know and acted deliberately, harming millions of people.

(The laws probably should be changed, so a normal or unusual change in housing prices doesn’t bankrupt a bank, if the bank loaned money responsibly.)

We couldn’t allow the economy to crash, from their reckless or harmful actions. We should penalize the people responsible for the harm their actions caused — strong enough penalty to fit the harm they caused.

Big banks are continuing to risk the same way they did before the financial crash. They now clearly know the potential consequences to the national/global economy. They obviously need to learn the risk to their own financial health.

The risk to the national economy didn’t dissuade the industry leaders from investing in ways that could ruin the company. The risk to their shareholders didn’t dissuade them. The small chance of personal financial ruin didn’t stop them from going for the huge probability of huge financial gain.

If low risk of personal bankruptcy if their business failed, didn’t dissuade them, we have to make the consequences more likely and more severe, and we have to make the benefits lower. We can’t allow them to crash the economy again.

There are benefits of big banks, including people feel more comfortable putting their money in a well-known bank. Big banks can make bigger loans, for growing large businesses, for huge important projects. But they have to run the business so they can handle mistakes, failures, bad loans, changes in the economy.

There is a petition you can sign, if you think banks should be split: http://petitions.moveon.org/sign/action-tell-obama-to/

Using PHP Packages without Composer

Composer http://getcomposer.org/ is a “Dependency Manager for PHP”.

If you do not have Apache command line access, like most people using a shared hosting account, instructions for installing a PHP package with Composer won’t work (at least not using the instructions given):

The preferred method of installation is [composer](http://getcomposer.org/). In your project root (not web root), create a minimum [composer.json](http://packagist.org/) file:
{
"require": {
"VerticalTab/Pillow": "x.x.x"
}
}
Replace "x.x.x" above with the tag number you want to use.

Next, get composer and use it to install (again, in your project root)
$ wget http://getcomposer.org/composer.phar
$ php composer.phar install
This will put the library into your vendors directory.

Then you would use this line of code in your program to access the package:
require 'vendor/autoload.php';

Well, you don’t need Composer to install this package, you can insert some standard PHP code that works, into your program. (But you won’t have all the version checking that Composer does.)

This PHP code replaces the autoload.php:
function __autoload($class_name) {
require_once("./$class_name.php");
}

The package I am using as an example is a Zillow API package, in the VerticalTab folder, inside the current folder, and contains these files:
/VerticalTab/Pillow/Chart.php
/VerticalTab/Pillow/Comps.php
/VerticalTab/Pillow/Date.php
/VerticalTab/Pillow/HttpClient.php
/VerticalTab/Pillow/Links.php
/VerticalTab/Pillow/Property.php
/VerticalTab/Pillow/Proxy.php
/VerticalTab/Pillow/Range.php
/VerticalTab/Pillow/ResultSet.php
/VerticalTab/Pillow/SearchResults.php
/VerticalTab/Pillow/Service.php
/VerticalTab/Pillow/Xml.php
/VerticalTab/Pillow/Zestimate.php

List all the package’s .PHP files using a special syntax. Convert the names like below. The backslashes are required; forward slashes are incorrect syntax. Drop the .php extension

use VerticalTab\Pillow\Chart;
use VerticalTab\Pillow\Comps;
use VerticalTab\Pillow\Date;
use VerticalTab\Pillow\HttpClient;
use VerticalTab\Pillow\Links;
use VerticalTab\Pillow\Property;
use VerticalTab\Pillow\Proxy;
use VerticalTab\Pillow\Range;
use VerticalTab\Pillow\ResultSet;
use VerticalTab\Pillow\SearchResults;
use VerticalTab\Pillow\Service;
use VerticalTab\Pillow\Xml;
use VerticalTab\Pillow\Zestimate;

Now all the package code is accessible to your program.

Inside the package are namespace commands, e.g. VerticalTab/Pillow/SearchResults.php has namespace VerticalTab\Pillow;

PHP Unzip bug makes WordPress Updates hang

I have been having problems with WordPress Updates for a while. No error messages, just the WordPress Update, or WordPress Plugin Update, hangs.

Then I found out that the WordPress backup plugin I am using, BackWPUp, failed if I configured it to use any compression.

Then I found out that the problems I had been having with random-seeming 500 Server Errors was from the WP-Super-Cache plugin configured with, hmm, compression.

WordPress Updates would create new folders, but no files in them.

I wrote a PHP program, outside of WordPress, to test if the problem was in WordPress, or in the version of PHP used on my server.

The problem is in PHP. The PHP unzip routines lock up. No error message on screen, in the PHP log, or in the system log.

WordPress 3.6.0 and 3.6.1, Multi-Site, Apache, PHP Version 5.2.17, [HTTP_ACCEPT_ENCODING] => gzip, deflate

PHP itself has a bug in Zip/Unzip in old versions. Hangs without any error message displayed or in logs. Affects WordPress Update, and Plugin/Theme Updates, and any plugins that use compression (e.g. WP-Super-Cache or BackWPup)

PHP Change Log http://www.php.net/ChangeLog-5.php#5.3.4 says
PHP Version 5.3.4 released 09-Dec-2010 – Fixed crash in zip extract method

Note: PHP versions are numbered so version 5.3.10 is higher than 5.3.9 (5.3.1 is lower)

Continue reading

XAMPP “Limit Not Allowed” in .htaccess

Quick Version:
In \xampp\apache\conf\httpd.conf
Find each occurrence of AllowOverride None
Change it to AllowOverride All

In \xampp\apache\conf\extra\httpd-vhosts.conf
Make the same change.

How I Have XAMPP Set Up

I have XAMPP, a full Apache web server for Windows, installed on my computer. Lets me develop and test web sites where only I can see my mistakes, then upload a working page to the Internet.

I have my web site files on a USB drive, so if I need to I can easily take it with me.

I have XAMPP Portable installed on that USB drive (connect the drive to any Windows computer, my testing web server is ready to go). I also have NotePad++ Portable (HTML editor), Filezilla Portable (FTP), and Firefox Portable (browser) with Firebug plugin (lot of features, invaluable for adjusting CSS until looks right, browser updates as I make changes, then copy correct CSS into NotePad++); all the tools I need for modifying web sites on-the-go.

I have XAMPP also installed on my computer, as a Windows Service, configured to use the web pages on that USB drive. Why both? Because I am nuts. I mean, so I could teach you how to do it that way! There may be some performance advantages to using the non-portable version, and probably some security advantages to using the Windows Service. Knowing how, it certainly isn’t harder to use. And I’m telling you how.

Change Configuration to Allow .htaccess More Control

The error messages “Limit Not Allowed” or (Options, DirectoryIndex, IndexIgnore, see http://httpd.apache.org/docs/2.4/mod/core.html#allowoverride for full list) is a configuration issue.

XAMPP default installation is configured for you as a server administrator, with full control over your testing environment. (XAMPP says clearly the default is not configured for security needed in a production server, but for testing.)

I want to be able to test the .htaccess files I write, just like clients would have (and like I have) on shared hosting accounts. But the default configuration blocks changing some things in .htaccess, that are better configured in server configuration files if you have access to them. Continue reading