Google Authenticator in CakePHP3.x

Google Authenticator gets a new wave of interest from the web community, trying to put an extra layer on top of user authentication process. There’s a plethora of plugins and components that let you authenticate with Google, but most of them aim to OAuth and Google+ integration. Two-step auth gets aside.

I took few hours on research for the simple 2FA library available on the net and found TwoFactorAuth that already support Google URI QR-codes, that can be easily embedded into any framework/application running on PHP.

CakePHP3.x Integration

With few minor modifications it nicely got integrated into CakePHP 3.x framework. If you’re using CakePHP 3.x, you can install ‘develop’ branch, of CakeDC/Users plugin, and enable two-factor authentication with few minor modifications.

 <?php
 //config/app.php or any other config file that suites your app
 Configure::write('GoogleAuthenticator.login', true);
 /*
 some other custom configs you might need
 'GoogleAuthenticator' => [
            //enable Google Authenticator
            'login' => false,
            'issuer' => null,
            // The number of digits the resulting codes will be
            'digits' => 6,
            // The number of seconds a code will be valid
            'period' => 30,
            // The algorithm used
            'algorithm' => 'sha1',
            // QR-code provider (more on this later)
            'qrcodeprovider' => null,
            // Random Number Generator provider (more on this later)
            'rngprovider' => null,
            // Key used for encrypting the user credentials, leave this false to use Security.salt
            'encryptionKey' => false
        ],
*/
?>

When you enable it the CakeDC/Users Google Authenticator feature, upon ‘/login’ you will ll be redirected to ‘/verify’, where you should insert your verification code from the mobile app (Google Authenticator for Android).

If you’re already sharing a secret key with the website/app, you won’t have to synchronize an app with it. Otherwise, you’ll have to scan it first, as it’s described in the documentation. QR-code will appear on the ‘/verify’ action of the app.

Vim: statusline and git customizations

Working with lots of projects at the same time in qobo.biz, I started to get confused on which branch I’m currently working.

Going back to the terminal, to check the diffs and commits, became a time waste in my daily routine, so I took a break during lunch, to get my vim plugins an upgrade. The catch of the day is the following:

Vim-Airline

Vim-Airline is a powerful status/tabline facelift of a default statusline with lots of customizations, and useful information on the files you work with. It nicely fits solarized theme, has color shift on different modes:

vim-airline demo
vim-airline with solarized theme enabled
Vim-gitgutter

Vim-gitgutter – is currently my favorite. The plugin identifies on-the-fly differences in the files you’re working in.

gitgutter diff
gitgutter diff with numbers on
Vim-fugitive

And last, but not the least for today – git wrapper for vim – vim-fugitive. It comes very useful with its set of git commands that you can access directly from vim, for example:

* :Gblame - now you can blame yourself in all the bugs
* :Gstatus - what's the status?
* :Gbrowse - redirects you to repositories file in github/bitbucket
* :Gcommit - let the fun begin

And just to complete the list of cools stuff, I must mention tagbar, that I’ve been using for long time, and its phpctags addon, that can make your life easier with better PHP support.

To summarize it all, a bit of editors fun from Twitter:

Definition of “done”

It’s been a long way for the definition to get to this blog post, so i’ll choose the one which favors the most, meanwhile its revision history:

An example Story definition of done would look like this.

  1. All story should have automated acceptance test.
  2. The story should have working code supported by unit test that provide around 60 – 70 percent coverage.
  3. The story should have well defined acceptance criteria.
  4. The code must have been written as a pair or should be code reviewed.
  5. Code must be completely checked in to the source control system and the build should pass with all the automated tests running.
  6. The product owner must accept the story.
Sprint Definition of done:
  1. Product owner should have defined a sprint goal.
  2. All stories completed for the spring must be accepted by the product owner
  3. All the automated acceptance tests should be running for the stories in the sprint.
  4. All code should have been pair programmed or must have gone thorough a code review process.
  5. If there is a database involved, the database scripts must have been automated and tested.
Release Definition of done
  1. Product is deployed to the test box and makes it to staging
  2. Product has a formal release date.
  3. There are deployment documents for the release
  4. Training manuals are available for users.
  5. All stories for the release are completed and accepted.
  6. The release does not have any level one bugs.

code-07

 

PHP: Array vs ArrayObject benchmarking

Some measurements on Arrays vs ArrayObjects found among gist users. Just going to bring it here, in case gist dissappears.

# php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:58:15)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

# echo '<?php $s = array(); for($x=0;$x<1000;$x++){ $s[] = array("name"=>"Adam","age"=>35); }; echo memory_get_peak_usage(); ' | php
655040

