There definitely are some articles (and forum threads) out there that come close, but this is how it’s done

Some predefs

The goal is to be able to connect to multiple VirtualHost’s on an Apache webserver.

We have a localpc behind a NAT-ed internet connection (yourpc.locality.lan) and the aforementioned publicly accessible webserver on the net somewhere (yourserver.example.com).

I’m assuming you can already connect to your server via SSH, based on a pub/priv keypair.

Local to remote

There are some things that need to be set local AND remote to make sure that Apache knows to which (not publicly accessible) VirtualHost it must redirect your HTTP request. That is, make up a name and put it in your /etc/hosts file and have it resolve to 127.0.0.1. E.g:

$ cat /etc/hosts
127.0.0.1 localhost

# For ssh tunneling
127.0.0.1 mysuperadminsite.locality.lan

Important! You need to put the ‘mysuperadminsite’  entry in your /etc/hosts file on your server as well. Otherwise it won’t work because Apache can’t figure out where this needs to go (more on apache config in a sec).

Then, the actual SSH tunnel command is this:

ssh  -L 9002:mysuperadminsite.locality.lan:80 yourname@yourserver.example.com

There are ofcourse nicer ways to fully hide/automate the SSH tunnel, but by doing it manually like this you are explicitly remembered that you’re in ‘admin-mode’

Apache trickery

Ok, so how does Apache know where to go when your HTTP request hits the server side? As your mysuperadminsite request is resolved to 127.0.0.1 (on the server), apache needs this as a NameVirtualHost. So put this in your global Apache config somewhere.

# For admin work over SSH
NameVirtualHost 127.0.0.1:80

Then you create an apache VirtualHost config with a setup like this.

<VirtualHost 127.0.0.1:80>
	ServerName mysuperadminsite.locality.lan

	# Here you put your docroot, includes, logfile entries and whatever else you want.

</VirtualHost>

And so, apache resolves the request to 127.0.0.1 where, based on the X-Header (containing the mysuperadminsite name) sent by your browser, it actually finds a vhost to handle your request.

This is a very safe way to handle your secure access because the VirtualHost is only handled by apache when it comes in on your loopback interface. Moreover FQDN’s based on “locality.lan” are not resolvable in the outside world.

It does however require a second website instance. You could combine an externally accesible VirtualHost by starting your config with this.

<VirtualHost [external_ip]:80, 127.0.0.1:80>

This way you don’t have to have a second VirtualHost config (and thus website instance) for management. But it’s easier to overlook going secure and thus have your passwords or whatever sniffed.

Gotcha’s

None that I know of, but feel free to point them out

Safe computing!

After researching and setting up two FormWizards in Django I concluded some things that might be useful to others. Hence this post.

Having userdata available throughout the wizard

I’ve seen some solutions on the net for this but when you handle data from several models over different steps the best way to handle this is using Django’s session framework. In parse_params() in the beginning and end we repectively get/set data and store our data.

def parse_params(self, request, *args, **kwargs):
    current_step = self.determine_step(request, *args, **kwargs)
    form = self.get_form(current_step, request.POST)

    # Pickup the dict from the users session or create a new one
    wizdata = request.session.get('wizdata') or {}

    # Your code goes here. E.g. set a value in the dict
    wizdata['some_key'] = 'Some value'

    # Store the possibly changed dict back in the users session.
    request.session['wizdata'] = wizdata

So whatever you do with the user data, it’s safe, and we can access it in any step throughout the wizardry.

def render_template(self, request, form, previous_fields, step, context=None):
    wizdata = request.session.get('wizdata')

    # Your other code goes here. E.g. a conditional on previously set data.
    if wizdata.get('some_key'):
        # Do something with your data
        wizdata['some_key'] = 'Some other value'

    # And again, simply store the dict in the users session.
    request.session['wizdata'] = wizdata

You can imagine that in the parse_params() and the render_template() method you respectively have the ‘if current_step == ‘ or ‘if step == ‘ statements along the way. All having the wizdata dict available.

This also works in the done() method. Simply get the dict one last time from the user session.

