PHP 10.0 BlogLinkedInSecurity (3.9.2014, 06:10 UTC)

This is an uncharacteristically non-PHP post, but I thought it may interest the audience anyway, and this is as good place as any to have it. So the TLDR of this post is that I’ve recently had an interaction with certain security issue in LinkedIn, this issue is still there, LinkedIn is not inclined to fix it and you may be affected.

The Story

All names (except, obviously, LinkedIn) in the story has been changed to protect the privacy, but refer to real people, entities and events.
The story of discovering this issue begun when one morning I have woken up and found in my mailbox a message saying “here’s the link to reset your password” from LinkedIn. As I have not reset my password on LinkedIn, I was somewhat surprised, but thought – OK, maybe somebody is trying to play tricks with my account, I’m pretty sure this would go nowhere. Then, as my brain was waking up, I looked at the email closely and discovered two things:

  1. This email has not my name, by the name of my colleague, let’s call him B., at the company, let’s call it Westeros Inc.
  2. The email was not sent to me directly, neither it was sent to B. directly, instead it was sent to an internal company mailing list

I didn’t know what to make out of it but decided maybe B. copy-pasted wrong address to some field in LinkedIn.
Later the same day, talking to B. and other coworkers, I have mentioned this event. B. said that he indeed reset his LI password recently, but he never added the goldcloaks list to LinkedIn. I’ve started to get suspicious and asked how then I’ve got his password reset email? He didn’t know. So we (myself and B.) did an experiment:

We went to LinkedIn, logged out and clicked “forgot password” on the login form. Then we entered the address of the and in a couple of seconds, I’ve got the password reset link, with B.’s name on it. Clicking on that link, I’ve got a form to reset the password (no additional questions like what’s my favorite pokemon) and after another click I’ve got the email saying “B., your password was successfully reset“. I used the new password to log in, but then I was stopped by the two-factor verification. Which means two things: 1) password change worked, since 2-factor kicks in only when password is right and 2) B. is a smart man and has protected his account against password thieves. I had to ask him for the code – now that I have his account’s password, this was the only way to give him the control back. After getting the code, I could successfully log into his account and could see all his deepest secrets (which I didn’t) or return the control back to him (which I did). Before that, we verified that is indeed in B.’s list of account’s emails.

Then I decided to see how comes the goldcloaks list ended up in B.’s email list. I went to my own email list, and, surprisingly, discovered that in my own list, among my regular emails, there is another mailing list,, which I definitely did not ever add there and had zero reason to. I asked other people sitting around in the office to check their lists and they too have discovered a couple of extra emails, added by some mysterious way, in their profiles.

The Analysis

Basing on these discoveries, I have arrived at the following conclusions:

1. There is a way, currently unknown to me, to add a group mailing list to one’s profile on LinkedIn, without their explicit consent (at least without them knowing that this is what they consented to).
2. LinkedIn accepts this group list email and any non-primary email as an email to send password reset requests too.
3. Reading emails from this address is the only thing needed to reset the password – even if 2-factor auth is enabled. With 2-factor auth, you will not be able to access the account after the password has been reset (unless you find a way to cheat there, I did not try) but you will be able to reset the password.
4. For the majority of people asked, LinkedIn password emails to ended up in a spam folder, which means the victim of the shenanigans may not even notice what happened.

This looked like a security issue, so I have written up the whole story (in a bit less colorful words than here) to and went back to work, expecting the email from LinkedIn with heartfelt thanks and promises of speedy fix implementation.

The Security Response

Of course, that is not what happened. Instead, what happened that I have got an answer from some very helpful individual from frontline s

Truncated by Planet PHP, read more at the original (another 5171 bytes)

SitePoint PHPQuick Tip: Make Sure Your PHP Version is Safe with Versionscan (2.9.2014, 23:31 UTC)

There’s a tool you can use to check that you have a version of PHP with the most bugfixes. The tool is versionscan and it recently got a 1.0 release. This quick tip will show you how to install it into your environment so it’s accessible from any folder, letting you call it at any […]

Continue reading %Quick Tip: Make Sure Your PHP Version is Safe with Versionscan%

SitePoint PHPQuick Tip: Install Recki-CT into a Vagrant Ubuntu Box (2.9.2014, 18:04 UTC)

Recki what? If you don’t know what Recki-CT is, see @ircmaxell’s original post or the repo, we won’t go into depth here. This quick tip will merely show you how to install it on a Homestead Improved box, much like we did with other software before. Step 1 – Homestead Improved First and foremost, get […]

Continue reading %Quick Tip: Install Recki-CT into a Vagrant Ubuntu Box%

Matthew Weier O'PhinneyDeployment with Zend Server (Part 3 of 8) (2.9.2014, 13:30 UTC)

