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.
Saturday, May 26, 2018
"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.
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.
- Treating Web content as something separate.
- Makes extra work.
- Creates errors and conflicts by having information in more than one place.
- History and archiving
- 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?
- Business systems
- Phone calls and text messages
- Contact management
- Office electronic documents
- Web CM
- Photos and videos
- Printed documents
- External systems
- Social media
- Chats
- Search
- 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.
- Formats
- 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.
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?
- 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
- 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:
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:
So, what's wrong with it?
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.eduAll 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.
- 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.
Tuesday, May 22, 2018
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.
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:
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?
- 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.
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:
- Set one or more variables with content.
- 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.
- The template file puts the content variables in the appropriate places.
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?
Subscribe to:
Posts (Atom)