Jersey Annotation

Is your application server is throwing up the following warning at startup?

WARNING: A sub-resource method, public java.lang.String PATH_TO_METHOD, with URI template, "/", is treated as a resource method

Then the most likely cause of is that you have already defined a @Path("/blah") for the class. There is no need to specify @Path("/"), using @Get at the method level is enough to tell Jersey that it is default method for entire class.

Testing your document structure for inconsistencies within MongoDB

One of the advantages with schema-less design is that it works well for prototyping; you can have a collection of documents with each of the documents of variable structure. You can modify the document structure for one, some or all documents within the collection all without requiring a schema for the collection or each and every document.

However, this is also a disadvantage during prototyping; there are no constraints to stop documents within the same collection having variable structure. Deliberate updates to a document succeed silently as do accidental updates; ie when you update a document with a subdocument hanging off the wrong node. So when you assume you have consistency across all the documents, within a collection, but don't, you will run into some issues. You could also argue here that you're not coding defensively enough if you're not checking consistency at the time of execution; I'm not going to go into that right now though.

That exact structure inconsistency happened to me, and I ended up going down a rabbit hole. The smart thing to do was to blat the DB and recreate it during each test, but there were reasons that I didn't do that, which again I'm not going to go into here. Additionally the error that was coming back from performing an operation on the inconsistent structure wasn't obvious and didn't indicate to me that there was document structure inconsistencies, but that's another story.

Anyhoo, I didn't want this to happen again, so to verify the structural consistency of a collection I now pull in a json template; an example of the structure of the document I'm expecting to find within the collection I'm working with, and compare it to the collection in the DB. You can define your template in a json/txt file or you can manually create the DBObject. Simply put, I perform a symmetrical diff on the documents that are contained in the collection(s) I'm working with, and report on any additional field not defined in the template, I also report on any field that is defined in the template but not the document.

This example creates a DBObject with a few NVPs at the root, a couple as subdocument NVPs and finally an array.

We use this 'template' to compare against the documents within the tests collection.

This is all very lightweight but as a method to verify crude consistency it is very handy, for me anyway.

Security and MongoDB

The MongoDB Security Model has some scope for improvement.

1. As default, Authentication is off. MongoDB is designed to run in a 'trusted' environment, depending on the network configuration to ensure the security of the environment.
2. Pre v2 authentication is not supported within a sharded deployment.
3. Once authenticated a user has full read-write to the entire DB. There is no concept of roles or groups or such like.

Now, I wanted to deploy with Security turned up to the max, so here I will present a practical example.

This is a typical set-up I'd use for my development environment; separate machines each running mongod.

Firstly, let's set up the replicaset.
On the primary we can define and run the replicaset config:

Nothing fancy here, all standard stuff. After a few minutes the dust settles and the primary and secondary identify themselves. You can check the status of the replicaset with:

Now, on each box in the replicaset you'll need to create a key (must be valid Base64 and 1K or less):

You can now bring down both instances. Either hit ctrl+c or do it the right way:

Now we can start each of the mongod instances with the keyFile:

Word of warning here. I spent a significant amount of time trying to set this up on v2.0.0 - yes I know it is a bit dumb to go with a x.0.0 version, but you'd think that something as basic/fundamental as this would be thoroughly tested. Well, suffice to say I ended up moving to the latest binary to get this basic functionality to work. It was annoying at the time, but it certainly made me read the available documentation multiple times.
So now on the primary we can create the admin user aka root, super...

As we have a replicaset these users will existing in admin and mydb on both instances.

This whole process should take about 5 minutes to configure provided you're using a stable, well tested version.

I got unlucky and wasted hours on a buggy version grappling with errors that I couldn't decipher, feeling a bit denvercoder9 (http://xkcd.com/979/).

I went through the pain so you don't have to...

A simple guide to finding distinct array values in a MongoDB collection

So you want to find unique values within an array within a document in a collection? A reasonable request.

