Django 1.10 added a new style of middleware with a different interface and a new setting called
MIDDLWARE instead of
MIDDLEWARE_CLASSES. Creating a class that supports both is easy enough with MiddlewareMixin, but that only works with Django 1.10 and above. What if you want to create middleware that can work with all versions of Django so it can be easily shared?
Writing a compatible middleware is not too hard. The trick is having a fallback for when the import fails on any earlier versions of Django. I couldn’t find a full example anywhere and it took me a few attempts to get it just right, so I thought I’d share my results to save you some time.
from django.core.exceptions import MiddlewareNotUsed
from django.shortcuts import redirect
from django.utils.deprecation import MiddlewareMixin
MiddlewareMixin = object
def __init__(self, *args, **kwargs):
raise MiddlewareNotUsed('DISABLE_MIDDLEWARE is set')
super(CompatibleMiddleware, self).__init__(*args, **kwargs)
def process_request(self, request):
if request.path == '/':
def process_response(self, request, response):
CompatibleMiddleware can now be used in both
MIDDLEWARE_CLASSES. It should also work with any version of Django so it’s easier to share.
Dysfunctional Broadcom WiFi card
I have had my Dell XPS 13 for almost half a year now. It’s the 2015 model numbered 9350. Ever since I got it, the WiFi has had issues. It’s dropping packets left and right and especially when placed on uneven surfaces like my lap or a carpet. I think it also has something to do with heat because it seems to take a while to show up after the computer is initially powered on. The issue worsened with time to the point where I simply can’t use it on my lap anymore.
I am far from alone with this issue. A simple Google search shows many people complaining about some variation of the same. Luckily, some of them actually figured out the culprit and it’s the Broadcom WiFi card. Apparently some models come with an Intel WiFi card that works perfectly fine. In the 2016 model they went ahead and completely replaced the faulty Broadcom card with Killer card across all models.
For whatever stupid reason, I decided to call Dell Support before just replacing the card myself. They were predictably useless and wasted two and a half hours of my time. Tier 1 took two hours of blindly following steps from a piece of paper. Tier 3 actually tried some advanced WiFi settings I never heard of, but that failed too. And then they saw my VirtualBox network adapters. They immediately jumped to conclusions that I’m sharing my connection with other computers (huh?) and that I need to disable them. So we disabled them and then instead of running an actual test like moving the laptop to an uneven surface, they ran one pingtest.net and decided that one passing test means they fixed the issue. I hung up.
More angry at myself for wasting my own time than Dell Support doing their jobs, I went ahead and purchased:
- Intel WiFi card 7265NGW
- Screwdriver set with Torx T5 because why make things easy to repair?
- Plastic pry tools because Torx is not hard enough
Once everything arrived, I followed the service manual and installed the new card in less than 10 minutes. With the right tools in hand, it was really simple and only cost $40. No need to wait 10-14 days for Dell to repair my laptop and no need to waste my time convincing technical support that it’s a hardware issue and another Broadcom won’t help.
Needless to say the WiFi is finally working perfectly fine on any surface.
I have seen a few “staying safe online” guides lately. I wrote one of my own a while back after some of my friends were threatened online and got worried. This guide should be a good starting point for most common casual internet users. It’s important to remember that no matter what you do if it’s online, it can be hacked.
- Never reuse passwords
- Some websites are easier to hack than others
- Hackers will try the same password on other websites
- Use LastPass for easier management
- Don’t use simple passwords
- Hackers guess passwords all the time
- There are easy automatic tools that enumerate all password options
- Don’t use your name, birthday, SSN, or any public information in passwords
- Keep your computer & phone up-to-date
- Old software has known and easily exploitable vulnerabilities
- Never click links in emails
- Clicking the wrong link can give control of your accounts to hackers
- Manually browse to the website even if the email looks legit
- Always logout on public computers
- Preferably never login on public computers in the first place
- Data can be linger even after logging out
- Some public computers record your passwords
- If it was put online, it will stay online
- Any private information shared can help hacking
- Your name and birth year can be enough to guess your SSN
- Click the little lock icon on top and follow instructions
- Set everything to private
- Hide your birth year
- Click the little triangle on the top right and choose Settings
- Enable login alerts to be notified of hacks
- Enable login approvals
- Enable trusted contacts in case your account is hacked
Securing Google Account
- Enable 2 factor authentication
- Check Google+ privacy
I had a problem where HDFS would fill up really fast on my small test cluster. Using
hdfs dfs -du I was able to track it down to the MapReduce staging directory under
/user/root/.staging. For some reason, it wasn’t always deleting some old job directories. I wasn’t sure why this kept happening on multiple clusters, but I had to come up with a quick workaround. I created a small Python script that lists all staging directories and removes any of them not belonging to a currently running job. The script runs from cron and I can now use my cluster without worrying it’s going to run out of space.
This script is pretty slow and it’s probably possible to make it way faster with Snakebite or even some Java code. That being said, for daily or even hourly clean-up, this script is good enough.
all_jobs_raw = subprocess.check_output(
'mapred job -list all'.split())
running_jobs = re.findall(
staging_raw = subprocess.check_output(
'hdfs dfs -ls /user/root/.staging'.split())
staging_dirs = re.findall(
stale_staging_dirs = set(staging_dirs) - set(running_jobs)
for stale_dir in stale_staging_dirs:
'hdfs dfs -rm -r -f -skipTrash ' +
'/user/root/.staging/%s' % stale_dir)
The script requires at least Python 2.7 and was tested with Hadoop 2.0.0-cdh4.5.0.
Sometimes you get stuck with a broken or no dump at all. You know what you’re looking for but WinDBG just keeps refusing to load symbols as you continue to beg for mercy from the all knowing deities of Debugging Tools for Windows. You know what PDB you’re looking for but it just wouldn’t load. The only thing you do know is that you don’t want to go digging for that specific version of your product in the bug report and build a whole setup for it just so you can get the PDB. For those special times, some WinDBG coercion goes a long way.
To download the PDB create a comma separated manifest file with 3 columns for each row. The columns are the requested PDB name, its GUID plus age for a total of 33 characters and the number 1. Finally call symchk and pass the path to the manifest file with the /im command line switch. Use the /v command line switch to get the download path of the PDB.
To demonstrate I’ll use everyone’s favorite debugging sample process.
C:\>echo calc.pdb,E95BB5E08CE640A09C3DBF3DFA3ABCB42,1 > manifest
C:\>symchk /v /im manifest
SYMSRV: Get File Path: /download/symbols/calc.pdb/E95BB5E08CE640A09C3DBF3DFA3ABCB42/calc.pdb
DBGHELP: C:\ProgramData\dbg\sym\calc.pdb\E95BB5E08CE640A09C3DBF3DFA3ABCB42\calc.pdb - OK
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
To force load the PDB you need to update the PDB path, turn SYMOPT_LOAD_ANYTHING on, and use the .reload command with /f to force and /i to ignore any so called mismatches.
kd> .sympath C:\ProgramData\dbg\sym\calc.pdb\E95BB5E08CE640A09C3DBF3DFA3ABCB42
kd> .reload /f /i calc.exe=0x00400000
You should now have access to all the data in the PDB file and stack traces should start making sense.
An open source OS makes debugging applications so much easier. Instead of firing up IDA and going through opcodes, you can simply read the code and sometimes even find comments. However, searching through millions of lines of code can be a daunting task. Operation systems usually have a huge codebase and even the simple task of looking for one function can take a few good minutes. After reading that function, you usually want to search for functions it calls or functions that call it to better understand the flow. Those extra searches take time too. A good IDE would solve this issue but it requires downloading and indexing the massive source code first.
LXR was created for this exact reason. It allows hosting a fully indexed copy of the source code. It even makes it easy to publish an index of multiple versions of the source code. Want to compare a certain function between two versions of the Linux kernel? No problem. Want to know which functions use a certain function? Easy. LXR is awesome and fast.
Setting up LXR on your own, however, does take some time and effort. That is why I was happy to find AndroidXref.com while trying to hunt down a bug in one of my Android applications. It indexes both Android and patched Linux kernel sources for all major versions of Android. It is an invaluable resource every Android developer should know.
I originally had a question about this topic open on StackOverflow with AndroidXref as the accepted answer. It was recently deleted, probably because it didn’t have anything to do with C operator precedence. This is my
I created a quick backport patch for Scapy 2.2.0 so it could run on Python 2.4. Nothing too special. Just the usual removal of with, try/except/finally and defaultdict.
So if you’re stuck with Python 2.4 like me but still want to [ab]use Scapy, apply the patch and get your fuzz on.
The original ticket is available on Scapy Trac.
Newer versions of GDB come with the nifty find command. The old version of GDB I have to use does not. It is also incapable of generating a proper stack trace for the platform it supposedly serves. But that’s a whole other story…
Anyway, I found a piece of code that almost does the same. I tweaked it a bit, fixed the stray bug ($x -> %p) and would like to never do it again. So here it is for my future reference and your indulgent.
set $start = (uint64 *) $arg0
set $end = $start + $arg1
set $pattern = (uint64) $arg2
set $p = $start
while $p < $end
if (*(uint64 *) $p) == $pattern
printf "pattern %p found at %pn", $pattern, $p
Humanoid, search engine and one of the most addictive FPS games ever created walk into a bar. A few refreshing cups of coffee later, a joke is born and its name is MW2 Guide.
I’ve created a pretty simple application for Android that helps Call of Duty: Modern Warfare 2 addicts, such as myself, to make some sense of the bombardment of dialog boxes popping after a match. It’s basically a list of all available callsign titles and their description. What sets it apart from a few dozen similar apps is the quick search ability and auto completion voodoo, in accordance with Android’s search centric vision.
Search for MW2 Guide on the market, or use the QR code below.
Microsoft provides useful extensions for debugging SCSIPORT drivers in WinDbg. But with some versions of scsiport.sys, the symbol files don’t contain type information. This produces fun errors like the following.
kd> !scsikd.scsiext 8a392a38
*** Your debugger is not using the correct symbols ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** Type referenced: scsiport!_DEVICE_OBJECT ***
scsikd error (3): ...\storage\kdext\scsikd\scsikd.c @ line 188
This makes the common task of getting your device extension object very daunting. After some digging, I came up with this code to at least get my device extension object from SCSIPORT’s device extension object.
* get relevant DevObj
* get DevExt
dt mydriver!MY_DEVICE_EXTENSION poi(<DevExt> + b4)
I’ve only tried it on Windows XP SP3. The offset may be different with other configurations. Anyone knows a better way around this? Preferable method would naturally be making scsikd work.