Latest Publications

Django on apache + mod_fastcgi

Today I was configuring apache(2) under mod_fastcgi to get my django project working on it. It was requested since the testing would go on a similar-to-deployment method.

So, I followed the guides at djangoproject but, as it seemed, I had some issues. Some were my own problem, some were not.
After fixing them, I decided to write a little “tutorial” to help other people perhaps having the same issues.

First things first

Before digging in to this tutorial, I advice trying to do the guidelines of django itself. In the end, if you follow as strictly as possible, it should work.
What will be discussed here will look very (and I mean very) similar to the guidelines of django, but with some notes on what I met on the process.

What is assumed?

During this, I’ll just simply assume you’ve got apache, and tested it to work (the way you installed it), I’m not going to explain how to install apache in any way, it’s useless, pointless, and there’s a whole bunch of tutorials covering it way better than I possibly could! GOOGLE it if you don’t have apache yet!

Step one.

So, as for the tutorial itself, we’re going to start of with running your django project in fcgi modus. As it is, the basic usage is very simple, and you can’t possibly go wrong in this.

Got from the official documentation:

./manage.py runfcgi [options]

Where [Options] is mandatory. The simplest way would be to use the socket option (as I’ll describe below), and a pid file is highly recommended!

In the end, you might want to configure your own protocol too (django supports all protocols supported by flup. And I chose for scgi (for unknown reasons really…)

So, knowing those things, the basic best-use would be to use the command:

./manage.py runfcgi socket=/path/to/socket/file pidfile=/path/to/pid/file [protocol=your_protocol]

To make things easier, I put those things straight in my project directory. Although one might opt-in for the approach of having a subdirectory, or using a completely different directory.

However, to start, which will help anyone having trouble setting things up properly, you should try to stop deamonizing the script, eventually you’ll see whatever happens…

To do so, just add daemonize=false to the string of options. Note that we’ll only use this during the test of the setup, if you don’t have any issues, I even wonder why you’re still reading this…

One might also be interested in auto-starting some script, but I’ll leave that shizzle up to you, although I strongly recommend, I can’t cover most auto-start script here (and since I’m used to archlinux, it was a hassle to do so on debian!)

Apache is next.

So, we don’t have to look back to the project anymore, we’re going to start of configuring apache.

Now, on this, I find the documentation of django a bit unclear, but depending on your OS, you’d be editing httpd.conf (or similar, e.g. on my debian it was called apache2.conf)
For clarity I’ll just keep refering to httpd.conf from here on!

After (obviously) installing and activating mod_fastcgi, you’d have to get one line in the httpd.conf file to enable the apache server to communicate with your project.

httpd.conf:
FastCGIExternalServer /path/to/fcgi/file -socket /path/to/socket/file

NOTE: The fcgi file can exist, but it is no requirement.
NOTE2: If you’re later on testing get “Permission denied: FastCGI: failed to connect to server blabla: connect() failed” you’ll need to make sure the user apache uses (mostly www-data) has access to the fcgi file. The simpelest way to solve this is a chmod 777 /path/to/fcgi/file

Next thing would be to configure your website. Note that here you’ll have to use the proper syntax to get your /media/ online. I used /media/ too for my own media files (in the end seeing that it isn’t the proper/best method, I’ll change that when I got the guts)

httpd.conf:
<VirtualHost 0.0.0.0>
  ServerName example.com
  DocumentRoot /path/to/document/root
  Alias /media /home/user/python/django/contrib/admin/media # Note that this may differ per setup
  RewriteEngine On
  RewriteRule ^/(media.*)$ /$1 [QSA,L,PT] # This one will NOT get django to deliver the media files
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ /fcgi_file.fcgi/$1 [QSA,L] # Note that you'll have to use the proper filename
</VirtualHost>

To end

Now, restart (or start) apache, and best tail -f the error file (just in case), pay attention to your (if you did what I suggested) non-daemonized django project. If nothing happens, and you can visit your website without an 500 internal server error, or anything similar, you can get the daemonized django project in the running!

Congratulations, you just configured and installed apache + mod_fastcgi to use in your django project. Next would be to actually get things running the way YOU want it.

Before I leave you guys to never visit me again, I’d like to thank the guys at irc.freenode.org#django for the help, and the django developers for getting such a great framework online!

Django + AJAX

With the past project, I’ve been using django all the way.
Given the requirements for that project, I judged that we were going to be needing a lot of AJAX, and I immediatelly started looking around for ways to do this. Luckily, it was found pretty quickly.
The is_ajax method

Conveniently enough: django provides a method inside the request, is_ajax, it’s pretty straight forward to  what I was looking to: A method to figure out simply and quickly whether or not a request is indeed originating from my AJAX platform.

There are -however- several items to take in account when using is_ajax:

  1. is_ajax checks the HTTP_X_REQUESTED_WITH header to varify the source to be AJAX or not. This is being used by most of the javascript frameworks, including prototype (which I opted for).
  2. In the current form, the CSRF (Cross Site Reference Forgery) middleware won’t work with AJAX, I have submitted a patch for that, but it has not yet been included in the svn. If you are using (or going to use) the CSRF middleware, you might consider changing the source.


Using is_ajax

To use is_ajax inside your view is a very straight forward and easy thing. However, considering several items, I would advice several things:

  1. I never use AJAX GET requests, ever. Because of that, I’m always checking whether or not the request was indeed a POST request. I advice using the same method (only allow one of both per page you’re requesting). Take in mind though the common sense: POST should be used when you’re intending to change values, GET whenever you’re just going to get some data and return it (get_or_404 e.g.) Even though we’re talking AJAX, we should still be on guard.
  2. NEVER, EVER trust anything coming from an AJAX request. Albeit you should never ever trust any request, I find the AJAX requests still more dubious. Especially since people are discovering ways to misuse the trust in AJAX more quickly. As a rule, anything coming from outside should be checked, and anything coming from the inside should be looked at in suspicion.
  3. When you’re using AJAX in a user authenticated area, always check for that user. It might sound as if I’m saying stupid things, but even though you expect the user to be there (it being a user area after all), it might just as well be something else.

Those things being pressed, this is how I use is_ajax fully:

if request.method != 'POST' or not request.is_ajax() or not request.user.is_authenticated():
    return HttpResponseForbidden('')

Simply put, it follows my method of thinking. First of all, the request should be POST, than, it should be an AJAX request for this function.
Those are the 2 basic “technical” items of the request. The third being the user authentication check, is actually only because it’s more secure and I need to use that user data later on.

If at any of those three the check fails, and goes to the return statement below, I follow the correct way of webdevelopment in telling the user/program the request is forbidden. Because it is, since it didn’t go through the checks. I was tempted to return a 404 document, it being a bit more cryptic, but it won’t change a darn thing after all.

As this concludes my little lecture, I’m going to let you guys play with the django framework some more!
References to the things I spawned at your face:

Using python?

While on my quest for a proper framework, which in the end I would like to use all the time, I stumbled upon django.

“Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.”

This is how they describe the project. And quite correctly that is.

While trying to figure out if I would like to use the framework, and interested to use the power of python together with web development, I got my hands on a project, which would be using django all the way.
Knowing no django at that point, I started learning the framework, and amazingly enough, the day thereafter I started the project, and everything worked from the start, currently, the project houses 2 apps, about 5000 lines of code, and everything is still working fine, clear, etc…

As I am implementing the new template system, I found that I spent more time using the version control than coding the actual project (!)

Why this post was started is simple: As from this moment, I’ll be writing frequently about django, and python. Because those are the things that my interests catches the most at the moment!

So, the android stuff hasn’t been posted often in the past year. Granted, the website did get most of its traffic because of these posts, but not quite the traffic I wanted, and I only wish to write about things I know sufficient of.
Android is developing so fast, and on so much different items, that it is becoming nearly impossible for only one person to keep track of it all, without spending a full-time job on it…
Does that make me less interested in Android? NO, it’s just so that I’m no authority on the subject, and there’s currently a whole bunch of websites/blogs doing a better job at reporting the events than I ever did.

Anyhow, this is the era of python in codercpf.be, I hope you guys are ready for it!

Until next post, CPF_

PS: As some of you (probably no one, except for google bot) noticed, I’ve changed hosting. Losing a lot in the progress (I hate moving!)
I’m currently being hosted at www.webfaction.com , which also allows for django, pylons, etc… projects to be hosted on the site!
Therefore, please expect some of my projects online here, and as it is, I’m going to make you guys some projects you just can’t ignore!

New design: Simple beauty

Hi @ everyone and nice to be somewhat back.

The site has been through some movement, and thanks to that, the previous loadFoO was lost in the process.

This time though, I’ve got a design from pikanai.com, called Simple beauty. I ported it on wordpress as usual, and if any of you wish for the files, please ask. I will make sure you get them ;)

