WebSense and their lack of sense
Dec 19th
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)"
..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
Aug 17th
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
Aug 17th
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
Aug 13th
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
Aug 11th
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!
Aug 4th
Here’s a new blog. Maybe this time I’ll actually update it with useful information. Ah well.
Cheers,
Nick