Schinckel.net

Nardac, a new Blogsome user, tried out my Page Templates hack, and asked the following question:

I’m having a hard time getting the pages to work. I think I’ve followed your instructions to a tee… but well… hmmm… can you take a look?
the page in question is http://nardac.blogsome.com/nardac/

I looked, and what is occurring is that his normal blog index page is appearing. So I tried the same with my blog: http://schinckel.net/schinckel/ - I know I don’t have a Page with this name, so I was interested to see what occurred. It too showed my index page. Looking down the bottom, I see the arguments that are passed to the server, and in this case, only the blog name is being sent (wpblog=schinckel). So, it seems that a page with the same name as the blog name cannot be used. I suspect this has something to do with the HTTP Rewrite Rules, but I’m not sure. I don’t see it as a big issue, anyway. Workaround: Don’t use your blog’s name as a Page name.

creativepro.com - Putting Your Best Blog Forward Smith Jackson, over on creativepro.com, has written a nice article on how and why to blog: it’s fairly heavily pointed towards Blogger, but there is a mention of Blogsome, and more importantly, my site is the example of a Blogsome blog linked to. I only noticed because of a referer hit, so, welcome to all of my new visitors who came from that direction! If you are keen on signing up with Blogsome, please do so. It costs nothing, but be sure to sign up in the Forums too, and have a look at some of the features (and caveats) of this service. I’m a very happy customer with Blogsome.

I thought I’d already written up a post on this, since I discovered it about a month ago, but apparently not. Blogsome has a nice little function called {is_asides}. It allows for easy alternate formatting of posts within a category called Asides. So, to have these fancy little numbers, the first thing you’ll need is an Asides category, with a post in it. Then, in your Post Template, try the following code: <div class="post {is_aside}{if $is_aside=='true'}Asides{/if}" id="post-{the_ID}"> This sets up the class of the post to also be Asides if it is in that category. I’ll make a note here that this could be done with any category, and just use {the_category seperator=" "}. This would allow alternate styling for any given category, but I wanted to use the {is_asides} Smarty function. That’s all of the code you need, the rest is just pure CSS. In my stylesheet, I have the following code, that looks after all of the Aside related stuff:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

    .Asides
    {
        border:#E1D6c6 1px dashed;
        padding:6px;
    }
    .Asides .post-info
    {
        display:none;
    }
    .Asides .post-footer
    {
        background:none;
        padding-top:0px;
    }
    .Asides .post-content
    {
        border-top:none;
        padding:2px;
        background: url(/images/blockquote.gif) no-repeat left top;
    }

The first stanza sets up the border and layout for the actual post. The second hides all of the post-info, such as Date, Title, etc. I later decided to move the Comments Link, else there is no way to view/add comments. The third removes the fancy symbol that appears between posts, and the last one removes the line at the top, and puts some lovely quotes into the background. I’m still going to tweak this a little: on an individual post page, the next/previous post links overlap with the bottom of the border.

Over on Neo Security Team, some guy whose Engrish is teh bom writes about supposed vulnerabilities within WordPress 2.0.1 and below. I’ll detail each of them, and how real I think they are. Firstly, all of them seem to be JavaScript related. That affects me, as I require JavaScript for commenting, which implies I want users to have JavaScript turned on. First potential issue:

’name’ variable is not filtered when it’s assigned to ‘value’ on the <input> in the form when the comment it’s posted.

