Forem: Jesse Rushlow

You want to base what on my hmac?

Jesse Rushlow — Mon, 09 Mar 2020 02:26:58 +0000

A guide to shrinking an elephant hashed and encoded in PHP.

I was recently working on a new bundle for Symfony, and while reviewing a block of code I had written earlier I asked my self, why do the big guys (Symfony and Laravel) encode the binary output of hash_hmac() using base64_encode()?

After some digging around, I discovered the answer. But first lets take a look at how hash_hmac() works. More specifically, what hash_hmac() returns...

TL;DR

When overhead is a concern, using base64_encode(hash_hmac(..., true)) gives you a hash with a string length of 44 characters vs the 64 characters that hash_hmac(..., false) provides.

What is this hash hmac and why do I care about it?

From the manual - "hash_hmac — Generate a keyed hash value using the HMAC method"

Translation, this method allows us to take a string of data, and potentially create a cryptographically secure hash that can be used to verify the data integrity. One thing to remember about hash_hmac, it's selfish. hash_hmac takes the data and gives you a string (hash), but it will never give you the data used to create that hash.

This is sometimes referred to as a one-way hash. Meaning the only way we can verify the integrity and authenticity of the data, is to create a new hash and then compare the original hashed value against our newly created hash. To do this we use the hash_equals() method.

To put it another way, lets play the game telephone. You remember that as a kid right? A large group gets in a circle and then the first kid says to his buddy on the left, "elephants are gray". Then his buddy does the same to the kid to his left, and so on and so on. The point of that game is to see if the phrase is still the same by the time it circles back around to the first kid.

Only in our version of the game, I'm going to start the game and use hash_hmac to prove to everyone at the end, I'm not fibbing...

$elephantHash = hash_hmac('sha256', 'elephants are gray', 'secret_key'); 
var_dump($elephantHash);
// string(64) d53c1002ddf2159b926ae4eaf775fb0242282e826070bb79a899bbf1af45642f

So the phrase is "elephants are gray", go tell a friend what the phrase is and have them repeat it to me. Hurry, I'm waiting...

While I'm waiting to hear back from your friend, I'll show you how I'm going to verify the original phrase. First, there are 3 required arguments hash_hmac() needs. The first is the algorithm, algo, that will be used to create the hash. sha256 is a good place to start, but be sure to follow best practices when picking which algorithm best fits your use case.

The second argument is the data string. This string is what will actually be hashed. In our case, we are hashing 'elephants are gray'. Lastly, we have to provide the third, key, argument that is used to generate the hash. The key, similar to a salt, must be kept secret. If you're using a framework like Symfony, APP_SECRET could be used as your key. So long as it's never exposed.

There is a 4th optional argument to hash_hmac(), raw_output, but I'll get to that later. Meanwhile, let's see what happens when we create a second hash using 'elephants are gray' as the data string again and compare it to the first.

// verifyElephantColor()
$secondGrayElephant = hash_hmac('sha256', 'elephants are gray', 'secret_key');

