Specifying a port when connecting with SSH

Some servers run their SSH server on a different port than 22 for a variety of reasons, including security.

To specify a custom port when connecting, use the -p flag as in the example below:

ssh user@server.com -p 2222

In this example, the client would attempt to connect using port 2222.

Fix garbled file names in SMB shares

If you have files in your SMB networked folders that look like this: TRZB4~J.mp4, there is a very easy fix to get the original file names.

Open your smb.conf file (usually at /etc/samba/smb.conf) and add the following line under [global]:

mangle case = no
mangled names = no

Once this is done, enter the following command in your terminal:

sudo service samba2 restart

Names are mangled to make them compatible with older operating systems, but this absolutely shouldn’t be a problem that you will face at home.

Following redirects with the Django test client

When running unit tests with in Django, the test client’s default behaviour is to stop at the first response, even if that response is a redirect.

If you want the client to follow these redirects and return the last page, perform your requests like this:

response = c.get('/redirect_me/', follow=True)

This will also add response.redirect_chain so you can see which URLs it followed before getting to the final page. Here is a sample redirect_chain:

[(u'http://testserver/next/', 302), (u'http://testserver/final/', 302)]

Euclidean algorithm in Python

While it won’t really be useful to most people, here’s how you implement the Euclidean algorithm in Python.

b = 13
a = 18

while b > 0:
    if a>b:
        a = a-b
        b = b-a

print "The GCD is:"
print a or b

Ping once and return true/false

The ping command will usually try pinging a device forever, returning the response time after each pingback. If you want to ping a device once and use the answer to perform an action, use the following snippet:

ping -c 1 [your ip or hostname] > /dev/null

This command will either return 1 on failure or 0 on success.

In the example below, we use the && operator to perform an action if and only if the ping to “homeserver” was successful:

ping -c 1 homeserver >/dev/null && echo 'Successfully pinged device!'

This can be a great way to monitor the presence of a device on the network for a dead man’s switch for example.

Print preview significantly different from Inspector in Chrome?

Are you having issues with the Chrome print media emulator showing different results from print preview? Here’s how I solved this problem.

In the emulator, my styles were showing just fine, but despite all the !important rules in the world, nothing would work in print preview. It turns out the print preview will display your page before CSS transitions are applied, so if there’s a transition when some elements are moved, print preview will show them before that transition. This is especially tricky if you use CSS transitions for columns, responsive design, slide out menus etc.

Adding *{transition:none!important} in the print stylesheet fixed it for me.

What is Cross-Site Request Forgery (CSRF)?

Following the previous “you should know” introductions about SQL injection and XSS injection, here is a short introduction to CSRF. I’ll quickly define it with a few examples, then provide solutions to avoid it.

CSRF (or XSRF) is an exploit where a malicious application transmits unsolicited requests to another web application in the name of an unsuspecting user.

For example, a malicious website could exploit on your application by putting an image with http://yourapp.com/transferCredits?amount=1500&to=hacker as the source on the page. If an unsuspecting visitor loads the image and is also connected to yourapp.com, he would unknowingly transfer 1500 credits to the hacker.

    This image on maliciouswebsite.com would silently
    delete a connected user's account on importantsite.com

    <img src="http://importantsite.com/api/account/delete">

Click jacking is a similar exploit. A malicious website could move an invisible Like button right under your mouse as you are about to click, making you Like a Facebook page without your consent.

Unlike XSS and SQL injections, you might not notice when a CSRF attack takes place, since it will look as a legitimate request.

Preventing CSRF

Using POST for requests with side-effects (creating, updating or deleting records) instead of GET will already help make your application safer.

To prevent CSRF, you need to verify that the request comes from a legitimate user. This can be achieved by emitting a unique token when serving the page that would normally call an action. When you receive a request, you verify that a valid token was supplied with that request. This is the approach most frameworks take.

Alternatively, you can verify the Origin and Referer headers to make sure that the request comes from your own site.

If you use Django, you are required by default to use CSRF tokens for POST requests with side-effects.

As usual, OWASP has an excellent guide about preventing CSRF.

.find() vs. .children(): which one should you use?

jQuery offers two functions to find children in an element: .find() and .children(). .find() will look through all children of an element while .children() will only look at immediate children.


In the snippet above, $('ul').children('p') wouldn’t return anything, while $('ul').find('p') would return all three paragraph blocks.

In terms of performance, .find() is faster than .children() in most cases, since it uses native browser methods instead of JavaScript.

Here is a performance test that compares .find() and .children().

Is my router affected by the Heartbleed Bug?

A few days ago, a catastrophic security vulnerability with OpenSSL dubbed the “heartbleed bug” was disclosed by a Google employee. I will not go in the details since this article offers a fantastic explanation, but let’s just say it’s quite a big deal, and a lot of applications are affected.

Most sites have already started applying fixes and notifying their users, but aside from various websites, there are a few other devices that are affected, including routers.

If you are using DD-WRT build versions 19163 to 23882, then you are at risk and should update your router firmware immediately.

OpenWRT users are also affected according to various user reports. As for Tomato users, you are safe as long as you are using an official release, as pointed out by a reader in the comments.

If you have another router model, make sure it’s not using OpenSSL between versions 1.0.1 (excluding 1.0.1g) and 1.0.2. If your firmware uses OpenSSL and was built between 2012 and april 2014, it’s likely to be affected.

Was your router affected by the Heartbleed bug? Report your findings in the comments.