In ANSI SQL you'll be using DISTINCT, JOINS and GROUP BYs, stuff you're used to, but in the NoSQL realm your best bet is mapreduce.

It might seem a little bit like hard work, and probably a little intimidating at first, but it is certainly worth it; mapreduce is an extremely powerful tool.

Set up the collection, the map and reduce functions, and execute the mapreduce command:

But now you want to find unique values within an array within each document in an entire collection.

The map function in this example iterates over each of the items and emits the key/value of each array element.

The reduce function aggregates the key/value from each of the emits from the map function. In this example we're looking at unique keys and maintaining a count of the unique keys.

If you're looking to find the distinct array elements for a single document, simply specify the document index. For the entire collection, just leave the query out. *simples*

Simple mongodb equivalents

After making a noob error today, I realised that some of the documentation could use a boost.

By default mongo returns the entire document.

All fields for the matched document will be returned

And in java



To return only certain fields, you need to let mongo know which ones you want


The will only return the fields meh and feh from the matched document

And in Java


You can also say 'all fields except for...'



This will return all the fields in the matched document expect for meh

And in Java

WPA2 Packet Capture

Viewing packets for users on a secure wireless access point is stupidly easy.

If you sit anywhere that has a Free Access Point, you can capture traffic from other users. This may be a coffee shop or juice bar, or whatever. You may think that this can only be done on Open Access Points. You'd be wrong in this thinking. This is no secret. You can capture packets from other users even if encryption is turned on. That is, if WEP, WPA or even the strongest WPA2 encryption is being employed. Seriously, this isn't new.

In the case of the coffee shop the operators will give you the wireless key for free. In other places they may charge you a small fee for the usage of the Access Point. It doesn't really matter if they give you the key or not tbh. I say this because it is pretty simple to snaffle the key. You can do this by driving by a house and sniffing for traffic for as short a time as a few seconds, and running some brute forcing offline. Anyhoo, this is off topic.

How to do it.

Install Backtrack4. This takes 30 minutes. It's easier to have BT4 as the host OS to be able to have all the tools to hand and to have the right access to the wireless interface. After this step it is as simple as a few commands.

Show the adapter config

iwconfig

Create a new interface in monitor mode

airmon-ng start wlan0

Now, can scans for available networks

airodump-ng mon0

Capture traffic on the Access Point in question

airdump-ng -c CHANNEL --bssid MAC_ADDRESS -w demo_capture mon0

Decrypt the captured packets.

airdecap-ng -e SSID_NAME -p PASSWORD_KEY demo_capture-01.cap

Open the decrypted packet capture in wireshark and follow any of the TCP streams that look interesting. You'll be surprised what you can find out.

Hack a Master Padlock

Master 3 Barrel Combination Lock

Ever wanted to be able to show off to a friend that you could hack a padlock? Yeah me too. I started off making a shim as I thought I could use the piece of a coke can technique. It turns out I was trying too hard; I managed to open the lock without any tools or lock picking kit, just a bit or force and feel was required.

Set all the dials on the lock to 0 (zero).

Use your thumb to push up the hook. Hold this in place while you feel your way to the combination. Turn each of the dials, starting with the top dial slowly around. If you're applying enough force and your feel is sensitive enough, you'll notice that the dial will be significantly different when it hits a certain number.

Believe it of not, it's that easy, that is the number for dial. Seriously. Next move onto the dial down. The action is exactly the same as before. Repeat again for the last dial.

Bingo! Or 'House!', as they say in Bingo.

It is just as easy, and exactly the same method for the 4 dial combination lock. Well, when I say just as easy, I thought to begin with that same technique wouldn't work, but I'm rather stubborn and kept at it. The difference between the correct position and all the other positions of the dial are much more subtle on the 4 dial than the 3 dial.

The other (more) famous Master Combination lock hack.


You can change the number by:

1. Unlocking the padlock
2. Holding down the hook in the 90 degree position
3. Setting a new number