2 minutes

Laravel 5 introduces the concept of “bootstrappers”, which are classes whose sole purpose is to setup the application. This new layer of abstraction makes many of the initialization code of the application modular and portable, so if you want to replace or change how a part or the whole initialization process, you can!

Update: The behavior implemented in the fragment below is now implemented by default in the following commit 7b4e918. You can still use the code below to define your own custom logger

The following is an example of a bootstrap class that replaces the regular logging service, with a logger that uses daily files (keeps one different file per day automatically):


namespace App\Bootstrap;

use Illuminate\Log\Writer;
use Monolog\Logger as Monolog;
use Illuminate\Contracts\Foundation\Application;

 * Class ConfigureLogging
 * Setup Custom Logging
 * @package App\Bootstrap
class ConfigureLogging
     * Bootstrap the given application.
     * @param  \Illuminate\Contracts\Foundation\Application  $app
     * @return void
    public function bootstrap(Application $app)
        $logger = new Writer(new Monolog($app->environment()), $app['events']);

        // Daily files are better for production stuff

        $app->instance('log', $logger);

        // Next we will bind the a Closure to resolve the PSR logger implementation
        // as this will grant us the ability to be interoperable with many other
        // libraries which are able to utilize the PSR standardized interface.
        $app->bind('Psr\Log\LoggerInterface', function ($app) {
            return $app['log']->getMonolog();

        $app->bind('Illuminate\Contracts\Logging\Log', function ($app) {
            return $app['log'];

Once the bootstrap is defined, you can override the $bootstrappers field on both the Http and Console Kernels:

 * The bootstrap classes for the application.
 * @return void
protected $bootstrappers = [

NOTE: Laravel 5 is under active development. This method might not work on the final release. Also, once you override the $bootstrappers variable you need to make sure it stays up to date with Laravel’s code (at least while it is non-stable) since they could rename some of these classes.

1 minute

The current version ZURB’s Foundation (A CSS framework) doesn’t style form checkboxes and the final look is always the browser default, which can look good or bad depending on your OS.

I like to have a more consistent look on my apps, especially on those that use checkboxes for selecting which items from a table to apply certain action to.

I use the following SCSS to style checkbox input elements. The original code was based from the look of checkboxes in Gmail although it was slightly more rounded. I’ve adapted it so that it fits better in Foundation (square corners), plus it will also use your $primary-color when it is highlighted:

The final result should look something like this:

foundation checkbox

2 minutes

SSL 3 is broken

Earlier this week Google released details on a new security flaw that some of their researchers found in SSL version 3.0.

POODLE, the name given to this vulnerability, stands for “Padding Oracle On Downgraded Legacy Encryption”. Attackers using POODLE can gain access to plaintext in some areas in a SSL connection. This could be used to extract important information such as a session cookie, which would allow the attacker to hijack an account and pretend to be that user.

Unlike Heartbleed and Shellshock, which were two other major vulnerabilities found this year, POODLE is not something that you can protect yourself against with a single patch, at least when it comes to servers.

Google has already stated that they will be phasing-out support for SSL 3.0 in all their products, which includes Google Chrome. SSL 3.0 can also be manually disabled on most browsers right now.

For servers, guides have been published on how to disable the protocol on popular web server software such as Apache and Nginx. However, I haven’t seen many articles on the web on how to fix this on Node.js.

Luckily, I stumbled upon this useful post by @3rd-Eden on GitHub:

Protecting against POODLE in node.js

Patching the vulnerability is very simple, but it does require modifying your code:

Step 1: Check if the server allows SSL 3.0:

On Unix systems, you can use the openssl client to quickly check if a server is vulnerable:

openssl s_client -ssl3 -connect <hostname>:443

If the client is able to do a successful handshake, then it is very likely that the server is vulnerable to POODLE.

Step 2: Disable SSL 3.0 on the server settings object

If your server is accepting SSL 3.0 connections, you will need to find where the https.createServer() function is being called.

Once you have located the file, you will need to load in the constants module:

var constants = require('constants');

Then locate the options object provided as the first argument to createServer() and add the following lines to the options object:

var options = {
	secureProtocol: 'SSLv23_method',
	secureOptions: constants.SSL_OP_NO_SSLv3,

var server = https.createServer(options, app);

This configuration will disable SSL 3.0 on your node.js server. Please note that this might make your website incompatible with really old browsers.

Step 3: Check that it worked

Relaunch your server and repeat step 1 to check that the client is unable to negotiate a connection successfully with SSL 3.0

Step 4: Wait for an official patch:

There seems to be an ongoing discussion on whether to make this the default behavior for node.js in future versions:

…or you can find more in the archives.

Copyright © 2015-2021 - Eduardo Trujillo
Except where otherwise noted, content on this site is licensed under a Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license.
Site generated using Gatsby.