On the Tighten.co blog Matt Stauffer shows how to make a password-less authentication system similar to what the popular site Medium uses centered around emails sent to the account for the user.

Recently I was working on a project where one of our major pain points was users' passwords. Users were added to the application by administrators, so they didn't have passwords when they were first added, and forcing them to set and remember passwords was a big hitch on the project's usability.

So, we decided to try out a Medium/Slack-inspired password-less login. If you've never had the chance to work with this, the login system works like this: enter your email address on the login page, get emailed a login link, click the link, and now you're logged in. Access to your email address proves your identity without the need for a password.

He walks you through the process of disabling the current password-based flow by creating and modifying the default "make:auth" results. When the user comes to the site, they're asked to log in via sending an email. This email contains a unique token attached to a link that matches one on the server side related to the user. He shows how to build out this relation table, the matching model and the endpoint used to verify the hash once the user clicks on the link.

Sebastian Bergmann has posted a guide to PHPUnit 4.7 and some of the changes/new features it introduces.

PHPUnit 4.7 introduces a couple of small improvements. For instance, PHPUnit's PHPT test runner now supports --INI-- sections, information about the PHP runtime used is now printed in verbose mode, and a warning is now printed when code coverage data is collected but no whitelist is configured.

He also talks about the support that's been added improving the output of the HTML version of the code coverage reports, showing different colors based on how well covered the lines are. He also briefly looks ahead to PHPUnit 5, the versions it will support and the plans for release.

Eric Wastl has written an open letter to software developers out there in response to this post and sharing some of his own thoughts (and corrections) about what it suggested.

Dear [Software] Engineers, Your job is not to write code. Rather, your job isn't only to write code. Your job is to design and build software, and one of the steps in that process happens to be explaining to a computer how to do its new job. An article appeared on Medium recently that writing code isn't really a big deal and it's not really what your job is about. It is. You can smell "Product Manager" miles before the signature line of the article. The article goes on to talk about how your job is to improve your products for your users. This is not the job of an engineer - this is the job of every person at your company.

He talks about some of the "other jobs" the Medium article suggests a software developer be doing including making sure the "code runs the way it should" (devops, testing, etc) and that it "actually gets merged and pushed into production" (a release engineer). He points out the dissonance between the request for things to "run under all conditions" and when it makes sense to add analytics to your code.

Because your job is to write code. Your job is to write the best code you can, as quickly as you can, within budget, meeting all of the expected features, in a maintainable way, and a million other things, and still make the users happy. [...] Your job is to tell someone when you make a mistake. Your job is to work together with your testers and with operations and with product and finance and, yes, even the other engineers. Your job is to figure out what product will ask for before they ask for it, and build the code so that if and when they do, adding the feature is easy because the code wasn't written in a way that requires a year-long refactoring project to do it in a way that wouldn't make Cthulhu literally gleeful at the thought of it.

The SecurityReason website has three new advisories posted concerning the latest release in the PHP 5 series:

• PHP 5.2.4 <= dl() open_basedir_bypass&code exec&dos - input for the dl() function is not handled correctly and can lead to arbitrary code being loaded and executed
• PHP <=5.2.4 iconv_substr() denial of service - memory limit issue can be used in a DoS attack
• PHP < 5.2.4 setlocale() denial of service - memory limit issue can be used for a DoS attack

The dl() overflow is marked as a medium threat (largely because it allows for arbitrary code execution) but the other two are shown as low threat. A patch is also given for the dl() issue to help correct the problem.

The SecurityReason website has three new advisories posted concerning the latest release in the PHP 5 series:

• PHP 5.2.4 <= dl() open_basedir_bypass&code exec&dos - input for the dl() function is not handled correctly and can lead to arbitrary code being loaded and executed
• PHP <=5.2.4 iconv_substr() denial of service - memory limit issue can be used in a DoS attack
• PHP < 5.2.4 setlocale() denial of service - memory limit issue can be used for a DoS attack

The dl() overflow is marked as a medium threat (largely because it allows for arbitrary code execution) but the other two are shown as low threat. A patch is also given for the dl() issue to help correct the problem.

The Zend Developer Zone is continuing on from previous parts of a series in this new tutorial posted today - part three of the "Ajax Chat Tutorial" tutorial series.

As our chat application gathers pace we return to the server side of the application. At this point we have setup the Zend Framework with an IndexController class to handle server requests. When we receive a new chat message from the user, we will need to store it. For this tutorial I've selected a file based solution using XML.

They start with a look at the storage method - XML on the backend, pushed into a MySQL database (along with the message format). There's a quick refresher on SimpleXML before they show how to integrate this storage method into the current system.

The Zend Developer Zone is continuing on from previous parts of a series in this new tutorial posted today - part three of the "Ajax Chat Tutorial" tutorial series.

As our chat application gathers pace we return to the server side of the application. At this point we have setup the Zend Framework with an IndexController class to handle server requests. When we receive a new chat message from the user, we will need to store it. For this tutorial I've selected a file based solution using XML.

They start with a look at the storage method - XML on the backend, pushed into a MySQL database (along with the message format). There's a quick refresher on SimpleXML before they show how to integrate this storage method into the current system.