# echo '<?php $s = array(); for($x=0;$x<1000;$x++){ $o = new ArrayObject; $o->name = "Adam";  $o->age = 35;  $s[] = $o;} echo memory_get_peak_usage(); ' | php
887984

# time echo '<?php $s = array(); for($x=0;$x<100000;$x++){ $o = new ArrayObject; $o->name = "Adam";  $o->age = 35;  $s[] = $o;} echo memory_get_peak_usage(); ' | php
61010784
real    0m1.448s
user    0m1.208s
sys     0m0.231s

# time echo '<?php $s = array(); for($x=0;$x<100000;$x++){ $s[] = array("name"=>"Adam","age"=>35); }; echo memory_get_peak_usage(); ' | php
33647944
real    0m0.525s
user    0m0.429s
sys     0m0.092s

We can conclude the following at least in PHP 5.6:

  • Winner for Speed: Arrays are faster than objects (with undefined or defined properties)
  • Winner for Memory: Objects with defined properties use less memory, 50%+ less than objects with undefined properties, only slightly less than Arrays

Ordered Fastest to Slowest in Speed for 100,000 items:

  • 0.107s – Arrays
  • 0.163s – Objects with undefined properties
  • 1.190s – Objects with defined properties

Ordered Least to Most Memory Usage for 1,000 items:

  • ~583kb – Objects with defined properties
  • ~807kb – Arrays
  • ~1.1mb – Objects with undefined properties

Qobo: first month benchmark

It’s been already one month since I moved to Qobo Ltd, as a backend developer, so it’s about time to do some benchmarks on the work done.

Open-Source

The level of open source involvement of Qobo is enormous. All the projects I’ve been involved in before were always about open-source: it was either based on open-source, or using open-source solutions into some extend. Every time it ends up locking down the solutions for indoor use. It was either features the company didn’t want to share with the open-source community, or key business aspects that were crucial for competitive advantage. The story repeats over and over – the level of feedback to open source was minimal.

Contrarily, Qobo’s approach towards open-source is different. I didn’t do the exact measures, but it’s approximately 70-80% of code that goes to public repositories. Apart of advocating open-source within the company, we participate in other development communities, which helps us get things better. What’s the point of getting stuck with yet another closed-source plugin/module/library that others troubleshooted/patched and use everywhere. Examples? Well, it’s CakeDC community, CakePHP framework, WordPress, Bootstrap, and many others.

Side-effects of it:

  • You write better code (if you want to get things accepted in pull requests)
  • You stand on the shoulders of giants (community helps. Always)
  • Self-development (you’re not stuck with repetitive tasks)
Teams

Q: how many programmers does it take to change a light bulb?

A: none, that’s a hardware problem (c)

Small teams, dedicated to certain projects or split by the expertise in certain technology or business aspects. Mind blowing speed of deployment & accuracy. The most appropriate way of describing the social system and involvement in the projects would be meritocracy – “We do it, because we can”.

 

Yarn: package manager for JS modules

Yarn kitty rocks!
Yarn kitty rocks!

Yarn is a package manager for your code. It allows you to use and share code with other developers from around the world. Yarn does this quickly, securely, and reliably so you don’t ever have to worry.

Yarn allows you to use other developers’ solutions to different problems, making it easier for you to develop your software. If you have problems, you can report issues or contribute back, and when the problem is fixed, you can use Yarn to keep it all up to date.

From hardware to software: key points

Absolutely great article by Seth Godin on hardware/software perspectives looking at the giants, like Apple. Few points need to be quoted:

  • Software can change faster than hardware, which means that in changing markets, bet on software.
  • It’s tempting to treat the user interface as a piece of fashion, some bling, a sort of jewelry. It’s not. It’s the way your user controls the tool you build. Change it when it stops working, not when you’re bored with it. Every time you change the interface, you better have a really good reason.
  • Hardware always gets cheaper. If you can’t win that race, don’t run it.
  • Getting users is far more expensive than keeping users, which means that investing in keeping users is the smartest way to maintain your position and then grow.
  • Software can create connection, and connection is the engine of our future economy.

Base32 advantages over Base64

While working on Google Authenticator, stumbled upon these little facts, why base32 was chosen over base64 for shared secret key:

  1. The resulting character set is all one case, which can often be beneficial when using a case-insensitive filesystem, spoken language, or human memory.
  2. The Base32 result can be used as a file name because it can not possibly contain the ‘/’ symbol, which is the Unix path separator.
  3. The alphabet can be selected to avoid similar-looking pairs of different symbols, so the strings can be accurately transcribed by hand. (For example, the RFC 4648 symbol set omits the digits for one, eight and zero, since they could be confused with the letters ‘I’, ‘B’, and ‘O’.)
  4. Base32 result excluding padding can be included in a URL without encoding any characters.