"Curiosity is the very basis of education and if you tell me that curiosity killed the cat, I say only the cat died nobly." - Arnold Edinborough

I really enjoy how easy Laravel makes forms. Being able to pass in a model to Laravel and have it take care of everything is awesome. Sometimes I simply don’t want to make a whole model for my form data, though. If you are similarly lazy at times then there’s a simple way to still have your default form values based on previous input.

Simply create a StdClass object and store the input values in there.

$sorting = new StdClass;
$sorting->sort_by     = Input::get('sort_by', 'displayname');
$sorting->sort_order  = Input::get('sort_order', 'asc');
$sorting->sort_region = Input::get('sort_region', 'all');

Pass $sorting to your template and use it with Form::model() and you’re good to go.

Unfortunately I had to miss the nginxconf for this year, but with it going on right now I got a bit nostalgic and dug out my t-shirt from last year and noticed an easter egg I hadn’t seen until now. On the back of the shirt are the headers of a HTTP response with the line:

Set-Cookie: nginxconf=Q29tZSB0byB0aGUgZGFyayBzaWRlLCB3ZSBoYXZlIGNvb2tpZXMgZHVyaW5nIGJyZWFrIHRpbWUK

Which, if we base64 decode it, translates to:

Come to the dark side, we have cookies during break time

I don’t remember the cookies being very good, though, hopefully that’s something they fixed for this year. ūüôā

So with the OnePlus Two released to the public we now know most of the decisions that went into the making of the OnePlus Two. One of the interesting changes from the previous model is that the NFC chip was removed. If you’re not familiar with NFC then it’s a technology which allows the phone to communicate with other NFC-capable devices by holding the devices together. As an¬†example –¬†mobile payment systems often use NFC. As a technology, NFC is only just starting to reach the mainstream market and most people will tell you they haven’t ever used it before or don’t even know what it is.

The decision to remove NFC was made in the last few weeks while I was still working at OnePlus and there was definitely a mixed internal reception to the news. I never got the actual reason for the removal, though, so the following is mostly speculation and analysis – not inside information.

With that out of the way, lets look at the logic that might explain why OnePlus removed the NFC chip from the OnePlus Two.

The most obvious reason is to cut costs. The quoted savings by implementing NFC ends up at around $5 per phone depending on volume. In the end that’s a $5 more attractive price and might result in more sales than the marketing value of having NFC.

So the big question is: Is the biggest segment of OnePlus users people who use NFC or not? While I doubt even OnePlus knows for sure it certainly seems as if they think most people won’t care. If we reference the famous innovation diffusion curve the question becomes: Has OnePlus reached enough of the majority market to not need the early adopters any more?


This is the part that’s deceptively difficult to answer, if you look at the initial response¬†then you might be inclined to say no. Reddit, Hacker News (though the post¬†strangely disappeared from their front page) and tech media are the first ones to voice their opinion and these are definitely the innovators and early adopters who use these technologies.

However, if you look at the media attention that the OnePlus One received (hats off to Bridget Hickey for that excellent work) then you see a lot of maintream media such as Time.com, Wall Street Journal et al.

For the OnePlus Two we already see that media which borders between early adopters and early majority such as Wired has already talked about the OnePlus Two.

If I were to make a guess I’d say that yes, I think OnePlus has probably passed the tipping point of where NFC makes sense and the slightly lower price will benefit more than having NFC as a feature. My primary concern with this decision is what happens to those users who buy the OnePlus Two unaware of the lack of NFC and later on find that their phone cannot use a brand new mobile pay system or their cool garage project isn’t going to work. The negative impressions that those users receive might follow OnePlus for a while.

Ultimately all research shows people who make predictions are usually just blowing hot air so I’m not going to say whether this decision was good or bad. I know for a fact that OnePlus management aren’t stupid and understand their market very well, that said, everyone sometimes misreads things and when you’re dealing with most of the world as your market it’s difficult to fully understand how a technology such as NFC applies everywhere.

