WebSense and their lack of sense

As I was browsing my lighttpd logs (something fun to pass time), I noticed a few weird entries. 62% of the visitors to my site use Firefox, so seeing quite a few IE visitors set off some alarm bells.

::ffff:208.80.193.40 nick125.com - [22/Sep/2009:07:47:52 -0600] "GET / HTTP/1.0" 200 15810 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; MEGAUPLOAD 1.0; ZangoToolbar 4.8.3; SpamBlockerUtility 4.8.4; MSN 9.0;MSN 9.1; MSNbQ002; MSNmen-us; MSNcOTH)"
::ffff:208.80.193.27 continental.nick125.com - [22/Sep/2009:07:50:16 -0600] "GET / HTTP/1.0" 200 3569 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; PeoplePal 3.0; ZangoToolbar 4.8.3)"

::ffff:208.80.193.40 nick125.com - [22/Sep/2009:07:47:52 -0600] "GET / HTTP/1.0" 200 15810 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; MEGAUPLOAD 1.0; ZangoToolbar 4.8.3; SpamBlockerUtility 4.8.4; MSN 9.0;MSN 9.1; MSNbQ002; MSNmen-us; MSNcOTH)"::ffff:208.80.193.27 continental.nick125.com - [22/Sep/2009:07:50:16 -0600] "GET / HTTP/1.0" 200 3569 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; PeoplePal 3.0; ZangoToolbar 4.8.3)"

..and so on.

Odd. I decide to whois the IP….and guess who it is!

OrgName: Websense, Inc
OrgID: WEBSE-6
Address: 10240 Sorrento Valley Road
City: San Diego
StateProv: CA
PostalCode: 92121
Country: US

Hmm. Why are they spoofing their user-agent? Also, it appears that they ignore robots.txt, as they never tried to request it from my server:

nick@lithium:~$ grep -i '208.80.19[2-9]' /var/log/lighttpd/access.log | grep -i 'robots'
nick@lithium:~$

Not only are they spoofing their UA, but they’re also disregarding robots.txt! How nice of them.

Anyone else notice this?

A neat little render_to_response trick

If you’ve used Django long enough, you will have noticed that render_to_response uses Context rather than RequestContext as the context instance. This is just no fun if you want to use things like auth, MEDIA_URL, etc in your templates. You could just add context_instance=RequestContext(request) to every render_to_response call, or you can use this little code snippet. Not only does it set the default context instance to RequestContext, but it’s a little less typing. In my projects, I put this in Commons.utils.

from django.template import RequestContext
from django.shortcuts import render_to_response

def render(request, *kargs, **kwargs):
 kwargs["context_instance"] = RequestContext(request)
 return render_to_response(*kargs, **kwargs)

Use it just as you would render_to_response, with the exception of setting context_instance. Enjoy!

The “Better” settings.py

While working on my CRM, I had a bit of an issue: I wanted to keep my setup specific settings (Database information, timezone, secret key, etcs) separate from application settings (INSTALLED_APPS, ROOT_URLCONF, etc). This is useful since it keeps development configurations and production configurations separate and it keeps your setup specific settings out of your VCS. Well, less talk and more code!

# local_settings.py
ADMINS = (
    ('Your Default User', 'nobody@example.com'),
)
MANAGERS = ADMINS

PRODUCTION = False
TIME_ZONE = 'America/Denver'
LANGUAGE_CODE = 'en-us'
SITE_ID = 1
USE_I18N = False
SECRET_KEY = 'PutASecretKeyHere'

DATABASE_ENGINE = ''
DATABASE_NAME = ''
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_HOST = ''
DATABASE_PORT = ''

PROJECT_ROOT = '/path/to/your/project'
MEDIA_URL = 'http://your/media/path/'
# Settings.py
from local_settings import *
if not PRODUCTION:
    DEBUG = True
    TEMPLATE_DEBUG = DEBUG
else:
    DEBUG = False
    TEMPLATE_DEBUG = False

MEDIA_ROOT = '%s/templates/media' % (PROJECT_ROOT)
ADMIN_MEDIA_PREFIX = '/media/'

TEMPLATE_LOADERS = (
    'django.template.loaders.filesystem.load_template_source',
    'django.template.loaders.app_directories.load_template_source',
)

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.core.context_processors.auth',
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media')

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
)

TEMPLATE_DIRS = (
    '%s/templates' % (PROJECT_ROOT)
)

INSTALLED_APPS = (
     'django.contrib.auth',
     'django.contrib.contenttypes',
     'django.contrib.sessions',
     'django.contrib.sites',
     'django.contrib.admin',
)

from post_settings import *
# post_settings.py

TEMPLATE_DIRS.append("/an/additional/template/path/")

So, how does it work? Quite simply. Put your database settings into local_settings.py and any other settings that aren’t set in settings.py will go there as well. Need to override something in settings.py? Use post_settings.py for that. Not cool enough? In local_settings.py, use a conditional to setup your database settings! This will look something like this:

if PRODUCTION:
    DATABASE_TYPE = 'mysql'
    [...]
else:
    DATABASE_TYPE = 'sqlite3'
    [...]

Pretty nifty, eh? I figured it might make someone’s life a little easier.

Cheers!

Nick

Upgraded to WP 2.8.4

Ah, it seems that Wordpress 2.8.3 has a nasty password reset issue, so I’ve upgraded to the new and shiny and password-reset-vulnerability-lacking 2.8.4. Wordpress makes it fairly easy to upgrade, so why not?

Archive.org

I just looked at the old versions of my site at Archive.org, and it’s kind of depressing. Oh, how immature I seem, looking at the old sites. I guess age does bring something to the party.

I’m going to go reminisce for a bit…..

Cheers,

Nick

Hello!

Here’s a new blog. Maybe this time I’ll actually update it with useful information. Ah well.

Cheers,

Nick