function verifyElephantColor($knownElephant, $suspiciousElephant): string
{
    if (hash_equals($knownElephant, $suspiciousElephant) {
        return 'We have 2 gray elephants';
    }

    return 'Ooops, one of the elephants changed color';
}

The verifyElephantColor() method above would return We have 2 gray elephants. This is because our, $secondGrayElephant, is using the same algorithm, data, and key as $elephantHash.

That was quick! Your friend just said to me 'elephants are pink'. Hmm, something seems fishy about this. I don't remember telling you the PHP elephant is pink... Let's find out for sure by calling the verifyElephantColor() method again.

$pinkElephant = hash_hmac('sha256', 'elephants are pink', 'secret_key');
echo verifyElephantColor($elephantHash, $pinkElephant);

// Ooops, one of the elephants changed color

AH HA! See, I never said elephants are pink! Since the data supplied to hash_hmac() differs from the original data used to create $elephantHash, we are given a different hashed string. The same holds true if a different algo or key were used.

How can we leverage PHP to shrink an elephant?

Now that you know how to create a hash with hash_hmac and verify the hash with another, using hash_equals(), let's see if we can get that elephant to shed a pound or two. Remember that fourth and optional argument, raw_output, I mentioned earlier? The documentation states that when raw_output is set to true, it will return raw binary data. Let's have a look at that...

Inner workings of hash_hmac:

Diving into the PHP source code, specifically php-src/ext/hash/hash.c, we eventually find the hash_hmac declaration and see that it calls the internal php_hash_do_hash_hmac() function.

PHP_FUNCTION(hash_hmac)
{
    php_hash_do_hash_hmac(INTERNAL_FUNCTION_PARAM_PASSTHRU, 0, 0);
}

Without getting into the nitty gritty of exactly how the php_hash_do_hash_hmac function generates a hash, we can skip down to the return logic:

//php_hash_do_hash_hmac()

if (raw_output) {
    ZSTR_VAL(digest)[ops->digest_size] = 0;
    RETURN_NEW_STR(digest);
} else {
    zend_string *hex_digest = zend_string_safe_alloc(ops->digest_size, 2, 0, 0);

    php_hash_bin2hex(ZSTR_VAL(hex_digest), (unsigned char *) ZSTR_VAL(digest), ops->digest_size);
    ZSTR_VAL(hex_digest)[2 * ops->digest_size] = 0;
    zend_string_release_ex(digest, 0);
    RETURN_NEW_STR(hex_digest);
}

Then strip away some of that C code that is irrelevant in the context of this explanation:

if (raw_output) {
    RETURN_NEW_STR(digest);
} else {
    php_hash_bin2hex(ZSTR_VAL(hex_digest), (unsigned char *) ZSTR_VAL(digest), ops->digest_size);
    RETURN_NEW_STR(hex_digest);
}

When we call hash_hmac() in PHP, the 4th raw_output argument is used in this if/else block. So if raw_output = true, php_hash_do_hash_hmac() returns us a nice chunk of binary code. If your business logic consumes binary, proceed no further. If binary isn't in your taste buds, use the default value, false, for raw_output.

When raw_output = false, we can see that the digest (binary representation) is passed to php_hash_bin2hex() who's return value is ultimately returned by php_hash_do_hash_hmac(). Sound familiar? php_hash_bin2hex() is actually the internal function called by bin2hex() that we use in userland code.

In short, hash_hmac() returns either a binary or hexit representation of the data passed to the function depending on the value of raw_output.

Ok, I'm not seeing the point yet...

Don't worry, I'm getting to it now. Using the example from above -

$elephantHash = hash_hmac('sha256', 'elephants are gray', 'secret_key'); 
var_dump($elephantHash);
// string(64) d53c1002ddf2159b926ae4eaf775fb0242282e826070bb79a899bbf1af45642f

We now know that our $elephantHash value is actually a 64 character length string that was ultimately returned from bin2hex(). I'm a huge fan of using the least amount of data possible, especially when I have to store that data in a data store such as MySQL.

Let's try this instead -

$elephantHash = hash_hmac('sha256', 'elephants are gray', 'secret_key', true);
// $elephantHash <- binary representation of the hashed 'elephants are gray` data string because we set true as the raw_data argument.

$skinnyElephant = base64_encode($elephantHash);
var_dump($skinnyElephant);
// string(44) "1TwQAt3yFZuSauTq93X7AkIoLoJgcLt5qJm78a9FZC8="

$skinnyElephant has a string length of 44 characters while $elephantHash is 64 characters.

Holy Elephant, you've lost 20 characters! How can this be?!

In a brief discussion with Sara Golemon, one of PHP's core developers, she provided 2 key takeaways in respect to encoding the binary result of hash_hmac() using base64_encode() vs hash_hmac(..., false);

Neither version is more or less secure than the other. Each has effectively* 256 bits of entropy.

bin2hex() increases the size of the string its given by 2:1, base64_encode() increases the size of the input by about 4:3**.

* It's actually slightly lower than 256bit for math reasons, but the actual entropy of both is precisely equal. They're just different representations of the same data.

** Depends on input block alignment which is based on 3 octets. sha256 isn't an exact multiple of blocks, so the expansion is actually 11:8, which is still well below 2:1.

Why does any of this matter?

As we can see above, using base64_encode(hash_hmac(..., true)) results in, approximately, a 31% smaller "footprint" as compared to using hash_hmac(..., false). If you're developing an application that doesn't care about how much storage space, or I/O is being utilized in a data store, then either of the 2 method's will suite your needs perfectly fine.

However, if scalability, storage space, network performance, etc... are of any concern to you, use base64_encode(hash_hmac(..., true)). This will ultimately reduce overhead and utilize less space in persistence while, theoretically speeding up network calls and app performance. The smaller the data, the faster the data can be consumed.

Footnote

I'm not a security expert... I'm a developer just like you. Use the information I have conveyed in this article with a bit of common sense. I.e. don't go using hash_emac('sha256'...) to secure the admin panel of your retirement fund... You get the picture.

Lastly I'd like to thank Sara Golemon for taking a few minutes to verify and answer a few thoughts/questions I had that led up to this article. Keep up the great work you do for the PHP community!

As always, any comments, questions, and/or constructive criticism are always welcome.

Jesse Rushlow jr (at) rushlow (dot) dev @JesseRushlow

Oops, I forgot to sign my commit from last Monday...

Jesse Rushlow — Tue, 28 Jan 2020 13:44:17 +0000

How to interactively use git rebase to fix unsigned GPG commits.

This is mainly a "post-it note to self" as I usually don't forget to sign my git commits, but occasionally I run into issues where I don't notice a commit has not been signed until 30 commits later. Here's the solution...

TL;DR

git rebase -i ID_OF_COMMIT_BEFORE_FIX
change pick to edit for the commit(s) needing a GPG signature and save.
git commit --amend --no-edit -S
git rebase --continue

The Backstory

In my usual workflow, especially when working with software that utilizes Git Flow like branches, I use GitKraken for visualization of the git structure.It has a nice UI and does a great job at presenting git repositories. But it does lack some "advanced" features to be truly useful to me. Such as handling complex GPG / SSH key setup's. (More on that in a future post)

This morning I was working on geeshoe/atom, a PHP library to to generate fully compliant RFC4287 RSS/Atom feeds (Currently in initial development). I had mistakenly performed a cherry pick using GitKraken. I say mistakenly because as I mentioned previously, GitKraken doesn't recognize my GPG key setup, so while it did perform the cherry pick, GitKraken didn't actually sign the commit. I didn't notice this until after I had pushed a PR up to GitHub and seen one of my commits didn't have the green "verified" tag. Dang it!

Are my commits signed?

In the CLI, git log --show-signature let's you know...


user@host:~/document$ git log --show-signature

commit 4ff30a5... (HEAD -> master)
gpg: Signature made Tue 28 Jan 2020 05:36:27 AM EST
gpg: using RSA key ...741096D2ADE04CA
gpg: Good signature from "Jesse Rushlow <jr@geeshoe.com>" [ultimate]
Author: Jesse Rushlow <jr@geeshoe.com>
Date: Tue Jan 28 05:36:01 2020 -0500

    updated doc

commit 95f8587...
Author: Jesse Rushlow <jr@rushlow.dev>
Date: Tue Jan 28 05:21:15 2020 -0500

    ignore ideas

commit c772d80d...
gpg: Signature made Tue 28 Jan 2020 05:19:33 AM EST
gpg: using RSA key ...741096D2ADE04CA
gpg: Good signature from "Jesse Rushlow <jr@geeshoe.com>" [ultimate]
Author: Jesse Rushlow <jr@geeshoe.com>
Date: Tue Jan 28 05:19:28 2020 -0500

    Initial commit

I've modified the output above for readability but as you can see, the first (Initial commit) & the third (updated doc) commits were both signed using my GPG key. The second commit (ignore ideas) however was not signed.

The fix

As the above scenario doesn't happen often to me, I always seem to forget how to sign previous commits without getting into a git mess. After doing some googling, rebasing hit's me square in the forehead. Duh!

The key is that we want to begin the rebase at the commit just before the commit which needs to be modified. In this case it will be the initial commit c772d80. We also want to rebase interactively.

git rebase -i c772d80 will open a text editor that will allow use to tell git which commit we want to modify.


user@host:~/document$ git rebase -i c772d80

Editor:

pick 95f8587 ignore ideas
pick 4ff30a5 updated doc

# Rebase c772d80..80753f3 onto c772d80 (3 commands)
#
# Commands:
..........

We are going to change pick to edit for pick 95f8587 ignore ideas within the editor and save as shown below.


Editor:

edit 95f8587 ignore ideas
pick 4ff30a5 updated doc

# Rebase c772d80..80753f3 onto c772d80 (3 commands)
#
# Commands:
..........

Git will then bring you back to the command prompt and halt at the commit that needs editing:


user@host:~/document$ git rebase -i c772d80

Stopped at 95f8587... ignore ideas
You can amend the commit now, with

  git commit --amend '-S'

Once you are satisfied with your changes, run

  git rebase --continue

user@host:~/document$

Now we can sign the commit using git commit --amend --no-edit -S

--amend Amend the previous commit.

--no-edit Use the existing commit message. No need to edit it.

-S GPG-sign the commit. If you need to specify the GPG key to use, -S[<keyid>] is more appropriate.

After running the above command, git will output something similar to the following:


user@host:~/document$ git commit --amend --no-edit -S

[detached HEAD c11cc9e] ignore ideas
 Author: Jesse Rushlow <jr@rushlow.dev>
 Date: Tue Jan 28 05:21:15 2020 -0500
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore

user@host:~/document$

We can now go ahead and finish up the rebase with git rebase --continue & if all goes well, git will tell you that the rebase was successful. To verify that we signed the commit, git log --show-signature should now show the GPG signature:


user@host:~/document$ git rebase --continue
Successfully rebased and updated refs/heads/master.

user@host:~/document$ git log --show-signature
...

commit c11cc9e...
gpg: Signature made Tue 28 Jan 2020 05:58:38 AM EST
gpg: using RSA key ...741096D2ADE04CA
gpg: Good signature from "Jesse Rushlow <jr@geeshoe.com>" [ultimate]
Author: Jesse Rushlow <jr@rushlow.dev>
Date: Tue Jan 28 05:21:15 2020 -0500

    ignore ideas

...

user@host:~/document$

You're all set! Happy coding...

Word to the wise...

If you have already pushed the unsigned commit upstream to github as I did, care should be taken before using the above described method. As there could be negative consequences.

First, after performing the rebase, you will more than likely have to force push the branch upstream to github. If this is a feature branch that hasn't been merged / modified by others, forcing the push shouldn't cause any headaches.

If there have been modifications to the branch / PR upstream, you may want to revert the commit, and just create a new signed commit rather than doing a rebase. If all else fails, you can always let the unsigned commit ride solo as a reminder not to make that mistake again...

As always comments, rants, suggestions, and constructive criticism are always welcome.

Jesse Rushlow jr@rushlow.dev

Unit and Functional tests, huh?! Whats the difference?

Jesse Rushlow — Fri, 17 Jan 2020 23:32:34 +0000

How and why you should separate your PHP test suites.

I recently attempted to answer a question on stack overflow in regards to PHPUnit testing. Although I feel I wasn't able to convey my answer in a understandable way. So what better way than to try again here...

Unit tests vs Functional Tests

A unit test is a test written that checks the behavior of a specific isolated block of code, without depending on the real input from external dependencies. So what are external dependencies? Anything outside of the method/function under test that said method/function relies upon. I.e. a different class method within the codebase, an API response from another server, etc... In unit testing, mocking dependencies allows us to test a code block without having to rely upon it's dependencies.

A functional test on the other hand is a test written to ensure that all of the code within a code base interacts with each other and its dependencies as expected. When writing functional tests, you don't usually mock your dependencies. More on this below.

Unit Tests

Look at the following two classes. In all, \Store::class has one dependency,\FruitBasket, and \FruitBasket has a dependency of it's own,\Connection::class, which provides a connection to a "server far away".

class FruitBasket
{
    public $serverFarAway;

    public $fruitArray = ['apple', 'orange']

    public function __construct(\Connection $serverFarAwayConnection)
    {
        $this-serverFarAway = $serverFarAwayConnection
    }

    public function getByType(string $type): string
    {
        $key = in_array($type, $this->fruitArray);

        if (!$key) {
            return $this-fruit[$key];
        }

        return $this->getFruitByTypeFromServerFarAway($type);
    }

    protected function getFruitByTypeFromServerFarAway(string $type): string
    {
        return $this-serverFarAway->getFruit($type);
    }
}

class Store
{
    public $basket;

    public function __construct(\FruitBasket $basket)
    {
        $this->basket = $basket;
    }

    public function getFruit(string $typeOfFruit): string
    {
        return $this-basket->getByType($typeOfFruit);
    }
}

To unit test \Store::class, we must mock \FruitBasket before testing the\Store::getFruit() method.

//UnitTest.php

use PHPUnit\Framework\TestCase;

class UnitTest extends TestCase
{
    public function testGetFruitReturnsOrangeWhenOrangeIsTheParam(): void
    {
        $mockBasket = $this-createMock(\FruitBasket::class);
        $mockBasket->expects($this-once())
            ->method('getByType')
            ->with('orange')
            ->willReturn('Orange')
        ;

        $store = new Store($mockBasket);
        $result = $store->getFruit('orange');

        self::assertSame('Orange', $result);
    }
}

The above test is actually performing 2 assertions. The first, self::assertSameis obvious. We are testing that $store->getFruit() returns the result from\FruitBasket::getByType(). The 2nd assertion is that \FruitBasket::getByType()is actually being called by \Store::getFruit() exactly 1 time. We are also ensuring that when we call \Store::getFruit('orange'), our 'orange' parameter is being passed to \FruitBasket::getByType(). We are accomplishing this without actually using a real \FruitBasket object in the test.

The next unit tests we would write would be for \FruitBasket::class;

//UnitTest2.php

use PHPUnit\Framework\TestCase;

class UnitTest2 extends TestCase
{
    public $mockConnection;

    protected function setUp(): void
    {
        $this-mockConnection = $this-createMock(\Connection::class);
    }

    public function testGetByTypeReturnsFruitInFruitAway(): void
    {
        $expectedResult = 'apple';

        $basket = new \FruitBasket($this-mockConnection);

        $result = $basket->getByType('apple');

        self::assertSame($expectedResult, $result);
    }
}

We are essentially doing the same as before, expect this time we are using the inheritedTestCase::setUp() method. setUp() allows us to create a fresh mock of the\Connection::class before each test is run. Of course we need the \Connection::classto create a new \FruitBasket::class instance.

Now we could write more tests for the different edge cases that are possible for\FruitBasket. We could also write assertions for the \Connection:class mock to ensure that if a fruit is not found in $fruitArray,\Connection::getFruitByTypeFromServerFarAway() is called with the $typeparameter. You would write those assertions just as I did in the previous example.

Functional Tests

After we have written our unit tests to ensure each individual method performs as expected, it's time to test if both classes work together as expected. There are 2 ways to go about this. The first, in true functional test form, would be to use a real \Connection::class to connect us to a "server far way."

The upside to this, is we don't have to write mocks out for \Connection::classand we will be absolutely sure that all the code act's as expected in a perfect world. However, for every upside there's a downside. First, if \Connection::classis providing us a connection to a MySQL server or API connection that we can't control, which is often the case in the real world; We wouldn't want to be hitting those resources over and over again with our test suite. Think rate limiting for API's.

Second, who knows what data exists on the "server far away" servers. What if 6 months from now, there were no more bananas left, and we needed to test if we called\Store::getFruit('banana), \FruitBasket::getFruitByTypeFromServerFarAway returned us a banana in our functional test.

How do we overcome this? My approach is to use a modified version of Functional Testing. If possible, I will replicate the external resource. I.e. create a MySQL docker container that has bananas in a table. Or, just use a mock \Connection::classobject for all but a few of my functional test methods. You could also mock\Connection::class for all of your Functional tests and utilize a real connection in a separate Functional Test suite or even use a real connection only in your acceptance tests. How you do it all depends on your code base and what external dependencies you are relying on. There is no single "right way" to do it.

But for this example, I'm going to mock our \Connection::class in the functional tests because \Connection::class provides a connection to a server which I don't control and has rate limits.

//FunctionalTest.php

use PHPUnit\Framework\TestCase;

class FunctionalTest extends TestCase
{
    public $mockConnection;

    protected function setUp(): void
    {
        $this-mockConnection = $this-createMock(\Connection::class);
    }

    public function testGetFruitReturnsFruit(): void
    {
        $fruitBasket = new \FruitBasket($this-mockConnection);
        $store = new \Store($fruitBasket);

        $result = $store->getFruit('apple');

        self::assertSame('apple', $result);
    }
}

In the example above, we are testing the \Store::getFruit() and \FruitBasket::getByType()interact with each other as expected. But what happens when \FruitBasked->$fruitArraydoesn't contain the desired fruit?

//FunctionTest.php

use PHPUnit\Framework\TestCase;

class FunctionalTest extends TestCase
{
    public $mockConnection;

    protected function setUp(): void
    {
        $this-mockConnection = $this-createMock(\Connection::class);
    }

    public function testGetFruitReturnsFruit(): void
    {
        ....
    }

    public function testGetFruitReturnsBananas(): void
    {
        $this-mockConnection->method('getFruit')
            ->willReturn('Banana')
            ->with('banana')

        $fruitBasket = new \FruitBasket($this-mockConnection);
        $store = new \Store($fruitBasket);

        $result = $store->getFruit('banana');
        self::assertSame('Banana', $result);
    }
}

We are still using a mock connection, but we a doing it while running a functional test. As \Store::class is utilizing a real \FruitBasket::class instance within the test.

Final thoughts

The key take away is unit tests should not interact with any real dependencies where as functional tests can and should where possible.

A few may argue that you shouldn't use mocks at all in functional tests. And that is true to a point. But in the examples above, \Connection::class is an external dependency that should be tested in it's own code base. And as such, mocking it is safe in this use case. As the developer, you should pick external dependencies that are thoroughly tested and maintained regularly before implementing them in your own code base.

I hope this helps. As always, comments, rants, suggestions, and constructive criticism is always welcome.

Jesse Rushlow jr (at) rushlow (dot) dev

Overflow reality check

Jesse Rushlow — Thu, 09 Jan 2020 04:09:35 +0000

The misadventures of a compound problem involving css, cache, and cross-browser support.

TL;DR

Overcome overflow with long strings in a pre tag with:

pre {
  white-space: pre-wrap;
  white-space: -moz-pre-wrap;
  white-space: -o-pre-wrap;
  overflow-wrap: break-word;
  word-wrap: break-word;
  word-break: break-word;
}

The Problem

After recording, editing, writing, and finally posting my article on how to create a Docker container to initiate PHP projects, I was pretty content with the result. I'm not a hollywood video producer or even an expert at creating tutorials of any kind. But I do just so happen to be pretty good at writing code, or so I thought...

Once I published the article to my site, rushlow.dev, I had to make a few tweak's to the final result, mainly to the articles CSS properties. Woohoo, all looks good! WRONG, a week after publishing I just so happened to pull up the article on my phone and realized something was off.

A few code snippets that I had enclosed in <pre>...</pre> were overflowing their container. This in turn caused my responsive design to become un-responsive; scroll bars appeared out of no where and the entire article was hard to read on my iPhone. So, as any developer in my shoes would do, I fired up my IDE and began toying with the code base to fix the problem. After a few minutes I discovered I had forgot to set white-space: pre-wrap; on the pre CSS property. Phew... Problem solved!

Prior to pushing my code, I had fired up Firefox & Chrome on my dev machine to make sure everything looked right. So far so good, using the built in dev tools, I played around with the viewport size and all is well. I then ran my tests, inspected the code, and merged the fix into production. Fire up Firefox on my iPhone again, and the problem is still there. A few explitives later, I found myself fussing with CSS once again.

To shorten this up a bit, one would think the iPhone version and the desktop version of Firefox, Chrome, etc.. would produce the same result regardless of the device you are using the respective app on. Nope! When I did my final check of the article while in staging, both in Firefox and Chrome, the overflow had disappeared. However while viewing the same code base in the same staging environment with the same browsers but on my iOS device, the problem kept reappearing.

The Fix

Part of the solution was to kick my self in the butt for breaking one of the golden rules while developing, especially anything related to CSS; disable any cache that may affect the desired result. Ahhhhhh, that's better. Now part of my problem has been solved. What I see on my iPhone is what I see on my desktop. GRRRR nope, nope, the result is improved but slightly different.

My pre tags are being wrapped accordingly but a few lines are still busting the container. It just so happens that the lines that are busting the container are long strings. white-space: pre-wrap; breaks a line at newline characters,<br>, and "as necessary to fill line boxes." What white-space: pre-wrap;doesn't do is break long strings to preserve width constraints. To do that you must use word-wrap: break-word;, which is an alias foroverflow-wrap: break-word;.

overflow-wrap: break-word; allows for a word to be broken at any arbitrary point and does not take into account soft wrap opportunities introduced by breaking up a word.

The last part of the fix is to account for browser specific styles. To do that, I added:

pre {
    white-space: -moz-pre-wrap;
    white-space: -o-pre-wrap;
}

Depending on your requirements, you can also add hyphens to word breaks withhyphens: auto. As my blog is mostly of a technical nature, auto hyphens would create more confusion in most situations where I utilize <pre> tags. For instance, in citing a command or url, if one were to copy and paste a string that was "auto hyphened", the user would immediatly say something is broken. Aswww.google.com is obviously not the same as www.go-ogle.com. Take this into consideration before applying CSS based auto hyphens.

My final thought on all of this is that to keep in mind a browser on one platform, Firefox/Chrome on Debian, will not behave the same on another platform. I.e. Firefox/ Chrome on iOS. Also, regardless of how long you've been writing code, always remember KISS. Keep it simple stupid! I often have to remind myself that the hardest of problems can be caused by the most simplistic solution that is right in front of your face. I.e. checking "disable cache" in a browser...

For more details on any of the referenced tags, checkout Chris Coyier's article at css-tricks & of course the MDN web docs.

PHP Workspace Container Part 1

Jesse Rushlow — Mon, 30 Dec 2019 23:58:10 +0000

TL;DR;

Create a docker container to provide PHP's CLI, Composer, Git, Node & Yarn that is not project specific and without the need to have any of the aforementioned tools installed on the host.

I'll be demonstrating how to accomplish this using Debian Buster as the host with docker and docker-compose already installed.

The source code for this project is available on GitHub

I use a directory structure on my host that allows me to store all of my PHP, Javascript, Python, etc. in separate folders organized by the project language. This allows me to have one workspace container per language. I.e.

- ~/develop/php
    - /symfony-app-1
    - /symfony-app-2
- ~/develop/python
    - /python-app

Creating our container

First we can go ahead and create our directory structure as follows:

cd ~/develop/php
mkdir workspace
touch .bash_aliases Dockerfile Makefile

- ~/php
    - .bash_aliases
    - Dockerfile
    - Makefile

Next, we'll define our docker image in the Dockerfile as follow's:

// Dockerfile

FROM php:7.4-cli-buster

RUN apt-get update && apt-get install -yqq \
    libzip-dev \
    zip \
    gnupg \
    git

# Install node and Yarn in workspace container
RUN curl -sL https://deb.nodesource.com/setup_12.x | bash && \
    curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add && \
    echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list

RUN apt-get update && apt-get install -yqq \
    nodejs \
    yarn

# Install composer & make compose global
RUN curl -s https://getcomposer.org/installer | php && \
    mv composer.phar /usr/local/bin/composer

# Create a regular user account to work from
RUN set -xe; \
    groupadd -g 1000 developer && \
    useradd -u 1000 -g developer -m developer && \
    usermod -p "*" developer -s /bin/bash

# Copy bash aliases defined on host to container
COPY .bash_aliases /home/developer/.bash_aliases

# Cleanup
RUN apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

# Set which account to use
USER developer

# Set working dir for container
WORKDIR /var/develop

Next, add any bash aliases that you want present within the workspace to .bash_aliases such as:

// .bash_aliases
alias la="ls -lah"

The above can be omitted if you prefer not to use any aliases, just remember to remove the COPY .bash_aliases /home/developer/.bash_aliases from the Dockerfile.

Create make targets

We could go ahead and fire up our container now without any issues using:

$> cd php/workspace
php/workspace:$> docker build . -t workspace:latest

....
Successfully built f6f89d2035c7
Successfully tagged workspace:latest

php/workspace:$> docker run -ti --rm --mount type=bind,src=/php,dst=/var/develop \
workspace:latest /bin/bash

developer@f6f89d2035c7:/var/develop$>

But that's a lot of typing every time we need to enter the workspace container. We could use bash aliases to make this easier, but that can get unwieldy if you manage a lot of docker containers. I have chosen to use make to simplify my docker life.

Edit your Makefile as follows:

// Makefile

.PHONY: build
build: ## Build docker workspace image
   docker build . -t workspace:latest

.PHONY: workspace
workspace: ## Launch workspace container bash shell
   docker run -ti --rm --mount type=bind,src=/path/to/develop/php,dst=/var/develop workspace:latest /bin/bash

Now all I have to do is call the make target's to build and launch the container like so:

php/workspace:$> make build
docker build . -t workspace:latest
Successfully built f6f89d2035c7
Successfully tagged workspace:latest

php/workspace:$> make workspace
docker run -ti --rm --mount type=bind,src=/path/to/develop/php,dst=/var/develop workspace:latest /bin/bash

developer@f6f89d2035c7:/var/develop$> WOOHOOO!

The best part about using make targets is portability. If you are managing several project's that each have their own docker images / containers, you can reuse the same makefile, with a little tweaking, across all of your projects. And best of all, it can be committed to your Git repo for others to use as well.

There are differences in how make works on linux based systems compared to Windows environments, but the principles are all the same.

Stay tuned for future video's in this series...

PHP 7.4 Typed Properties BC Problems

Jesse Rushlow — Fri, 27 Dec 2019 02:13:51 +0000

Prior to PHP 7.4, declaring property scalar types was done with DocBlocks as follows:

/ **@var int|null** /
public $id;

With typed properties introduced in PHP 7.4, the scalar type can now be set like this:

public ?int $id;

This is awesome, it cuts down on excessive boilerplate and the PHP interpreter will not allow an invalid value to be set on the property.

But, there are a couple caveats to be aware of...

Without setting a property type, one would be able to have a class property such as:

//class.php

<?php
class MyClass {

    / **@var int|null** /
    public $id;
}

And then call the property without any problems like:

//test.php

<?php
require('class.php');

$object = new MyClass;
$var = $object->id;

var_dump($var);

$:> php -f test.php
NULL

However if you declare the property type and then attempt to access that type as above, you'll get a FatalError. I.e.

//test.php

<?php
class MyClass {

    public ?int $id;
}

$object = new MyClass;
$var = $object->int;

echo $var;

$:> php -f test.php
Fatal error: Uncaught Error: Typed property MyClass::$id must not be accessed before initialization...

To overcome this, you must set the value of $id before attempting to access it. This can be accomplished in a number of ways.

class MyClass {

    public ?int $id = null;
}

class MyClass {

    public ?int $id;

    public function __construct() {
        $this->id = null;
    }
}

class MyClass {

    public ?int $id;

    public function setId(?int $id) {
        $this->id = $id;
    }
}

Using any of the above means of setting $id before accessing the value of $id would result in the following:

//class.php
<?php
class MyClass {

    public ?int $id = null;
}

$object = new MyClass;

$var = $object->id;

var_dump($var;)

$:> php -f class.php
NULL

Of course if you are using setter's to set the value of $id, you must call the setter method before accessing the property.