I’ll assume he means that when the comment is posted. Let us test that. Nope, this is not true. When using the normal comment posting form (i.e. the individual post page) all fields are stripped of HTML, except the Comment field (see below). In fact, this problem is no more or less serious than number 2, below. It is the same problem! This problem also exists for URL field, and possibly email field (although this is generally not shown in a blog comment, as it’s a bit of a Spam magnet.

Second potential issue:

‘comment’, this variable only filtered " and ’ chars, this makes possible to use < and >, thus this permit an attacker to inject any HTML (or script) code that he/she want but without any " or ’ character, this only happends if the user that post the comment it’s the admin (any registered kind of ‘user’).

I’ve confirmed this, even though it’s not really clear what this person is saying. If you post a comment, then all <script> tags are stripped. However, if you edit a comment, you can insert HTML. I think this is what the author means. Short answer - don’t allow other users to register. That is an absolute fix. Casual commenters cannot cause this bug. In fact, this trick could be used to great effect: the script would be run by an admin trying to delete the comment, too! Again, the best way to avoid these issues is to not allow people to register as users, as they then would not be able to edit comments. Incidentally, the fixes they suggest would either not fix the problem, or in fact remove the ability to have any HTML in any comments. Since I want people to be able to style their own comments, this is not acceptable. WordPress already has some method of filtering out ’nasty’ HTML - lists, images and scripts are not allowed in comments, for instance. Surely these same filters can be used when an admin edits a comment, too? A much better solution!

Third issue:

Full path disclosure & Directory listing When I discovered this bug, I reported it to some pepople before public disclosure, I was noticed that this isn’t new and I decided to look why they haven’t patch this bug. As this bug it isn’t patched yet, I tryed to know why and I found something like this in their forum (I don’t know if the person that posted this was the admin but it gives the explanation): (Something like the following, it’s not textual). ‘… these bugs are caused by badly configured .ini file, it’s not a bug generated by the script so it cannot be accepted as a bug of WordPress…’. This is not an acceptable answer, if you think it is, a bug caused because of register_globals is Off it’s .ini fault and not the script, they have to be kidding, if they want to make good software, they have to make as far as the language can, to prevent all bugs. There’re multiple files that don’t check if they are been call directly. This is a problem because they expect that functions that the script is going to be called to be declared. This kind of bug it’s taken as a Low Risk bug, but it can help to future attacks.

This took me ages to figure out what they meant - apparently files can be accessed directly if you know the URL. For instance: http://www.victim.com/wordpress/wp-includes/ Actually, this is more of an http rewrite issue - and as such, specifically does not affect Blogsome. And even if it did, I’m not really sure it could do much harm. I might be wrong about that, but I’m almost certain that Blogsome is immune to this, since every URL that Blogsome serves from each blog doesn’t directly access the source files, but goes through the database.

Chris Legend is using some files from my templates: mainly the guts of my Comments.html page. This is all well and good, but because I have customised the guts out of my site, there are some caveats. The first is that my Comments.html relies on a certain JavaScript to be called before it allows any Comments. That is, if you just use this file from my template, noone will be able to comment at all on your blog. I had to write this post, as I can’t find another way to let Chris know! To fix this, you either need to edit the template page, and put the following into the action field: "/wp-comments-post.php". If you don’t do this, no one can comment on your blog.

Gravatars are now working well on Blogsome: {$comment->comment_author_email|gravatar:"default":"size":"rating":"border"} This needs to be inside the {foreach} inside comments.html in your template. For example, to use no default image, and limit the size to 40x40 pixels, you’d use: {$comment->comment_author_email|gravatar:"":"40":"":""} Notice the double quotes where the argument is missing, and that (in this version) you actually need to include all of the arguments. This may be fixed at some stage.

One of the most common issues we see on the Blogsome Forums is when a user tries to post an article that has non-latin characters in the title. I found I had done this, with a recent post without realising this. What I propose is a change to the Blogsome code that either just strips out the extended characters, or replaces them by similar characters. It could convert any of the characters: à áâãäå into a, for instance, and æ into ae. For others, it could either convert ² into 2 or squared. I’m guessig a simple function could be rolled to do this, or even found out there already on the Internet.

For some reason, there is a small bug in the Quicktags.js script I contributed to Blogsome. That is, when putting in an abbr, or an acronym, only some Browsers will automatically add what the abbreviated term stands for (or what it might stand for). I coded in a series of common values, so that, for instance, if you have AAC selected, and press abbr, then it will put Advanced Audio Coding into the title field. It works with Firefox. It also works in Safari, but only if the User Agent is changed - older versions of Safari didn’t support Quicktags at all, so the authors of WordPress coded in a check, and the Quicktags don’t appear in Safari. I must fix the check in the Blogsome code, and submit it to Roger. It doesn’t work, however, with either Opera or Internet Explorer. Something to fix, later.

The Search Hilite plugin doesn’t seem to function under Blogsome. I’m not sure if it used to, but it may be possible to modify the stylesheet, or do something (maybe using JavaScript) to highlight search terms. We can get the referer information, after all, and should be able to process this and make a guess as to if it’s a search engine or not. Similarly, you cannot view Page 2 onwards of a site search: I’ll look into this (and highlighting search terms here too, BTW).

I’ve started the revamp of the Blogsome forums. I’ve decided to clear out the FAQ section, and only have questions in there that have an answer, or cannot be answered. General users are not to post problems they have there, but rather to use it as a great place to find information. Anyone who wants to help out can read FAQ Reorganisation, and start the work!