Skip to main content.

Tuesday, June 20, 2006

I was pointed to this reported "security issue" today, and wanted to say a quick word about this.

The report is invalid. None of the specified URLs are exploitable.

  1. action.php: has include('./config.php'); as first line. config.php defines $DIR_LIBS.
  2. media.php: same thing: included config.php first, via a fixed path.
  3. xmlrpc/server.php: again, the same: includes config.php via a fixed path.
  4. xmlrpc/ this one is just funny, since this file doesn't execute any code when called (it's included from elsewhere). The only thing it does is composing an array and defining a number of functions.

Including config.php as soon as possible, via a safe path, is crucial to Nucleus security: including config.php defines crucial variables (like DIR_LIBS) and bootstraps Nucleus (including security checks: that's why you'll receive a "Sorry, an error occurred" error message when trying these URLs)

The previous security issue, which led to the release of Nucleus v3.23, was possible because PLUGINADMIN.php has no reliable way of knowing where it is executing, and therefor cannot include config.php in a safe way. Instead, this file is included from plugin admin areas, which include the config file first. Should have called the file, actually.

Anyway, there's no need to worry about this report. You're only vulnarable to it if you've got an empty config.php file, and in that case, your site won't function anyway. As far as I know, Nucleus v3.23 is safe to use.

Thursday, March 09, 2006

You might have noticed that all of the sites have been down for quite a long time today. Here's a quick update of what was/is wrong: we're using too much MySQL resources. The hosting provider pointed to the Japanese forum and Skins site archive as the reason for disabling the site.

Short term solution was to disable these two parts of the site. An upgrade to another hosting plan has also been started. Once complete, we'll re-enable the temporarily disabled sections.

Saturday, February 18, 2006

Since I don't use document editors, spreadsheets or presentation software very often, I decided to install the 'free' OpenOffice 2.0 suite instead of Microsoft Office (which would cost me way too much compared to how much I'd use it). Actually, I've had OpenOffice installed for quite some time now, and it neatly opens any ppt or xls files.

Lately, I started creating some actual documents: spreadsheets. That worked fine. Hurray! The utter user-unfriendlyness (mainly when editing charts), didn't really bother me. Hey! It's free.

Next task: setting up a small database with OpenOffice Base... My first attempts to create tables with some inter-table relationships eventually resulted in an OpenOffice crash, which rendered the entire database file unusable. That's like... a bummer.

It took a couple of days before I got my courage back and started over. One single table with some views and forms this time. No fancy options. During the next week, I entered some data.

Today, after adding an extra boolean field in the main table: BOOM! OpenOffice started spitting out SQL errors. I couldn't even access the table in question. Bye Bye data!

Things like these make me slowly turning into a Microsoft fanboy. Really. Putting the user in control rather than the software.

Sunday, January 22, 2006

The deadline for Nucleus CMS Skin Design Contest submissions is getting closer (JanuaryJune 30th). If you haven't started on a design yet, the time to do so is now :)

Nucleus CMS Skin Design Contest

Lately, Moraes and others have been doing a lot of work on a new & improved admin area. In the CVS repository, a new branch has been created for this. Quoting Moraes:

Ok, the Branch-NewAdminArea was created. These files and the libs directory were branched:


For information on previous tags and branches, see the archive for the CVS category.

Tuesday, January 17, 2006

A while ago, I wrote about Internet Explorer security zones and dynamically created elements. Until such an element was attached to an existing document, all operations on that element were executed in the zone corresponding with about:blank.

I ran into a similar situation while making changes to automatically activate an ActiveX control.

Monday, January 09, 2006

It's a simple enough question, which you should try to solve in your head: What does the following code display, and why?

  $i = 1;
  $i += $i++ + ++$i;
  echo 'i=', $i;

Bonus question: Is the result always the same in other programming languages (JavaScript, Java, C#, ...; provided the syntax is adapted to the host language :))? Why (not)?

Tuesday, December 06, 2005

If you weren't aware of the Nucleus CMS Skin Design Contest yet, you are now.

Nucleus CMS Skin Design Contest

Check it out!

Sunday, December 04, 2005

I'm not such a stats freak. But when Google unleashed Google Analytic some weeks ago, I installed it on the main site. Some interesting findings are collected in this post.

Thursday, November 24, 2005

Captcha images are quite effective at halting comment spam. However, besides being inherently inaccessible, they're also quite annoying to regular users.

How to maintain a spam-free site, without annoying your users? That's the question.

Wednesday, October 26, 2005

Recently, I discovered something some interesting things about Internet Explorer:

When assigning some HTML to the innerHTML property of a DOM element, Internet Explorer performs some security text, especially if the inserted HTML contains javascript (e.g. <a href="..." onclick="javascript code">...).

If you create elements dynamically (e.g. var e = document.createElement('p');) and assign something to innerHTML before appending the created element to the DOM tree, Internet Explorer performs its security text in the zone to which about:blank belongs.

Saturday, October 01, 2005

On, you can track which movies of the IMDb top 250 list you've seen. It's currently open for all in a closed beta width invites, of which I have 4 left to share. Send me your mail address and name, and I'll see what I can do for you.

By the way, was developed by Tim Broddin, which you might remember from the Nucleus Support Forum as JefPober or Sir_Psycho.

Sunday, September 25, 2005

NAJAX is a PHP Ajax framework. Not only does it look easy to use, it also appears to have well-written and well-documented code.

One of the examples is a PHP Exam. I managed to score only 7 out of 12. A list of my errors in in the extended section of this article.

Recent PHP versions offer a mysqli extension instead of the old mysql extension. Since Nucleus relies on the mysql_xxxx functions, it won't run when those are unavailable.

A database abstraction layer would be the ideal solution, but will take a long time to implement correctly and break most of the currently available plugins. Luckily, there is a workaround which works rather well: defining fake mysql_ methods that delegate the work to the new mysqli_ methods. This way, you can keep running the Nucleus core and most plugins.

Update 2005-09-28: These changes made it into CVS

Tuesday, September 20, 2005

After discovering about the debug_backtrace function (PHP >= 4.3.0); I was thinking about how wonderful it would be to attach a customized error handler to Nucleus when running in debug mode. This handler could output a stacktrace, which would be much more helpful than a message a la "Tried to call a method on a non-object at code.php line x" when this line of code is buried deep into the code.

Unfortunately -- as I discovered the hard way -- the error handler function that is passed to set_error_handler is never called for fatal errors. This behavior is listed in the manual, but I only bothered to read it carefully once things didn't quite work as expected. The reason why these fatal errors cannot be trapped is that the engine might not be in a stable state. Bummer. An extra class of errors (fatal unless trapped) would certainly be welcome.