Also, please give the opinion, it’s highly appreciated.

Anyhow, this’ll be my leave for a while again.

PS: Keep It Simple, Sexy ;)

Small quote.

For today (and of course the previous days of inactivity) I’ve got a quote, which I really liked:

“Windows is a 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can’t stand 1 bit of competition.”

Beat that!

CPF_

[Android] Netbeans plugin in the make

Sorry for the late idleness, I’ve been quite busy elsewhere.

Nonetheless, there’s some nice work going on with the android platform, again. This time someone has published his current work status in creating a Netbeans plugin to emulate the Android OS.

Screenshots are found here: http://picasaweb.google.com/joerg.ruethschilling/AndroidPluginForNetbeans

I’m definitely using that one when it’s out there, I’m a Netbeans user myself, so working with eclipse isn’t really my style (works though).

UPDATE
As it is, I just read that the android plugin for netbeans will never come to an end. Apparantly,  google licensing prevents the SDK to be used in another IDE than eclipse.

I’m sorry to everyone, but that’s just the way it is. Too bad though, because android on netbeans would’ve been really fast and powerfull…

Funny people – firefox anyone?

Here’s a picture of someone getting detention for running firefox… http://www.uploadgeek.com/uploads456/0/1197784327416.png

How about that? We all seem to love internet explorer too much ^^

