Flux RSS des billets

DotMG's joblog

Work hard at whatever you do! (Ecc. 9. 10a)
La catégorie cms a 3 Billets
Publié le 6 Fév 2013, 7:45 am dans cms, html

Today I changed the configuration of this blog to dofollow. For my point of view, the web is a space of sharing and if a visitor adds a valuable comment to something like a blog, the least that the blog owner have to give in return as a gratification is an ounce of Googlejuice.

Nofollow attribute is, in my humble opinion, the worst way to discourage spammers. Except your satisfaction that the spammer didn't get any value in his activity,there is no other advantage. It doesn't discourage spammers and doesn't stop spams in your blog.

So, I am deactivating the nofollow attribute, and will monitor manually the comments. I will be removing comments which don't bring any value, especially those with an hyperlink. I am also planning to make a sort of blogspam.net proxy, to fight spam my way. This proxy will act as an URL blacklist checker, so I will be logging any domain mentioned in a spam comment and reject any further attempt to link to this domain. If the spam passes my check, then this module will forward checking to blogspam.net, before accepting the comment. A final manual review will be performed and possible spams will be deleted again.

Publié le 3 Fév 2013, 3:17 am dans cms, nginx

Yesterday I talked about installing WikkaWiki. I didn't mention it was about installing WikkaWiki on nginx. Wikkawiki is a CMS designed to function with Apache. Pretty URLS were achieved by using Apache's RewriteModule. Like for many other PHP CMS, URLs like http://example.com/wikka.php?wakka=HomePage are shortened like http://example.com/HomePage, so the Rewrite Engine translates /HomePage to /wikka.php?wakka=HomePage

Rewrite Rules can be translated into nginx statement configurations, and WikkaWiki Rewrite Rules are rather simple. The nginx rule is as simple as :

try_files $uri $uri/ @wikka;
location @wikka {
 rewrite (.*) /wikka.php?wakka=$1;
 fastcgi_pass 127.0.0.1:9000;
 fastcgi_index index.php;
 include /etc/nginx/fastcgi_params;
}

The try_files line is used to select rewriting only for non existent files. If file exists ($uri) or if we access a directory ($uri/), then they are served as is. In other words, resources like CSS, JS, Images, ... won't be redirected into wikka.php. However, if these conditions are not met (file doesn't exist), then location will fallback to @wikka, where rewriting happens.

The rewrite line is the actual rewriting rule. It's straightforward to understand. However, it is not sufficient because the try_files seems to short-circuit the execution of the page as PHP script, and without the fastcgi_pass, fastcgi_index and include below, the page just returns as an attachment to download. What you should do is to search in your nginx configuration how php files are executed. Search something like location ~ \.php$ { in your nginx configuration files, e.g. by grepping in /etc/nginx/. Copy everything inside the location php block into your location @wikka and restart nginx; that should do the trick. Don't forget to edit manually wikka.config.php and change rewrite_mode to '1'.

Another thing you must keep in mind is that with this trick, if the URI exists, it will not be rewritten. It is a slight difference with Apache where only some folders were specifically served without rewriting. If someone accesses http://example.com/wikka.config.php, this file will be executed. In Apache, it will be redirected to /wikka.php?wakka=wikka.config.php. In general, this is a non-issue, because with WikkaWiki, php files accessed directly don't do any harm, outputting a blank page in most cases. But it IS a security issue if you rely on RewriteEngine to forbid access to some sensitive directory. For example, if you allow visitors to upload files on your server, there is a risk that this file is served (or executed) by nginx.

Publié le 3 Oct 2012, 2:31 am dans cms, php

One reseller of webhosting at Dot.MG asked me to revamp one of her customer's website. The old webmaster seems to ignore anything about templating and dynamic pages, all files of the website were served statically. That's a good thing for my servers, but a very bad thing when it comes to touch something in his designs. We'll talk later about how I re-templated this installation.

This site had a bulletin board, which was hosted elsewhere, on free forum hosting, and integrated to his site with ugly <iframe>.

I had to install myself a discussion board, and, it's the first time in years that I had to play again with a bulletin board. Last time I've use one, PhpBB was the king of BBs. One of the forum I like is run by Vanilla and I went on their site to download one look for a download link. I was not looking to download the archive, rather looking for a download link, to copy the URL and use wget on the server. Actually, I feel very uncomfortable with downloading something to my PC and then uploading the file to my servers. I'm now used to get the tarball directly from my test server, doing the install there, and repeat the process on the production box when everything is okay.

But, VanillaForums didn't give a simple download link, the download was on a post form, so I was obviously obliged to use a browser and click the download button. I gave a last chance to Vanilla by passing --post-data to wget, but when this was also failing, I gave up and did a quick search for lightweight forum. Then I saw this stackoverflow discussion where I saw PunBB as one of the candidates. And yes, PunBB has usable download links. At my great surprise, PunBB has support for Sqlite, the installation was easy and straighforward.

And there are the reasons why I chose PunBB.