def done(self, request, form_list):
    wizdata = request.session.get('wizdata')

    # Other code here

    # Cleanup
    del request.session['wizdata']

Then, for tidyness, at the end of done() we remove the dict from the user session.

Gotchas

There can be stale data, in the form of our stored dicts, left behind when wizard sessions are not finished by the user. This also is true for the sessions itself. As stated in the The Django docs about sessions you should clean up the sessions from time to time.

Anybody that has improvements, questions or compliments please drop me a line

GrtzG

I recently moved away from amarok and started using Exaile as my favorite audio player. I found out that Exaile automatically displays the cover art when it finds a “cover.jpg” in the album folder. Maybe I’ll start a ‘which-player-supports-what’ post some day but don’t hold your breath

I was very excited about this because my tast in music is ‘not mainstream’ to say the least so all those cover fetcher tools leave a lot of gaps for my album art. Since I started to clean up a bit I wrote down the structure on a note to remember it once and for all. I thought I’d might as well publish it and so this post was born.

Folder setup

It’s all in folder “~/Music/” but that isn’t that important. The structure is set up as follows:

Artist/Album/
             cover.jpg
             back.jpg
             info/              # For stuff like lyrics.txt, etc.
                  bookletX.jpg  # booklet images.
                  [back.jpg]    # if info/ exists this file moves here.

If it’s a multiple disc album the CD directories are called “cd1″, “cd2″, so smalls and no spaces. Then the info directory can stay on album-top level, but I place a copy of cover.jpg in all cdX directories so Exaile displays them.

