WordPress Plugins : Demo Data Creator

Here is a useful plugin for all of you, WordPress developers – Demo Data Creator.   It generates a whole lot of test / demo data and populates your WordPress site with it.  No more lengthy copy-pastes of Lorem Ipsum into posts and pages, single user (hi admin) installations, and senseless “foobar” and “foobar2” categories.  Now you can populate your test or development environment with lots of data to help with previews, and all those issues around search, pagination, and things like that.

demo-data-creator

If you’d rather avoid the plugin and automate this kind of work yourself, make sure to have a look at WP-CLI – command line interface for WordPress, which, among others, has the “wp post generate” command.

httpoxy – a CGI application vulnerability for PHP, Go, Python and others

httpoxy

httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments.

It comes down to a simple namespace conflict:

  • RFC 3875 (CGI) puts the HTTP Proxy header from a request into the environment variables as HTTP_PROXY
  • HTTP_PROXY is a popular environment variable used to configure an outgoing proxy

This leads to a remotely exploitable vulnerability. If you’re running PHP or CGI, you should block the Proxy header now.

The RegEx that killed StackOverflow

Here’s an outage postmortem from the recent StackOverflow downtime.  It just shows you how easy it is to break things, even they were built by some of the smartest people around.  Programming is touch and there is no way around it.

Technical Details

The regular expression was: ^[\s\u200c]+|[\s\u200c]+$ Which is intended to trim unicode space from start and end of a line. A simplified version of the Regex that exposes the same issue would be \s+$ which to a human looks easy (“all the spaces at the end of the string”), but which means quite some work for a simple backtracking Regex engine. The malformed post contained roughly 20,000 consecutive characters of whitespace on a comment line that started with — play happy sound for player to enjoy. For us, the sound was not happy.

If the string to be matched against contains 20,000 space characters in a row, but not at the end, then the Regex engine will start at the first space, check that it belongs to the \s character class, move to the second space, make the same check, etc. After the 20,000th space, there is a different character, but the Regex engine expected a space or the end of the string. Realizing it cannot match like this it backtracks, and tries matching \s+$ starting from the second space, checking 19,999 characters. The match fails again, and it backtracks to start at the third space, etc.

So the Regex engine has to perform a “character belongs to a certain character class” check (plus some additional things) 20,000+19,999+19,998+…+3+2+1 = 199,990,000 times, and that takes a while. This is not classic catastrophic backtracking (talk on backtracking) (performance is O(n²), not exponential, in length), but it was enough. This regular expression has been replaced with a substring function.

Composer magic

Now that everyone is super comfortable with composer, I thought I’d share these two gems which I didn’t know or think about.

composer info

This command lists all of your packages installed with composer.  This is super handy if you want to include a page in your project, listing all the libraries and versions which are currently installed.  It also gives you a description of each library as provided by the package.

composer outdated

This command lists packages which you are using, which have updates available.  With this you can have a better understanding of what will happen if you run composer update (depending on your composer.json of course).

Update (July 21, 2016): Guess what? There is even a way to combine the two with one command: composer info -l .  This will list all the packages, with their versions and descriptions, and with an additional column of the latest version for each package.

After a year of using NodeJS in production

There are days, when I feel jealous of all the young kids playing around with new technologies.  I need a certain level of stability and acceptance of the technology before I can apply it to client projects.  And I need time, which is a very scarce resource lately.

And yet there are days, when I feel good about being somewhat reserved and conservative in my technology stack choices.  Reading this blog post makes me feel just that.  Of course I need to try it out for myself and shape my own opinion, but with my lack of time, this should do.

I spent a year trying to make Javascript and more specifically Node work for our team. Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries and debugging trivial code more than anything.

Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.

I would however recommend Javascript for front-end development such as Angular or React (like you have another choice).

I would also recommend Node for simple back-end servers mainly used for websockets or API relay.

Now if only somebody wrote a similar post about Docker …