dougv.com « Doug Vanderweide

There are a number of handy tools every PHP programmer needs in his toolbox, and among them is a strong password generator.

This is especially true if you are programming membership-based Web sites, and you either want to generate initially strong passwords to hand out to end users, or you don’t want to give your end users the ability to provide their own passwords, which tend to be inherently insecure. (No, it’s not a strong password if you obfuscate your child’s name by capitalizing the first letter.)

We’ll create a function called generatePassword() that will take four arguments, each optional: The length of the password, plus the number of capitals, numbers and symbols it should have.

If no parameters are given, the function will return 8 random lower-case letters. The function will also test its attributes to see if too many capitals, numbers or symbols are requested; if so, the function will return Boolean false and raise a PHP warning error.

Let’s take a look at the function, and then I’ll point out things of interest. FYI, this function should work for PHP versions 4.x and 5.x.

Continue reading: A Strong Password Generator Written In PHP »

It’s no mystery to anyone who’s been on Facebook for more than a week that one of its biggest boons — and, in the finest Zen tradition, one of its most nagging banes — is the plethora of third-party applications that leverage its data.

Virtually all the value in Facebook is crowdsourced — that is, users generate all the content, they create all the connections, they drive interest in whatever direction it may flow, they create scores of memes every hour.

Since Facebook’s primary business model is driven by collecting data about usage, this means that opening its use to the creators of new social media tools makes tremendous success.

Why bother taking Microsoft’s old-school tack — create a standard, then ride it into the grave — when, instead, you can provide users, and let others give them reasons to stick with you? Why bother even taking Google’s approach — create lots and lots of things, in the hope one of them proves popular — when someone else can assume all the risk, presenting you with the opportunity to buy or duplicate his success with your framework?

How many people, do you suppose, would have stopped using Facebook after a few days, had it not been for Mafia Wars, Farmville or Bejeweled? That’s my point.

But every day, there’s also a new crop of the outright obnoxious third-party applications that promise to do the exact opposite: Drive users out for fear of their privacy and security.

Take, for example, the recent spate of “see who’s stalking your profile” applications. As The Register notes, all of them are at best cash-for-clicks scams; at worse, open invitations to load malware onto the computers of tens of thousands of unsophisticated users.

I’d like to expand upon a central tenet of a blog post offered by Rik Furguson of Trend Micro, from which The Register drew its article: That it’s high time Facebook employed some sort of vetting process for third-party applications.

Continue reading: It’s Time For Facebook – Or, At Least, Someone – To Vet Third-Party Applications »

A common challenge when working with ASP.NET master pages is how to dynamically add JavaScript that is relevant to a specific child page.

In other words, maybe your site has 10 child pages that share one master page / template. One of them is, let’s say, a contact us / directions page, and on that page, you want to display a map from one of the many mapping APIs out on the Web; for simplicity’s sake, let’s use the Google Maps API.

Proper implementation of the Google Maps API requires you to call, in the head section of your page’s HTML, the API library. So, you’re left with four options:

1. Import the library in the master page’s code for all child pages, and thus incur that overhead for every page using that master page / template;
2. Create a second version of the master page, containing the code, and apply that master to the child page that needs it;
3. Don’t use a master page for the page that needs the API; have that erstwhile “child” page contain all the HTML it needs; or
4. Figure out a way to add the needed code to the head of the master page for the child that needs it.

Option 1 seems reasonable, but it’s messy; although simply bringing in the Google Maps API for every page isn’t resource-intensive in this strong-computer, fast-bandwidth world, it’s sloppy at best and a potential security risk at worst (although the Google Maps API is pretty much safe to import, even if you’re not going to use it).

Option 2 leaves you with what is fundamentally two versions of the same thing, which is pretty much the dictionary definition of “inelegant.” Option 3 isn’t any better.

Option 4 is the best approach, and thankfully, there are a couple of ways to do it in ASP.NET. I’m going to describe the way to do it by dynamically adding HTML elements to the master page’s head, but first, a quick digression on using a PlaceHolder control.

Continue reading: Dynamically Adding JavaScript To Your ASP.NET Master Page From A Child Page »

One of the greatest contributors to the WordPress plugins repository is Lester “GaMerZ” Chan.

It’s testament to the value of his contributions that his work has not only been duplicated, borrowed and built upon by hundreds of other plugin developers — just search “gamerz” in the WordPress plugins repository to see how many times his name is cited — but many of his ideas and hacks have made their way into the core functionality of WordPress.

I use two of Gamerz’s plugins: WP-PostViews and WP-PluginsUsed. (Until recently, I also used WP-PostRatings, but that was not a popular feature, so I turned it off.) I like them both, but I had concerns about the security of using WP-PluginsUsed.

My concern was not WP-PluginsUsed itself, but the fact that it reported the version numbers of other plugins. Just telling the world that I am using a plugin is bad enough; reporting the specific version number, making it even easier on crackers, seems pointless.

But I believe in giving credit where credit is due, even at the risk of someone trying to exploit this site. I can always deactivate any plugin that has a major security hole. Besides, what plugins one is using generally isn’t difficult to figure out; there tends to be a handful available for any given task, and the ones that work well are often few and far between. You can pretty much just look at a WordPress blog and get a good feel for what plugins it is running.

That said, to keep my peace of mind, I simply commented out the part of WP-PluginsUsed that reveals version numbers.

You can do that either in the plugin editor that’s built into WordPress, or your favorite text editor. Look for the get_plugingsused_data() function, around Line 46:

### Function: WordPress Get Plugin Data
function get_pluginsused_data($plugin_file) {
	$plugin_data = implode('', file($plugin_file));
	preg_match("|Plugin Name:(.*)|i", $plugin_data, $plugin_name);
	preg_match("|Plugin URI:(.*)|i", $plugin_data, $plugin_uri);
	preg_match("|Description:(.*)|i", $plugin_data, $description);
	preg_match("|Author:(.*)|i", $plugin_data, $author_name);
	preg_match("|Author URI:(.*)|i", $plugin_data, $author_uri);
	if (preg_match("|Version:(.*)|i", $plugin_data, $version)) {
		$version = trim($version[1]);
	} else {
		$version = '';
	}
	$plugin_name = trim($plugin_name[1]);
	$plugin_uri = trim($plugin_uri[1]);
	$description = wptexturize(trim($description[1]));
	$author = trim($author_name[1]);
	$author_uri = trim($author_uri[1]);
	return array('Plugin_Name' => $plugin_name, 'Plugin_URI' => $plugin_uri, 'Description' => $description, 'Author' => $author, 'Author_URI' => $author_uri, 'Version' => $version);
}

We’re going to edit the last line of that function, the one that says “return array( … ).” Here’s the replacement line:

	return array('Plugin_Name' => $plugin_name, 'Plugin_URI' => $plugin_uri, 'Description' => $description, 'Author' => $author, 'Author_URI' => $author_uri, 'Version' => ''); //$version);

What this does is replace the version number for each plugin with an empty string; it has the same practical effect, through the rest of the plugin’s code, as never having reported the version of the plug-in.

Note that I also could have commented out lines 54, 55, 56 and 58, and left Line 64 intact. That, too, would have set the value of the version for each plugin to an empty string. I opted for the solution above because it is most elegant.

I distribute all code under the GNU GPL.

The MSDN Roadshow returns to Augusta, ME and the Central Maine Commerce Center’s Florian Auditorium on Sept. 24, from 1 p.m. – 6 p.m. (That’s a later start than recent roadshows, because directly before it, there’s a TechNet event about Windows 7 and Remote Desktop.)

MSDN Roadshows are a chance for Microsoft evangelists — namely, Chris Bowen and Jim O’Neil — to describe new technologies, demonstrate how to program in Microsoft languages and platforms, and generally share the word about what’s new and on Microsoft’s mind at the moment.

Among the issues to be discussed at this roadshow is Windows 7. Without question, Chris and Jim know their stuff, and you’ll definitely walk away from this event with a better knowledge of Microsoft technologies — if not some of the loot they give out at every event (fully-functional copies of Windows Vista, Visual Developer 2008 Professional, Microsoft Press books and peripherals having been offered in the past as door prizes).

Florian Auditorium and the Central Maine Commerce Center are in the former SCI Systems / Digital Equipment plant off Civic Center Drive. I have a public Google Map of the location.

If Augusta or the date are not convenient for you, Chris and Jim are doing the same agenda in Manchester, NH; Rochester, NY; Troy, NY; Waltham, MA and Farmington, MA. Chris Bowen details it all on his blog.