Then if the album is a compilation it’s placed in this directory (got this from iTunes .

~/Music/Compilations/

You can find your Artists tag based because your player indexes those anyway. Assuming you use the tracks artist and not “Various artists”.

Track file naming

Then for naming the MP3 files themselves. When it’s a track in a full album:

01 - Trackname.jpg

When the track is in an album which is a compilation of various artists:

01 - Artist - Trackname.jpg

I noticed,when I used XMBC that it displays the tracks with “01. Trackname” even when naming them as above so that is at least understood without ambiguity.

When the track is just a single song:

Artist - Trackname.jpg

I have some old cassettes and MD’s I converted to MP3 in the past which have a Compilation suffix with “MD”, “AC”, “LP” at the end:

Trilok Gurtu - African Fantasy - Crazy Saints - Compilation MD.mp3

TAGs

Not to much hassle there. The only thing significant is when it’s a 1-pass MP3 of a full album the track title get’s some extra information. A full album suffix between brackets and a “cd1″ addition when it’s a multiple CD album.

Logical Progression cd1 (Full album)

Geeky

I think the subject of this post is totally geeky anyway but nevertheless .. Currently in the tags all words get first caps but with words being between brackets like the aformentioned (Full album) only the first word get’s capitalized. (Although I’m not sure yet what to do when it’s a subtitle or name).

Logical Progression cd1 (Full album)

I think that covers most of it for now. Hope it’s helpfull to anyone going bonkers over there MP3 collections.

Suggestions are welcome ofcourse.

GrtzG.

As Brian says it very eloquently in Songbird vs. Amarok: How not to design a GUI, and currently working on interface design myself. Amarok .. WTF?

After reading the Middle pane thread on the KDE forums I was baffled. Why not add customizable (drag ‘n drop) pane widgetry layout? And for the available widgets to fill that middle pane …

• Wiki info – How about a browser?!?!
• Track info – That’s already above the playlist.
• Album info – With file/folder view you can see what albums you have with one mouse click. (as was Amaroks strong point of critisism once towards iTunes).
• Lyrics – Do you think I’m studying lyrics while I’m working?

And some other fun features:

• The control buttons – Way to big, and worse the size is not adjustable. People are not born with visual impairments by default you know.
• After upgrading Amarok it decides to hang at 62% every time when it tries to scan my audio collection.

I heard a KDE member speak at a dutch conference not to long ago about how KDE has clean code and isn’t to bloated. Now I know why.

Exaile

Looking for that smooth flexible, clean player? then Exaile is the new big thing. It’s written in Python, supports OSD-notify out of the box. Supports plugins (and then some!). And ofcourse also the usuals like systray support, album cover fetching .. the works.

Props to the developers of Exaile!!

And for Amarok .. I am outta here!

GrtzG

SELECT id, name FROM myapp_model WHERE owner_id='1' GROUP BY name;

This would have been (easily) possible except for the WHERE clause on ownership that screwed me. Since the SQL statement was that simple I decided to write a bypass function that get’s the data straight from the database. It’s readonly access and I dont do anything more with it then create a list of links. Even more so, from a KISS point of view this code is easier to read back after several months.

And for reusability I turned it in to a function. It takes the model and the distinct field, and for my purpose the needed ownership as parameter:

from django.db import connection

def get_latest_objects(model_name=None, distinct_field=None, user_id=None):
    """ Get lastest distinct selection (as tuples) of a given model
    """
    model_name = model_name.lower()
    query = ("select id,%(distinct_field)s from myapp_%(model_name)s "
                "where owner_id='%(user_id)s' "
                "group by %(distinct_field)s;") % {
                    'model_name': model_name,
                    'distinct_field': distinct_field,
                    'user_id': user_id,
                    }
    cursor = connection.cursor()
    cursor.execute(query)

There’s not much to it, I just hope it helps you to avoid ‘the hard way’. And it helps to keeps your view methods more readable because you dont need anything more then this:

latest_objects = get_latest_objects(model_name='MyModel',
                        distinct_field='name',
                        user_id=request.user.id)

What is returned (latest_objects) is a list of tuples that you can unpack in your templates straight away. Note that there’s no error checking in there, because I know what I’m doing Besides, worst case you get back an empty list and possible errors are caught when you write your tests. You do write those don’t you?

Grtz Gerard.

But since wrongfull data disclosure is absolutely unacceptable I was still afraid that I would miss something somewhere. A nice example I ran into was populating a dropdown list in a form, where all records were visible instead of only those owned by the logged in user.

That got me thinking and eventually I wrote this small but sweet piece of middleware. Further elaboration below the code.

from django.db import connection
import re

"""
QueryScreener is a middleware development tool. This tool helps to avoid
unwanted data disclosure once you go into production.

It monitors queries to the models in your model_list and warns you when queries
are executed that do not contain a ownership where clause. And thus can be a
potential data disclosure hazard.

It requires a owner attribute in your model definition, e.g:

    owner = models.ForeignKey(User, editable=False)

Edit the 'model_list' below for what models should be monitored. And add
QueryScreener to MIDDLEWARE_CLASSES in you settings.py

Note: This can/should only be used while running Django's testserver command
with e.g: ./manage.py runserver 192.168.1.81:8000
"""

class QueryScreener(object):

    model_list = ['myapp_customer', 'myapp_order', 'myapp_product']

    def process_view(self, request, view_func, view_args, view_kwargs):
        if len(connection.queries) > 0:
            query_parse(connection.queries, self.model_list, 'process_view')

    def process_response(self, request, response):
        if len(connection.queries) > 0:
            query_parse(connection.queries, self.model_list, 'process_response')
        return response

def query_parse(self, model_list, caller_process):

    for query in connection.queries:
        for modelname in model_list:
            modelstring = 'FROM `'+modelname

            if re.search(modelstring, query['sql']) and not \
                re.search(r'^SELECT.\(1\).AS', query['sql']):

                reg = re.compile(r'^SELECT.*WHERE.*owner.*(ORDER BY.*)?$',
                                    re.DOTALL)

                if not reg.search(query['sql']):
                    print ('<<< WARNING >>> Query execution without ownership '
                            'clause, called from "' + caller_process + '"')
                    print query['sql']

            if re.search(r'^SELECT.\(1\).AS.`a`.FROM.*WHERE.*$', query['sql']):
                print ('<<< Django Farted >>>')
#                print query['sql']

Update1: The ‘ORDER BY’ in the regex needs to be optional.
Update2: Django does a ‘try update’ in save_base() without owner (seperated the select statement)

The comment in the code above sums up how to get it working. What it does is print a warning and the query in question that does not respect ownership. If enabled while developing just keep track of your console output for:

<<< WARNING >>> Query execution without ownership clause, called from "process_response"

Should you  have suggestion, criticism, or words of admiration then please, do tell me

GrtzG

Today I ‘moved’ the first version of my application from the Django development setup (run via “./manage runserver”) to a lighttpd/fcgi production setup. Been cleaning up code and concluded I wanted the app straight on the ‘/’ or docroot with a simple config like this:

HTTP["host"] == "example.int" {
    fastcgi.server = (
        "/" => (
            "main" => (
                "host" => "192.168.1.2",
                "port" => 8000,
                "check-local" => "disable",
                #"fix-root-scriptname" => "enable",
            )
        ),
    )
}

After a lot of messing around and not getting the aformetioned setup to work I found the ‘PATH_INFO’ problem. The easiest way is to have lighttpd version 1.4.23 running, because then you can enable:

    "fix-root-scriptname" => "enable",

And therewith actually acces your app on “/” instead of “/dd” as shown in the below example under the line with “fastcgi.server (“.

The problem however is that lighttpd version 1.4.23 is not apt-get-able yet and I like my systems clean. So here’s the somewhat cumbersome but functional example that works:

HTTP["host"] == "example.int" {
    fastcgi.server = (
        "/dd" => (
            "main" => (
                "host" => "192.168.1.2",
                "port" => 8000,
                "check-local" => "disable",
            )
        ),
    )

    url.rewrite-once = (
        "^(/.*)$" => "/dd/$1",
    )
}

What happens is that lighttpd passes an incoming request like “/url_to_something” to your fcgi proces, but fcgi is on “/dd/url_to_something”. So with the rewrite rule we make sure the “/dd” prefix is added, other wise it would not be passed to the fcgi handler.

The problem however is that you should modify all your in-app links so they would be prefixed with /dd otherwise you end up with a 404. This can be globally resolved by adding the line below to your Django settings.py

FORCE_SCRIPT_NAME = ""

Django then strips of the “/dd” prefix just before it gets parsed by your django app URL Dispatcher.

So when lighttpd version 1.4.23 is in the debian and/or Ubuntu repository, you apt get it and adjust your setup in 3 places.

Remove the rewrite rule and the “dd” part from your lighttpd host config and disable the FORCE_SCRIPT_NAME in your settings.py. Doing it like this keeps everything running with the least adjustments now and only a little work to be done in the near future.

I put this here in the hope that people do not actually reply to web.support@intructor.net and give out their credentials. To some it might seem useless to post this. But I am sure that there are people that do. So if you get an email like this one simply press the <delete> key.

Safe computing!!

1. Understand and accept that you will make mistakes
2. You are not your code
3. No matter how much karate you know, someone else will always know more
4. Don’t rewrite other programmers’ code without consultation
5. Treat people who know less than you with respect, deference, and patience
6. The only constant in the world is change
7. The only true authority stems from knowledge, not from position
8. Fight for what you believe but gracefully accept defeat
9. Don’t be “the guy in the room.”
10. Critique code instead of people—be kind to the coder, not to the code

Just so you remember..

GrtzG

For example, if you put this:

javascript:void(location.href='http://tinyurl.com/create.php?url='+encodeURIComponent(location.href))

as a url target in a bookmark it redirects you to a page at tinyurl and automatically generates the tinurl of your current page. I always keep stuff like this handy (in a toolbar) for quick access.

The delicious plugin can show a toolbar filled with bookmarks tagged with a specific word. So after installing the plugin make sure your Delicious toolbar is visible by right-clicking on your topmenu and selecting “Delicious Toolbar”.

In the Delicious menu choose “Manage favorite tags”. Create a new tag e.g. “MyBar” and select it as your favorite tag on your toolbar:

From now on all saved bookmarks that have the tag “MyBar” will show up in your toolbar.

In case of the scripted example above, choose “New bookmark” in the delicious menu. Paste the javascript code in the URL target, call it “Tiny”, give it the tag “MyBar” and save it.

Voila, now you have a working scripted bookmark called “Tiny” in your delicious toolbar.

GerardJP says:

Happy computing!