Welcome friend.

I recently discovered and disclosed some rather serious cross-site request forgery vulnerabilities to the security team at github at 2:30 AM =p, and they managed to get a fix implemented and rolled out by 10:30 AM. That is a truly badass turnaround and they should be fiercely commended for their work.

The vulnerabilities themselves were pretty chumpy though. There was nothing being done to stop someone from tricking a logged in user into deleting their repositories / replacing their email / password / etc. I am glad it was fixed so quickly, but less than ecstatic about it being there in the first place. Github has been around for long enough (firmly and very specifically in the web technologies fields) that this should not have been an issue.

Please be aware of csrf people, it will mess up your day.

John Resig tweeted the following:

Trying to get periods in Wordpress permalinks to work, but failing. How can I force WP to allow: http://example.com/foo.bar/

I was curious so I watched replies to him. There were many deeply misguided answers, my favorite being:

I’m not sure, but it seems like it might likely be a server configuration issue.

There was a reference to this: http://firsttube.com/read/hacking-wordpress-day-two/, but hacking the core is a pretty poor solution, and will be overwritten the next time you upgrade.

The periods get dropped by sanitize_title_with_dashes, and there is no clean way to hook into it and fix the problem, so you can just use remove_filter to drop it, and replace it with a very similar function that allows for periods:

remove_filter('sanitize_title', 'sanitize_title_with_dashes');
add_filter('sanitize_title', 'sanitize_title_with_dashes_allow_periods');
 
function sanitize_title_with_dashes_allow_periods($title){
        // same as sanitize_title_with_dashes minus the line replacing periods, 
        // and an alteration to the final catch all regex to allow periods
        // please note, might be dangerous for some reason?  i don't rightly know.
        $title = strip_tags($title);
        // Preserve escaped octets.
        $title = preg_replace('|%([a-fA-F0-9][a-fA-F0-9])|', '---$1---', $title);
        // Remove percent signs that are not part of an octet.
        $title = str_replace('%', '', $title);
        // Restore octets.
        $title = preg_replace('|---([a-fA-F0-9][a-fA-F0-9])---|', '%$1', $title);
 
        $title = remove_accents($title);
        if (seems_utf8($title)) {
                if (function_exists('mb_strtolower')) {
                        $title = mb_strtolower($title, 'UTF-8');
                }
                $title = utf8_uri_encode($title, 200);
        }
 
        $title = strtolower($title);
        $title = preg_replace('/&.+?;/', '', $title); // kill entities
        //$title = str_replace('.', '-', $title);
        $title = preg_replace('/[^\.%a-z0-9 _-]/', '', $title); // allow for periods
        $title = preg_replace('/\s+/', '-', $title);
        $title = preg_replace('|-+|', '-', $title);
        $title = trim($title, '-');
 
        return $title;
}

Please note that this could be dangerous, they might be removing periods for a good reason

So I am dicking around on lite.facebook.com, and I see this funny little icon in my footer:

I hadn’t seen it before so I looked into it. It linked to “http://lite.facebook.com/w/oarllz/~/toggle/”. Upon clicking this link, I was redirected back to http://lite.facebook.com except I had some kind of goofy debug terminal at the top, here it is:

note the highlighted “lobster lobster lobster”.

And here are some other notable screenshots:

“/var/www/zuesgodofthunder”, nice.

You should be able to see this yourself for the time being at least.

1. go to http://lite.facebook.com
2. log in.
3. use this link (sometimes it needs to be hit twice): http://lite.facebook.com/w/oarllz/~/toggle/
4. Page should redirect back to http://lite.facebook.com with the funny little terminal.

notes:

• This does only appear to work on lite.facebook.com
• Don’t use this to do anything bad.

This is just a little something I whipped up because I found it useful. Tips.Glossary is used for helpful tool-tips that gracefully degrade when JavaScript is not available for whatever reason. The basic idea is that you include an HTML glossary in the page, and if Tips.Glossary is available, the tips will come up however you specify, if not, they are simply anchors to their entries in the HTML.