This is the third in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed creating recurring jobs via Zend Job Queue, à la cronjobs.

Today, I'm sharing a very short deployment script tip learned by experience.

Tip 3: chmod

In the first tip, I detailed writing deployment scripts. One of the snippets I shared was a chmod routine:

$command = 'chmod -R a+rwX ./data';
echo "\nExecuting `$command`\n";

The code is fine; what I did not share is where in the deployment script you should invoke it. As I discovered from experience, this is key.

Zend Server's deployment scripts run as the zend user. If they are writing any data to the data directory, that data is owned by the zend user and group -- and often will not be writable by the web server user. If you have scheduled jobs that need to write to the same files, they will fail... unless you have done the chmod after your deployment tasks are done.

So, that's today's tip: if you need any directory in your application to be writable by scheduled jobs, which will run as the web server user, make sure you do your chmod as the last step of your deployment script.

Next time...

The next tip in the series is another short one, and will detail how to secure your Job Queue job scripts.

Other articles in the series

I will update this post to link to each article as it releases.
Cal EvansInterview with Chris Weber (2.9.2014, 05:00 UTC) Link
Ross TuckNotes from LaraconEU (1.9.2014, 22:00 UTC)

Having spent the previous weekend at LaraconEU, I wanted to jot my thoughts down about the conference, particularly some of the upcoming features unveiled by Taylor Otwell (the framework’s BDFL). To clarify, I’ve never used Laravel, have no plans to do so right now and all of these features are still in active development. I just want to talk about technical and community impressions so take everything you read with a grain of salt.

New directory structure

The next big Laravel release is going to ship with less of a Rails-inspired structure (think: app/models, app/controllers, or ZF1) and will instead move to a PSR-4 structure. This looks great for 2 reasons: first, it brings the framework more in line with existing community standards (and tooling). Second, I believe this change will encourage devs to design their objects more freely, rather than try to fit everything into the pre-labeled types of objects.

Taylor is also shipping a plugin that will support the old directory structure seamlessly, so you can go ahead and upgrade to the other stuff without letting this change hold you back.


One of the most controversial parts of Laravel are the Facades, essentially static shortcuts to objects in the DI layer. Stealing an example from the docs, you might have a controller like this:

class PageController extends BaseController {
    public function showStuff()
        return View::make('some.template', []);

In this case, the View object is the Facade. Being static makes it convenient but harder to test and isolate. While there’s some interesting stuff going on behind the scenes to make it somewhat testable, the new version of Laravel renders the point moot by adding autowiring IoC to more objects, like controllers. This lets us rewrite the above example to:

class PageController extends BaseController {
    public function showStuff(View $view)
        return $view->make('some.template', []);

This seems like a small change but the effect is profound. Our dependencies are clearer and we can mock them very easily. This new feature preserves the ease of use, makes room for better OO, and does it without breaking BC. Nice.

I’m not a huge fan of autowiring IoC myself but considering the tradeoffs, I think this is a great change. In fact, I’d go far as to say this is the killer feature for the next version and would highly recommend Laravel devs upgrade just to get access to this (when it’s deemed stable, of course).

Custom Requests

The most interesting feature was the new customs Request classes. Essentially, this let you create typed HTTP requests with custom validation and authorization rules that run before allowing access to the controller.