For security reasons it’s fairly good practice to invalidate all log-in sessions¬†when a users password is changed. This is especially useful when a users account has been compromised and they go to change or reset their password. Without log-in session invalidation the attacker will still be logged in and able to cause chaos.

Unfortunately Laravel does not provide this functionality out of the box. We actually have to go through quite a bit of trouble to make Laravel play ball here but it’s definitely worth it, so lets get to it!

Implementing this feature is a two step process.

  1. Track the session IDs of all logged in users.
  2. Invalidate the session data attached to those user sessions.

Part one is fairly simple and can be done in your own application code. The session ID is exposed through Session::getId() so simply add this to an array of session ids stored in a persistent cache. When When you want to invalidate the log-in sessions simply fetch this cached array. I will leave this part as an exercise to the reader.

Part two is where it gets tricky. The Laravel session providers themselves implement a very suitable destroy method that takes a session ID. However, unfortunately the Laravel session store does not expose this method but instead implements a migrate() method. This method does not take a session ID, but instead offers to destroy the current session. Invalidating the session of the user changing the password is all perfectly fine, but that still leaves our attacker logged in. In order to fix this we need to implement a custom session store that properly exposes the destroy() method of the individual session providers.

The following code is done in Laravel 4.2. Version 5 has quite a few changes so this might be significantly different. If anyone uses Laravel 5 please let me know if this applies there as well.

In order to implement this we need to backtrack to where Laravel actually loads session classes. This is defined in your app.php providers array as¬†‘Illuminate\Session\SessionServiceProvider’. The SessionServiceProvider registers a¬†SessionManager which then creates the¬†Store class we’re looking to extend. This means we need to provide our own version of these 3 classes and then modify app.php to load our own SessionServiceProvider class.

Read More

As of Laravel 5.0 it’s still not possible to set the remember me cookie with a secure flag. This is slightly weird as there is a configuration option for secure session cookies. Fortunately modifying Laravel to set a secure log-in cookie is not too difficult – all we need to do is provide a custom Guard class for the Auth driver which overrides the setRecaller() method.

This code is done against Laravel 4.2, I’m not sure how simple it is to adapt to 5.0 as I have not had a chance to work with that yet. Feel free to let me know in a comment.

 * Custom guard class that sets a secure log-in cookie.
class SecureGuard extends \Illuminate\Auth\Guard
	 * Create a secure remember me cookie for a given ID.
	 * @param  string  $value
	 * @return \Symfony\Component\HttpFoundation\Cookie
	protected function createRecaller($value)
		return $this->getCookieJar()->forever($this->getRecallerName(), $value, null, null, true);

Now that we have our custom guard class we need to tell Laravel to use this new class. While not completely intuitive the best way to do that is to configure a custom auth driver where we wrap the default EloquentUserProvider class in our new SecureGuard class. Add the following to your global.php file.

| Auth Driver
| Extend the auth driver to support secure cookies.

Auth::extend('SecureAuth', function($app)
	$model    = $app['config']['auth.model'];
	$provider = new Illuminate\Auth\EloquentUserProvider($app['hash'], $model);

	return new SecureGuard($provider, $app['session.store']);

Finally update your auth.php config file to set the new auth driver.

'driver' => 'SecureAuth',

I’m super excited to announce that I will be speaking at the nginx¬†conference starting on the 20th. I haven’t really put much content up on this blog for a long while, but for the past year I have been working at a smartphone company called OnePlus. We have gotten a ton of traction in the past few months with press from all over the world and great marketing by our team. This naturally means a lot of traffic to handle and because of the way we do our marketing that traffic comes in large bursts rather than sustained over time. During one of our campaigns we had 22,000 connections inside just 10 seconds of our campaign page being live.

At nginx conf I will speak about just how we handle this type of traffic and how it’s different from more normal traffic patterns. If you’re attending stop by my talk on the 22nd at 11:45 am!¬†If you don’t have a ticket yet it’s not too late! Until the 19th you can still register for the conference.¬†(use the discount code SPEAKER25 for 25% off!)

Looking  forward to hopefully seeing a bunch of you guys there!