This probably works with most MooTools stuff post 1.2, you are smart and will figure it out.

Check it out here.

Download the example.

or have a look at the code:

Selectors.Pseudo.hash = function(hash){
	if(!$chk(hash))
		return this.get('href').contains('#');
	var currentHash = this.get('href').split('#')[1];
	return currentHash === hash;
}
 
 
Tips.Glossary = new Class({
 
	Extends: Tips,
 
	options: {
		'anchorClass':	false,
		'hideGlossary':	true
	},
 
	initialize: function(glossary, options){
		this.parent(options);
		this.glossary = $(glossary);
		if(!$chk(this.glossary))
			throw "Glossary not found / defined, quitting";
		if(this.options.hideGlossary)
			this.glossary.setStyle('display', 'none');
		this.indexGlossary();
		return this;
	},
 
	indexGlossary: function(){
		this.items = this.glossary.getElements('*[id]');
		this.anchors = new Elements();
		this.items.each(function(e){
			var anchor = $(document.body).getElement('a:hash('+e.get('id')+')');
			if($chk(anchor)){
				if(this.options.hideGlossary);
				anchor.addEvent('click', function(event){
					new Event(event).stop();
				});
				this.setTipContent(anchor, e);
				this.anchors.push(anchor);
			}
			if(this.options.anchorClass)
				this.anchors.addClass(this.options.anchorClass);
			this.attach(this.anchors);
		}, this);
	},
 
	setTipContent: function(anchor, target){
		anchor.store('tip:title', target.get('title'));
		anchor.store('tip:text', target.get('html'));
		this.fireEvent('settingContent', [anchor, target]);
	}
 
});

On a side note, notice the psuedo selector being added. This has been added because for whatever reason, the following CSS3 selector is goofy:

$(document.body).getElements('a[href="http://trickeries.com"]'); // works
$(document.body).getElements('a[href="#glossary-username"]');    // does not work

Anyone have any idea why?

I have a long and tension filled past with WPMU (Wordpress multi-user).

My first major beef was that they forcibly eliminated ‘www’ from your site url. It was hard coded in the source to tear it out and redirect, even if you went well out of your way to define it with the ‘www’. This was part of their general participation in the following bullshit: http://no-www.org/

I had an ssl certificate on www. Lots of stuff blew up, and there were a few infinite loop redirects. I wasn’t happy, and this eventually led to some core edits. This has since been changed, you can read some of the complaints here: http://mu.wordpress.org/forums/topic.php?id=7593

My next problem was that lots of language shit was hardcoded, including emails. This is generally improving over time, however I still have problems translating everything, as there are now emails stored in the database as options, which leaves me with difficult translations. More core edits to sort this out.

The next issue that I encountered was that my term id’s were very quickly getting larger and larger, with no reasonable explanation. This is still the case, and I have no idea why. Refer to the following forum thread (with no replies or acknowledgement), which explains this issue in more detail: http://mu.wordpress.org/forums/topic.php?id=3308 and my solution: http://mu.wordpress.org/forums/topic.php?id=6759

The next issue is that the admin does not gracefully handle many users. For pages where it is displaying users, no pagination is used. So if you get a few thousand subscribers, you better believe your browser is in for a crash when even attempting to load any of those pages.

The most recent issue I have experienced is that you can no longer register subpages to the plugins.php page, unless you don’t want anyone but the admin to be able to use them. I have no problem with this in theory, but historically this has never been the case. Now you have to be an admin to even load the plugins page, so if you have a tool you want editors to use, it better be somewhere else. This is because the variables that handle the menu generation declare that you need to be able to install plugins, edit plugins, or activate plugins in order to see the page, which only admins are capable of doing. This was also a hell of a thing to figure out. I had to crawl through include after include with ‘die(‘made it here!’);’

I still very much appreciate the software. It is a huge piece of impressive, and its not something that they needed to share or support (It was developed for use with wordpress.com). I am sure is a bear and a half to work on and test.

I just need to vent sometimes.