Chryp is a GPL3′d, Tumblr-like blogging engine written in Php. It’s used by such sites as Cameron I/O, hinting that it’s at least marginally capable.

A very web2.0 tumblelog blogging tool. What is a tumblelog you ask?

Creating native Win32 applications in Php. Am I the only one who thinks this is really messed up? And I like Php …

Building a Weblog with PHP and MySQL. DIY weblogging, a good, motivated project if you need a reason to learn Php+MySQL.

Unix Weblog Hacks. Weblogging with /bin/sh … don’t try this at home kids.

It’s official, weblogging is now all the rage with the big-boys, both Microsoft and Sun have exposed their devs to the masses. The blogspace predates these recent enteries by some years, but I’m sure that the big boys will somehow claim that they were first.

I’m working on extending Textpattern with some scripts I developed for Blosxom. Textpattern is a Php-based weblogging tool, and my scripts are all Perl-based plugins and command-line utilities. I don’t really want to port the scripts to Php, so I decided to find a way to call Perl from Php.

In a few minutes of searching, I only found one Perl binding for Php. It isn’t considered stable, and it isn’t available from my web host (Dreamhost). I did find an answer in the Php manual, but a googling on the specific topic of calling Perl from Php came up dry. So I decided to make it a bit more obvious.

Pipe dreams

All of my scrips are simple text processors, so the inputs and outputs can be passed using the stdin/stdout pipes. Using both the input and output pipes of a process is a bit more than the standard Php exec functions can handle, so we’ll be using the proc function family. Nearly every language has a set of these functions (and that’s a good thing).

You can download the demo script here. The script will need to be executable, it needs the correct path to the Perl interpreter, and the log file folder needs to be writable by the web-server process.

The Perl script reads text from stdin, and replaces spaces with underscores. From Php, we can call the Perl script and manage the standard in, out, and error pipes. The example is slightly modified from the Php manual.

The basic process:

1. Define what to do with the process’s pipes. Notice that the error pipe is mapped to a log file (which is appended on each call).
2. Define some text to test with the Perl script.
3. Open the process, which is our Perl script. This will fail if the script can’t be found, or if it isn’t executable.
4. Write the test text to the input pipe of the Perl script.
5. Read the output of the Perl script.
6. Close the process. This is best done after all of the pipes are closed (otherwise it causes deadlock).

The PHP script:

< ?php
$handles = array(                             // 1
   0 => array("pipe", "r"),                   // stdin 
   1 => array("pipe", "w"),                   // stdout 
   2 => array("file", "test-errors.txt", "a") // stderr 
);  
$test_text = "This is a test";
    
$process = proc_open("./test.pl", $handles, $pipes);
if (is_resource($process)) {
    fwrite($pipes[0], "$test_text");
    fclose($pipes[0]);    
    while (!feof($pipes[1])) {
        $output .= fgets($pipes[1], 1024);
    }
    fclose($pipes[1]);    
    $r = proc_close($process);    
    echo "Before: $test_text<br />";
    echo "After : $outputn<br />";
}
?>

And the perl script:

#!/usr/local/bin/perl

# replace spaces with _s in stdin
while(<>) {
    s/ /_/g;
    print;
}

I’ve been struggling with how to approach authentication for bender’s interface. The main problem is that the agents use transports that aren’t condusive to authentication (like IRC). As well, the eventing back-end doesn’t really allow for a coupled authenticated/encrypted layer (like SSH), as the framework doesn’t easily allow for session management.

As with any feature, it is worth understaning why it is needed. What is the underlying purpose of authentication? It’s funny what happens when you slice and dice requirements, the process tends to simplify and clarify.

How is authentication useful for a blogging system?

• Prevent graffiti or garbage content from being posted to the system.
• Prevent users from posting content posing as other users of the system.
• Prevent real damage to other users’ systems, or the hosting systems by disallowing any sort of viral or trojan code from being passed through the system.
• Prevent database damage to the hosting system(s) by disallowing most users from access to administrative tools or exploits that would allow damage to be done.

The only scenario that requires any authentication-based security is the administrative functionality, which simplifies the problem greatly. Now, the user-agents can be designed for ease-of-use (and not session management).

Based on this line of thought, the agents will accept content from users without challanging for credentials. The back-end will apply heuristics to validate the content and user, similar to bayesian filtering as used in Mozilla mail. The posted content will be further scrutinized to filter known server/browser exploits. All that remains is to authenticate sessions for access to the administrative tools, a subset of the overall functionality.

The really nice thing about understanding how and where security is needed is that it allows the user-interactions to be improved. Now users of the bender-blogging system will not have to login to submit posts. A simple optimisation, but one that has proved (so far) to be an incredible improvement in usability.