LoadFoO v0.2

LoadFoO is becoming bigger every second, just minutes ago I fixed up the xhtml 1.0, while I discovered that the sidebar was not widget-friendly (Big mistake), also, the 0.1 version contains wrong files. So, anyone (If someone) who has already downloaded 0.1 version -> dump it, and get the 0.2 version now

At any rate, the next thing (again) would be to make it valid. I’ve currently got 8 errors on the index, all thanks to the widgets… It’s likely that I’m going to have to fix up some widgets for this, any author of that widget will be contacted if there would be any update, and the updates will be available for download here soon.

LoadFoO – small update

Ok, the previous post is outdated already, LoadFoO wordpress theme is now 100% valid w3c code (xhtml 1.0 transitional). I’m thinking of making it xhtml 1.1, but that’s for later. The file is still found at www.codercpf.be/dls/loadfoo-0.1.zip.

Please comment as much as possible, and use at will, it’s gpl after all.

Many thanks to the original designer again!!

New design – LoadFoO

I’m proud to finally announce the new design – LoadFoO.

LoadFoO was originally developed by Devit Schizoper as an open source design.

I liked what it might become here, and asked permission to create a wordpress template out of it, which permission I got if – of course – I leave the credits intact.

So, Enjoy the first template version, still not 100% valid, but it’s a start, I’m going to w3c it soon!

Also, the template is downloadable here. The template is originally based on the default template, so forgive me if not all the files render correctly. The 1.0 version will solve it all!