Do you want your websites users to log in? For certain types you would, but often there is no need. The Ibuildings website does not allow you to register an account and log in. Why would it?
However by default Drupal 8 (and earlier) considers logging in on /user part of the frontend theme. This means that either you have to theme it or accept a horribly broken login page.
Or you could convince Drupal to apply the admin theme to user pages.
A couple of weeks ago we announced the schedule for the Dutch PHP Conference. I already mentioned that we have a great selection of experienced speakers as well as many speakers who are less familiar with the conference stage but are eager (and ready) to take it. At the main conference days we have 5 tracks packed with interesting talks. At the beginning of the first day and at the end of the second day we'll have a keynote. Let me briefly introduce the keynote speakers to you now!
It's been a great honor to receive a total of 350 talk and tutorial proposals for the 10th edition of our annual Dutch PHP Conference. Proposals covered a wide range of topics. Many talk proposals had been submitted by experienced speakers, some by absolute beginners. A number of speakers seems to have proven their skills at local meetups and are now ready to take the stage on a conference like DPC, where there might be a 100 or up to 220 people listening to you.
This is the first blog post in what will hopefully become a new series where we look at old Drupal 7 & 8 security advisories (at least 3 months ago so they should be patched everywhere) and try to learn from the mistakes of others.
As a first post I'd like to pick an older vulnerability, one I've used in presentations to demonstrate how hard it can be to properly apply HTML encoding for Drupal.
If you want to know what JavaScript really is, you have to look beyond just the language. In contrast to PHP, there are several platforms that it runs on. And then there’s the ecosystem, which is nothing like the one PHP has.
In the previous parts of this series we looked at how to get rid of complexity at the level of algorithms. After discussing the problem of nulls in your code, we looked at object lifecycles and how to encapsulate them properly. Now that we have objects that can be constructed and changed only in valid ways, we need to look at how they communicate with each other and how we can improve our code with regard to that aspect.
This year Ibuildings will host the Dutch PHP Conference (DPC) in Amsterdam for the tenth time in a row, on June 23rd - 25th. As you may have noticed, since a couple of weeks you can send in your tutorial or talk proposals. The Call for Papers closes on February 22nd.
In the first part of this series we looked at ways to reduce the complexity of function bodies. The second part covered several strategies for reducing complexity even more, by getting rid of null in our code. In this article we'll zoom out a bit and look at how to properly organize the lifecycle of our objects, from creating them to changing them, letting them pass away and bringing them back from the dead.
In the previous part of this series we looked at what are basically a lot of guidelines for achieving "clean code". In this part I'd like to take a closer look at something we call null. Our main goal will be: to get rid of it.
PHP is pretty much a freestyle programming language. It's dynamic and quite forgiving towards the programmer. As a PHP developer you therefore need a lot of discipline to get your code right. Over the years I've read many programming books and discussed code style with many fellow developers. I can't remember which rules come from which book or person, but this article (and the following ones) reflect what I see as some of the most helpful rules for delivering better code: code that is future-proof, because it can be read and understood quite well. Fellow developers can reason about it with certainty, quickly spot problems, and easily use it in other parts of a code base.
I can still remember seeing jQuery for the first time. Then we got Node JS! Running client-side code on Node wasn’t always possible, and ECMAScript 6 was great in theory, but how long would we have to wait until all browsers were updated? Much to my surprise, these problems are gone!
In this blog post, I will describe a JavaScript workflow that includes:
With many, many open issues (15496 at the time of writing) for Drupal core alone and even more issues for all the contributed modules it can feel like a big hurdle to start contributing to the project.
Last year we switched to using Slack for all our internal communication and it's working out nicely. It's very developer centric in that it offers integrations with lots of services like Travis CI, GitHub, etc.
When we started using Slack one of our developers was sending a file, had his Developer console open and noticed that even though he'd not chosen to share the file public, the API gave back a public URL anyway. Much to his dismay when he tried it out in a new private browsing window he could download his file without authentication!
Everything you share on Slack automatically becomes available on a public url.
Concerned with the security of our communications (we don't share financials or credentials through Slack fortunately, but we may share company or customer sensitive information) I decided to look into it and make it a teachable moment on 'secret URLs'.
Using a style guide helps keep code more readable, which makes it more maintainable. It can also prevent you from introducing bugs which can be hard to spot (by making semicolons mandatory for example). Enforcing code styles is hard. You can use code reviews to do so, but luckily, there are some tools to help you.
This blog post tells you how to enforce the Airbnb Style Guide using ESLint and Ant.
Software we build depends on an aweful lot of other software, our framework (Drupal), third party modules, libraries (server side and client side!), PHP and it's extensions, Webserver (Nginx / Apache), OS (Linux), etc.
The question with security audits is always, how far do we go? What third party software should and shouldn't we audit?
For an application that uses Drupal, it's pretty clear that we should audit the custom configuration and code as well as verify that all third party library versions used do not contain known vulnerabilities. But should we audit Drupal? Should we audit a popular third party module like Views? How about a less popular one like the Feeds REGEX Parser? What if a Alpha, Beta or Devel version is used?
To help with decision making we built and released the Ibuildings Drupal Security Audit tools.
I'm sitting at the conference dinner, in the cargo room of the Cap San Diego in Hamburg Germany, supposedly the 'largest cargo ship seaworthy museum in the world'. Across from me is a German student and OWASP volunteer. We've been talking for a while now, he looks forward to a future in pentesting so he volunteered to help with OWASP AppSec Research 2013. AppSec is a conference for Application Security, hosted by the Open Web Application Security Project (OWASP). Sometimes they add 'Research' to it to encourage researchers to come and speak.
'Sigh. Here we go again' I think as I hear conversation around us stop, people listening in.
Whatever reputation PHP has with other software engineers, it's even worse with the IT security crowd.
On 24 and 25 January it was time again for PHPBenelux the 5th version no less. Two days full of PHP talks that started Friday morning with tutorials. My choice of tutorial was “Design patterns workshop” by Brandon Savage.
Before the tutorial really started about specific design patterns themselves we went back to the basics and got a explanation of SOLID. Because SOLID is the base of most of the design patterns and Object Orientated Programming. SOLID stands for five principles that should help with the making of better, more testable and easier extendable code.