    class UserController extends BaseController {
        public function createUser(CreateUserRequest $request)
            // do stuff

In the example above, if the HTTP request is a POST, the $request is already prefilled and validated before ever reaching the controller, cleaning up the code a bit. The custom Request classes can be generated with an artisan command to save some boilerplate setup.

Once you see it in action, it’s pretty clear this is an integrated Command Bus, which is pretty fascinating. If you know me, I’m bonkers about command bus service layers an

Truncated by Planet PHP, read more at the original (another 3936 bytes)

Stas MalyshevPHP Spec – a dream come true (1.9.2014, 19:50 UTC)

Almost 8 years ago, I wrote “What is PHP anyway?“. This blog is supposed to be about some long-term dreams, and in this case it was the dream come true – Sara Golemon and the excellent Facebook team made a draft PHP spec and with some paint and polish it can become a real spec pretty soon. Not sure if it can be ready by the 8th anniversary of that post, but it probably will be out by the 9th :)

Talking to people, I recently discovered not everybody knows this thing exists. So here it goes – it exists right here. It is still a draft. If you see something wrong, submit a pull request. If you feel you can contribute more by working on it or refining some points, “standards” mailing list was re-purposed to be the working group list.

Tagged: language, PHP, specification, standards
SitePoint PHPSingle Page App with Laravel and EmberJS (1.9.2014, 16:00 UTC)

In this part, we will see how Ember works, how to use Ember Data and how to build something simple with it. Router, Route, Model, Template and Store are some of the concepts of Ember. I’m not going to explain every one of those, so if you feel stuck, use the documentation. As usual, you can download the code for this part here.

Let’s code

Note that while developing with Ember, it’s a good idea to download the Ember Inspector. They released Ember with a Chrome Extension and now that extension is also on Firefox.

For this example, we are going to put every line of JS inside /public/static/app.js. In a real project, this is not a good idea. This simplifies our example but ask yourself - have you ever done some serious work with MVC architecture in just one big file? We saw how Laravel works: controllers are in one folder, each of them in one file, the configuration is in its own folder, the models too. I suggest you do the same thing with Ember when you dive into a proper project.

The first thing you ever do when starting Ember is create the application. It is a global namespace for everything that you code with Ember. An Application can be created like this:

App = Ember.Application.create();

I suggest activating a bit of debugging just by adding a line of code when you create the application.

App = Ember.Application.create({

It doesn’t do much more than output your movement through the URLs and templates in the console. Also, we are going to use Ember Data which is a separate module of Ember and provides a nice integration with REST, translating everything from Store Object to request on the server. By default, Ember Data uses the Rest Adapter. You can also use the Fixture Adapter for testing and local development. Basically, Ember Data is a bridge between servers (Rest API) and local storage with the Store Object.

As we saw earlier, our API uses a namespace. Ember’s Data comes with a Rest Adapter which accepts a namespace, a prefix like we saw on Laravel Route groups. Lets pass in our namespace as an argument.

Continue reading %Single Page App with Laravel and EmberJS%

SitePoint PHPWelcoming New Authors – July, August 2014 (31.8.2014, 16:00 UTC)

Two more months, and our ranks keep growing - while some authors are basking in the summer heat on beaches around the world, others are hard at work submitting their excellent content and getting the networking they deserve.

New Authors

In the past two months, we’ve had a whopping ten new authors join our team, all top quality, all incredibly enthusiastic about both learning and teaching. Let’s welcome them into the fold! Note that from now on, all author descriptions will also have their social icons underneath so you can keep in touch with them via your social network of choice.

Continue reading %Welcoming New Authors – July, August 2014%

PHP 10.0 BlogPHP 5.6 – looking forward (31.8.2014, 04:52 UTC)

Having taken a look in the past, now it’s time to look into the future, namely 5.6 (PHP 7 is the future future, we’ll get there eventually). So I’d like to make some predictions of what would work well and not so well and then see if it would make sense in two years or turn out completely wrong.

High impact

I expect those things to be really helpful for people going to PHP 5.6:

Constant expressions – the fact that you could not define const FOO = BAR + 1; was annoying for some for a long time. Now that this is allowed I expect people to start using it with gusto.

Variadics – while one can argue variadics are not strictly necessary, as PHP can already accept variable number of args for every function, if you’re going to 5.6 the added value would be enough so you’d probably end up using them instead of func_get_args and friends.

Operator overloading for extensions – the fact that you can sum GMP numbers with + is great, and I think more extensions like this would show up. E.g., for business apps dealing with money ability to work with fractions without precision loss is a must, and right now one has to invent elaborate wrappers to handle it. Having an extension for this would be very nice. Finding a way to transition from integer to GMP when number becomes too big would be a great thing too.
Still not convinced having it in userspace is a great idea, what C++ did to it is kind of scary.

phpdbg – not having gdb for PHP was for a long time one of the major annoyances. I expect to use it a lot.

Low impact

Function and constant importing – this was asked for a long time, but I still have hard time believing a lot of people would do it, since people who need imports usually are doing it in OO way anyway.


OpenSSL becoming strict with regard to peer verification by default may be a problem, especially for intranet apps running on self-signed certs. While this problem is easily fixable and the argument can be made that it should have been like this from the start – too many migrations go on very different paths depending on if it requires changing code/configs or not.

Adoption – again, with 5.5 adoption being still in single digits, I foresee a very slow adoption for 5.6. I don’t know a cure for “good enough” problem and I can understand people that do not want to move from something that already works, but look at the features! Look at the performance! I really hope people would move forward on this quicker.

While 5.4 will always have a special place in my heart, I hope people now staying on 5.2 and 5.3 would jump directly to 5.6 or at least 5.5. The BC delta in 5.5 and 5.6 is much smaller – I think 5.3->5.4 was the highest hurdle recently, and 5.4 to 5.5 or 5.6 should go much smoother.

Anything you like in PHP 5.6 and I forgot to mention? Anything that you foresee may be a problem for migration? Please add in comments. 

Tagged: extensions, migration, PHP, php56, syntactic sugar, syntax
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP