Blackmoor Vituperative

I use MediaWiki for a few web sites (Warlords of NUM and WestGuard, for example). Unfortunately, some lowlife scum like to post spam about luxury watches or viagra or whatnot on these sites, so I need to lock them down to prevent this.

The simplest way to do this is to 1) disable anonymous editing, and 2) disable account creation by anyone other than a sysop (which is to say, me). The MediaWiki manual explains how to do this (and a great many other things), but I thought it might be help for folks if I posted just those specific instructions here, since I think this is a common request for those using MediaWiki.

Simply add the following lines to the end of LocalSettings.php with a text editor such as Notepad++ (do not use Windows Notepad — use a real text editor):

## Customized settings begin here

# Disable anonymous editing
$wgGroupPermissions[‘*’][‘edit’] = false;

# Hide user tools for anonymous (IP) visitors
$wgShowIPinHeader = false;

# Prevent new user registrations except by sysops
$wgGroupPermissions[‘*’][‘createaccount’] = false;

And that’s that. You will probably also want to add a custom “wiki.png” logo. If so, you should add the path to it, like so (you will, of course, need to upload it to your site first):

## Customized settings begin here

# Custom logo
$wgLogo = ‘http://www.mymediawikiwebsite.org/skins/mycustomskin/wiki.png’;

# Disable anonymous editing
$wgGroupPermissions[‘*’][‘edit’] = false;

# Hide user tools for anonymous (IP) visitors
$wgShowIPinHeader = false;

# Prevent new user registrations except by sysops
$wgGroupPermissions[‘*’][‘createaccount’] = false;

And there you go.

Adobe Systems has announced its plans to open-source its Flex Web development framework.

The San Jose, Calif., company is releasing its Adobe Flex source code to the open-source community to enable developers throughout the world to tap the capabilities of Flex and participate in the ongoing development of the technology.

Flex is a framework for building cross-operating system RIAs (rich Internet applications) for the Web and enabling new Adobe Apollo applications for the desktop, the company said.

“We’ll be open-sourcing Flex with the next release of the technology, which is code-named Moxie,” said Jeff Whatcott, vice president of product marketing in Adobe’s Enterprise and Developer Business Unit.

Whatcott said Adobe will introduce the first public pre-release version of “Moxie” in June, “and we’ll be providing public daily builds of the technology starting at that time. We’ll also be launching a public bug database, so it’ll look, act and feel like an open-source project” even then.

However, the technology will not be open-sourced until “Moxie” is released in the second half of 2007—most likely in the fall, Whatcott said.

Upon release, the open-source Flex software development kit (SDK) and documentation will be available under the MPL (Mozilla Public License), Whatcott said.

Using the MPL for open-sourcing Flex will allow full and free access to source code, and developers will be able to freely download, extend and contribute to the source code for the Flex compiler, components and application framework.

Adobe will also continue to make the Flex SDK and other Flex products available under their existing commercial licenses, allowing both new and existing partners and customers to choose the license terms that best suit their requirements.

Whatcott said the MPL “strikes a good balance” for developers, particularly those who want to take a staged approach to working with open-source technology.

“This is the culmination of a long path toward opening up Flex,” Whatcott said.

(from eWeek, Adobe Open-Source Move Sets Showdown with Microsoft)

I have it on good authority that Flex is going to be the Next Big Thing. If you like to stay abreast of web technology, this is the time to start gearing up with Flex.

Silverlight isn’t even an also-ran.

As the number of Web applications grows so does the number of vulnerabilities introduced. Failure to follow proper coding guidelines can expose an organization, its employees, and its customers to malicious attacks.

This is the first in a series of articles in which I explore the Open Web Application Security Project (OWASP) Top Ten and how the OWASP recommendations for dealing with the identified vulnerabilities can be integrated into your Software Development Lifecycle.

(from TechRepublic.com, Lock it down: Use the OWASP Top Ten to secure your Web applications — Part 1)

This is good stuff. Check it out.

Apart from the actual security provided by digital certificates in a Web environment, in terms of encryption of data and authentication of participants, they are meant to be a confidence-boosting measure.

That little lock icon in the browser and the “https” in the address tell the user that the communications are secure. Users can also click through some dialog boxes linked from the icon to see specifics of the certificates for the site they are viewing and make a decision about the authenticity of that site. Of course, 99% of users never do any such thing, and probably very few even notice the relatively obscure lock icon.

Even the value of the lock icon has been diminished lately. There have been recent examples of scammers obtaining a certain kind of SSL certificate, called a domain-authenticated SSL certificate, that can be obtained with very little in the way of verification of the bona fides of the applicant. Even if the user takes care to look for the lock symbol, he or she can be fooled by such a certificate.

A new standard hopes to address this situation with a new class of certificate. Some reports indicate that the final official name for these certificates will be “Extended Validation,” but they are more widely known as “High Assurance” SSL certificates.

(from IIS Zone, High Assurance SSL)

You’ve heard the Ivory soap slogan, “99 44/100 percent pure“. Until today you could say much the same about the Google Web Toolkit (GWT). While most of GWT was open source, a few important pieces were binary-only. Today that all changed as Google made the entire GWT 1.3 Release Candidate available, with source, under the Apache 2.0 license.

GWT was introduced 7 months ago as a radical new way to develop Ajax applications using an old familiar language – Java. It enables developers to use all their great Java tools and expertise to create “no-compromise” web applications.

(from ZDNet, Google Web Toolkit goes 100% open source)

In the first 10 years of professional web development, back in the early 1990s, browser support was binary: Do you — or don’t you — support a given browser? When the answer was “No”, user access to the site was often actively prevented. In the years following IE5’s release in 1998, professional web designers and developers have become accustomed to asking at the outset of any new undertaking, “Do I have to support Netscape 4.x browsers for this project?”

By contrast, in modern web development we must support all browsers. Choosing to exclude a segment of users is inappropriate, and, with a “Graded Browser Support” strategy, unnecessary.

Graded Browser Support offers two fundamental ideas:

* A broader and more reasonable definition of “support.”
* The notion of “grades” of support.

What Does “Support” Mean?

Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates a barrier to participation. Availability and accessibility of content should be our key priority.

(from Yahoo! UI Library: Graded Browser Support)

I particularly like this line:

“Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web.”

I have tried repeatedly to hammer that into the heads of various clients who Just Don’t Get It. It’s about the content.

The response time of a Web page is critical to an application being fully utilized since users will quickly navigate to another site when/if load times are unacceptable. In this article, Tony Patton examines ways to optimize Web applications.

Optimize Web applications with reduced page size

There is nothing earth-shattering in this article, but it offers good, solid advice.

The Department of Homeland Security redesigned its website over the weekend, and now all of the existing links to DHS documknts across the entire WWW are broken.

404 : Page can not be found
We recently redesigned our site and most pages have moved.

Here is a clue for would-be web designers out there. Never break hyperlinks.

Many novice Web developers use CSS positioning and layout directives without a sound understanding of how they really work. A brief introduction to the box model explains what it is and how you can use it to make better decisions about positioning your HTML elements on a Web page.

(from Tech Republic, Make better Web pages by understanding the CSS box model)

How often have you browsed to a Web site, only to encounter a blank page in your browser? This happens to me all the time. Other times, the Web page is missing entire sections — typically navigational elements — and I can’t browse around at all. And sometimes, though not always, the Web page notifies me that I need to install or enable a plug-in or change my browser’s settings in order to view and navigate the Web page properly.

Now, I’ll be the first to admit that I’m not a typical user, but by no means am I the only person who experiences these problems either — particularly since users are much more aware of Web browsing security concerns than they used to be. Depending on my mood and the Web site in question, I may spend some time attempting to adjust my Web browser settings.

But more often, when I encounter an improperly displaying Web site — especially those that require JavaScript, ActiveX controls, Java, or Macromedia Flash in order to work at all — I question whether it’s worth my time. And if a Web site “locks” me in, due to JavaScript code redirects, pop-up windows, or some other method to keep me from going back, I won’t even bother trying to make it work.

(from Tech Republic, Why interactive Web site features often conflict with security best practices)

I agree completely.