Hate In Religious Holiday Seasons

Note to self: check out the psychology of hate

Dec. 25, 2011
Bomb blasts targeting Christmas Day church services in two Nigerian cities have left at least 28 people dead, with three more attacks on other towns.
The Islamist group Boko Haram said it had attacked St Theresa's Church in Madalla, near the capital Abuja, killing 27 people.

Dec. 25, 2009
In the eastern Baghdad district of Sadr City, Iraqi officials say a roadside bomb blast killed six Shi'ite Muslim worshipers as they observed the solemn Ashura holiday.

Nov. 6, 2011
Three explosions occurred today, November 6, in a market in Baghdad, on the first day of Eid Al-Adha, a Muslim holiday commemorating Abraham’s willingness to sacrifice his son, reports Reuters. As stated by the Baghdad police and the staff of Al-Kindi Hospital, the blasts left at least eight dead and 26 wounded in the city’s central market of Shurja.

"Content Management" - Hard Problems

There are a number of "hard problems" in the context of Enterprise Content Management (ECM or just CM) and institutional information in general.

1. Treating Web content as something separate.
1. Makes extra work.
2. Creates errors and conflicts by having information in more than one place.
2. History and archiving
1. Archiving fixed artifacts is hard enough, but how do we keep long term history of all the information in all the systems of an organization?
1. Business systems
2. Phone calls and text messages
3. Email
4. Contact management
5. Office electronic documents
6. Web CM
7. Photos and videos
8. Printed documents
9. External systems
1. Social media
2. Chats
3. Search
1. Information and data is stored in multiple systems in multiple forms, from simple word processing documents to complex business systems. Currently nothing is capable of connecting them all in a useful way.
4. Formats
1. How can we possibly relate data, documents, pictures, audio and video in all the systems in an organization? It's being worked on with such things as facial recognition, media tagging, etc. But, we aren't there, yet.

Many enterprise software systems have a Web interface or are Web based entirely. That helps with problem #1, but, typically, not any of the others.

Popular "content management systems" have all of these problems. Wordpress, Drupal, et. al. are self-contained. Plugins often provide interfaces to other systems, but not to the point of searching all of them at once. Incorporating word processing and spreadsheet documents is usually clumsy or impossible. History and archiving are idiosyncratic, usually in the form of database exports with no standardized structure.

Does Global Warming Matter?

1. Assertion: Predicted sea level rise will wipe out most coastal cities around the globe. Find the evidence.

Why use Apache Server Side Includes (SSI) for Web scripting

• Simple
• Fast
• Flexible
• Secure (if configured properly)
• Low server load

Apache SSI (also called XSSI, extended server side includes) has several advantages over other server-side technologies:

Easy to learn

A small learning curve makes XSSI accessible to people with limited programming experience. XSSI is programmer-efficient because it requires very  little debugging.

Mature

Well-tested code and a stable API make future surprises unlikely.

Lightweight

XSSI can deliver popular features such as printer-friendly versions, article partitioning, and hierarchical menus without client-side scripting or a database back end. Maintenance becomes easier--and cheaper.

Efficient

Contrary to early-day warnings that XSSI would bog down a web server, XSSI is probably the most resource-efficient of all dynamic technologies. For example, according to the Apache Hello World Benchmarks (see XSSI Resources), mod_include, the base module implementing XSSI in Apache, can serve more Hello World pages per second than other dynamic content-generation technologies.

Secure

In particular, if you do not include the output of arbitrary web server executable programs. Also, content maintenance is at the file system level. Desktop html editors make that an advantage because Web-based CMS write  to the file system. That's the vector for CMS attacks. See below for a security discussion.

Ubiquitous

Present in virtually every Apache installations, because its implementation is a base module.

Complementary

Combined with web site templates, XSSI can decrease maintenance time and increase sitewide consistency. 

It is easy to integrate with client-side technologies, including cascaded style sheets, JavaScript, and other dynamic objects such as Flash and Java applets.

On the server side, it's integrated with Apache CGI (Apache's original way of programming Web pages). Thus it can be combined with any other programming language that supports stdin/stdout. CGI is language neutral. 

