Plugins

rrichards from the forums published his first public OpenID-Plugin results. Check out this thread on the forums. If you're interested in testing the plugin or are interested in OpenID, please give it a look and report about it.

Many thanks to rrichards and all volunteers!

This new Serendipity release addresses a local file inclusion security issue discovered yesterday. It was possible to give a special parameter to a serendipity file to include a file on your own web-tree (or other files the webserver has read access to). If used on clear-text files, this could be used to disclose information like the apache logfiles on your website.

This error can only happen in a scenario with two prerequisites: Register_Globals needs to be turned on in your PHP configuration AND your webserver must ignore the default Serendipity .htaccess file. This .htaccess file usually prevents to directly call Serendipity's include files via HTTP. Thus we feel that only a very low percentage of installations should be affected by this bug.

However, Serendipity 1.0.4 is a recommended upgrade for everyone taking security responsibly, like we do. We are thankful to the community for inspecting Serendipity, searching for bugs and security issues and reporting them to us. In this case, many thanks to Majestic from the forums for notifying us.

Most of the plugins (both bundled and available via spartacus) were upgraded to also circumvent that bug, so you should upgrade all of your active plugins to the recent versions as well.

The Serendipity 1.1 release tree was also modified with a patch for this issue. It will be contained in todays snapshot, and the 1.1-beta6 release file. The easy steps to perform an upgrade are documented in our FAQ on http://www.s9y.org/.

Thanks to Robert from the forums he convinced me to implement a feature for him. Well, actually he bribed me to do it. ;-)

Nevertheless, now that I implemented the feature, I kinda like it. The enhancement to the Freetag plugin (version 2.7, should be available via Spartacus now) allows you to enter a list of comma seperated keywords for each tag you have available on your blog.

Whenever you save an article now, the plugin will analyze the content of your entry. For each keyword that you entered and that is found in the article, the corresponding tag will be auotmatically assigned to your entry (taking care that no duplicate tags happen).

So, if you have the Tag "PHP" you could enter keywords like "Serendipity,php,s9y,phpbb,xss,sesser". When you now create an entry where you use the keyword "Serendipity", the freetag plugin will automatically assign the tag "PHP" to this entry.

Thus, especially if you have a low count of tags you can save a lot of time by assigning meaningful keywords to your tags. Beware that if you enter a lot of keywords for a lot of tags, that this might slow down saving an entry. This happens because a list of EVERY available keyword needs to be compiled and matched against your saved article to be able to see which keywords were used.

Have fun!

Google seems to have changed their URLs where pings to the sitemap webmaster helper tool are sent to.

Thus, the Serendipity Google Sitemap plugin requires you to either manually update to the right URL. The updated plugin in Spartacus has been committed today and should be available tomorrow.

The new URL to use is: http://www.google.com/webmasters/tools/ping?sitemap=%s (see this thread)

I've committed a new plugin to Spartacus that allows users to use a very simply Notification System.

Users can create text (HTML formatting configurable) that will appear on the Admin Backend. A small goodie is a feature that notifications are subject to specific usergroups - only the usergroups for which the creator intentionally posted the message will see it.

The plugin also allows to configure whether normal users are allowed to use the messaging system. In the future this could be enhanced for more granular control, but for the time being it should proove a nice tool. The display of the messages can be controlled via a bundled notes.css CSS file.

CSS formatting also allows to format new incoming messages differently. Now try it out and have fun

Despite my downtime, I was able to find the time to commit some changes I was having up my sleeve to the 1.1 beta version.

It involves, what many people have asked for: Specify, which user/usergroups are able to have access to certain plugins. My standpoint until now was, that plugins should implement the versatile permission management of Serendipity, available since version 0.9.

However, reality got me when I saw that no plugin was really ported yet to use that permission management setup to provide custom permission sets. But people wanted to have the ability to say "The staticpage plugin is only available to user XY".

Thus, I implemented a rather hackish way into the groupmanagement: You can now specify complete plugins, or specific event hooks which are forbidden for a usergroup. This way, you can say that group X is not allowed to execute a 'Staticpage' plugin.

This approach should work quite well for many usage scenarios - the upside is, that all old plugins are supported instantly. However, the neater approach of course is to modify plugins so that they provide their own permissions for more granulate control of what you want to achieve.

To enable this functionality you must first enable the option "Enable Plugin ACL for usergroups" in the serendipity configuration. The reason why you must explicitly enable this is, because those plugin checks decrease the performance of the plugin API. Every executed plugin hook must be checked against the blacklist, and those checks would hurt bloggers that do not intent to use this feature. To satisfy everyone, you have an option for this.

You can try the feature in the nightly builds created today, or using an SVN checkout. The feature is contained in 1.1-beta4.