Introducing embedded code snippets · GitHub

August 17th, 2017

Reference code in issues (or start a new issue) with embedded code snippets.

Introducing embedded code snippets · GitHub

Twitter

August 17th, 2017

Introducing Puppeteer: A modern Node.js API for headless Chrome. Built with ?? by the Chrome team.…

https://twitter.com/i/web/status/897844237902856197

Twitter

Trump Explains Who The Bad Guys Are In ’80s Movies from Brian

August 17th, 2017

RT @funnyordie: Trump Explains Who The Bad Guys Are In ’80s Movies

Trump Explains Who The Bad Guys Are In ’80s Movies from Brian

Twitter

August 17th, 2017

RT @funnyordie: Trump Explains Who The Bad Guys Are In ’80s Movies

Twitter

NIST Special Publication 800-63B

August 16th, 2017

New NIST guidelines for password security and authentication methods. Gets rid of many old password anti-patterns in favor of encouraging user-friendlier, simpler, but longer passwords. Recommends passwords have a minimum length of 8 characters (6 for numeric PINs), and allow pass-phrases up to *at least* 64 characters long. I’d probably want to go with 128 chars or more (after all, it will end up being cryptographically hashed before storage, anyways, so the length of the user’s original password is mostly irrelevant), but this is definitely a welcome improvement over all the bad “8-12 characters, with a mix of lowercase, uppercase, numbers, and special characters, except not *these* characters, and by the way you’ll have to change it in 90 days” patterns.

They also include recommendations for OTP (One-Time Password) and multi-factor authentication systems. Dry reading, but I hope that many organizations will start to follow these recs and get rid of current bad password practices.

NIST Special Publication 800-63B

Instagram: Current status: CiderCoding. #cider #code #webdev #moblog

June 5th, 2017

Current status: CiderCoding. #cider #code #webdev #moblog

Instagram: Early morning rainbow on my street. #moblog

May 25th, 2017

Early morning rainbow on my street. #moblog

Introducing Rapscallion

March 6th, 2017

Rapscallion is an asynchronous server-side rendering engine for ReactJS.

Introducing Rapscallion

How to make your React Native app respond gracefully when the keyboard pops up

February 28th, 2017

A few methods for gracefully auto-scrolling your form in React Native when the keyboard is needed for text inputs.

How to make your React Native app respond gracefully when the keyboard pops up

Good Breakdown of Recent WordPress Vulnerability

February 8th, 2017

The Sucuri Blog has a good dissection of the recent critical WordPress REST API vulnerability. I won’t rehash the details here, but I did want to point out that this is why developers should remember to follow these two rules of defensive programming:

  1. Sanitize inputs as early as possible
  2. Sanitize outputs as late as possible

In this case, there was a failure to follow the first rule. There are a couple of different places where this could have been handled better.

For one, unless there is a good reason to allow GET or POST variables to override a URL placeholder parameter, then that should be handled appropriately. If there is a reason for it, then those values should be forced to comply with the regular expression or data type that is expected.

The other failure, beyond simple sanitizing, is that the logic of the update_item_permission_check() method simply didn’t properly account for the failure to retrieve a valid result from get_post(). This function will return post data either as an object or an array (depending on parameters), or null upon failure. The logic of the first conditional was looking for a valid post and invalid permissions on the post as an error condition:

if ( $post && ! $this->check_update_permission( $post ) ) {
    return new WP_Error( 'rest_cannot_edit', 
        __( 'Sorry, you are not allowed to edit this post.' ), 
        array( 'status' => rest_authorization_required_code() ) );
}

Instead, it should have reversed the valid post logic, and looked for not a valid post, or invalid permissions:

if ( ! $post || ! $this->check_update_permission( $post ) ) {
    return new WP_Error( 'rest_cannot_edit', 
        __( 'Sorry, you are not allowed to edit this post.' ), 
        array( 'status' => rest_authorization_required_code() ) );
}

And for good measure, it should probably check whether the return value was an instance of WP_Error, for future-proofing. This small change would have detected an invalid post ID, and still performed a valid permissions check for existing posts.

Okay boys and girls, let’s say it all together now… “Security is hard.”