Desktop GUI html editors can include it by switching to html mode. Can even use an online editor like blogger.com and copy-paste the html.

Forward-looking

It can integrate with any text-based document, including XML and RSS.

Powerful

CGI has access to all programming languages, commands and scripts on the system including server side Javascript. It can get data, code, etc. from other servers. It can make database calls. There's practically no limit to what a programmer can do using CGI integrated with SSI.

Apache's eXtended Server Side Includes Onlamp.com, by Kostas Pentikousis 07/07/2005

 

But, is it secure? Various authors have challenged Apache SSI security. For example:

Protecting Web Servers from Security Holes in Server-Side Includes by Jared Karro, Jie Wang, Division of Computer Science, University of North Carolina at Greensboro, Greensboro, NC 27402, USA, Jared Karro@uncg.edu, wang@uncg.edu

All of the examples this paper sites are internal attacks. Controlling who can edit the Web site and what user Apache runs as completely negate the claimed problems.

Generally, when people talk about the security of a Web scripting language, they are referring to external attacks. No one will claim that a Web language is totally immune, but SSI has, historically, had the fewest issues of any Web programming language.

Other claimed vulnerabilities:

• Server-Side Includes (SSI) Injection
• The authors provide no explanation of how the injection is to be accomplished. Setting the file system permissions so the Web server can't write to it and turning off Exec permission, which are standard procedures for securing an Apache site, should eliminate any possibility of this working.
• Perhaps they are referring to using the query string as a variable in an SSI command. Programmers must be cautioned to never do this without checking the content of the query string.

So, what's wrong with it?

• Limited function in of itself compared to other Web languages, e.g. PHP. Using CGI, it can do anything the others can, but programmers may find breaking the work into two environments inconvenient.
• Requires understanding of stdin/stdout to use CGI.
• Programmers must pay attention to the data coming in to ensure it doesn't contain executable code. Best practice is to never execute any part of the parameters or form input. Some CGI libraries, e.g. in CPAN and MIT's cgic take care of this housekeeping.
• The biggest problem is lack of exposure. Most Web programmers don't know it exists.

Turning Apache SSI usage on its head.

Most people who talk about templating with Apache Server-side Includes scripting (SSI) have HTML pages pull in pieces of common code such as styles, headers, footers and so on, then hard code the content in the page. This technique certainly reduces the amount of code in each page. And, one can make some changes in a single place. In programming parlance, it modularizes the code. This approach has drawbacks, though.

• Depending on what is pulled in, changing the structure of all the pages in the site may mean editing many files.
• The content can't be presented in different ways for different purposes. It can't be reused.

So, what if we turn this concept on its head? What if the content calls the “page”, or more broadly the “template” rather than each page having content. What would that look like?

SSI can set variables. The variables can contain anything that is a string. The variables can be substituted for text just about anywhere, including in the URI in an SSI command.

What does that mean? It means that content can be put in a file that calls a “page” to display itself. The steps are:

1. Set one or more variables with content.
2. Call a template file, either a fixed one, or, and here's the beauty of it, one whose path is in a variable that was set before the content file was called.
3. The template file puts the content variables in the appropriate places.

Why go to this trouble? Because the template file that’s called can be different depending on the desired output. One time it can be a complete HTML page. Another time it can be an HTML fragment such as a paragraph or a list element. Another time it can be an RSS feed item. Another time it can be Javascript variables. The same content. Only the template changes.

What's more, one template can be used for many pages, potentially an entire site. So, if the site structure or style changes, only one file has to be modified.

In some sense, this turns SSI into an object-oriented system, bringing it into the modern era of system architecture. The variables are object attributes and the template file is the method. What's more, the method can be anything. Unlike most OO languages, it doesn't have to be hard coded. (Although it could be by using #if conditional processing to choose among a fixed set of methods.)

Regardless, the possible uses of this technique are limited only by one’s imagination. The output can be anything that is deliverable in response to a Web request, even JSON. And, it can be driven by parameters in the URL that called it. (Apache SSI has access to the query string.) RESTful services anyone?