Prevent JavaScript links by parsing URLs

If you have a website that allows users to submit URLs, one of the (many many) things people will try to do to break your site is to submit URLs that use the javascript: protocol (rather than the more expected http: or https:). This is almost never something that you want, since it allows users to submit essentially arbitrary code that other users will run on click in the context of your domain (same origin policy).

So how do you fix it?

First thought would be to try to check the protocol:

> safe_url = (url) => !url.match(/^javascript:/)
[Function: safe_url]

> safe_url('http://www.example.com')
true

false


Today I found the need to look through all old versions of a file in S3 that had versioning turned on. You can do it through the AWS Console, but I prefer command line tools. You can do it with awscli, but the flags are long and I can never quite remember them. So let’s write up a quick script using boto3 (and as a bonus, try out click)!

I have a large number of keyword bookmarks in whichever browser I happen to be using at the time that I’ve been building up over the years1. One of the ones I particular enjoy is text: data:text/html, <html contenteditable>. What that does is open a new tab where I can take notes, completely locally. It’s really handy… but there’s one big problem: I often accidentally close the tab and lose whatever I had been typing. So I decided to take a few minutes to write up a simple extension of the idea that would save the data to LocalStorage.

Inlining plaintext attachments in Gmail

When you send a text message to a Gmail email address (at least from an iPhone using AT&T), you get something like this:

It’s vaguely annoying to have to click through every single time just to see what the message is, especially when various extensions (such as uMatrix) break overlay rendering or when you have multiple attachments.

Much better would be to just display the plaintext attachments inline:

Ludum Dare 30: Demo mode

Quick update this morning: I managed to get a ‘demo mode’ working. Now when you first start the game, the boxes will be whizzing around in the background giving you an idea of what you’re about to get yourself into!

Ludum Dare 30: Programmer art and simple AI

A few hours later and we’ve already finished (or at least made good progress on) two of the goals that I was hoping for:

• AI players; at the very least one that moves randomly, but optimally several different kinds
• Pending the previous, a selector on the options screen that can turn each player either off, on, or to any of the current AIs
• Stylings around the page; probably some sort of thick border that bleeds a little in and out, looking different per player

Ludum Dare 30: 24 hours

Here we are, 24 hours into the competition.

A lot of the last few hours has been spent doing a fair amount of restructing. Before, I had a single ‘thread’1 for each of the tiles, along with another thread listening for user input. Unfortunately though, that lead to all sorts of race conditions. Specifically, whenever two tiles overlapped, it was often the case that one was doing the falling step (which copies from one internal buffer to another) while the other was in the swap step (which copies from tile to another). Then after the first finished, it would copy the second buffer over… overwriting anything that had been swapped.

Oops.

Ludum Dare 30: Hints of a game

We’re getting there. 18 hours in and I have the first hints of what might actually be a game…