Amazon Web Services (AWS) offers a wealth of services for site owners. A service I particularly enjoy is the inexpensive CloudFront CDN which lets me deliver static content, like downloads and update information for my software, very fast to people across the world. What became apparent is that while it was fast and cheap, it wasn’t the most secure solution. Anyone could forge the update response and mislead my users to downloading a modified package full of malware. The solution was to use an SSL certificate with the CDN, ensuring the integrity of the downloads and update information. For this purpose I used Let’s Encrypt™ which allows you to create properly singed SSL certificates for free. The process is non-obvious so I’m documenting this for you.
As a Joomla! developer I often find myself providing support to users of my software. Sometimes, despite my best intentions, I hit a stone wall: a server setting is amiss. In this case I explain to my users what the problem is and ask them to contact their host to rectify it. One of the most irritating situations I’ve found myself dealing with is when a host replies “we can’t do this for security reasons”. I would generally accept that, if only the host actually knew what they’re talking about. And, yes, I am specifically talking about the fopen URL wrappers and the fact that they are stupidly disabled on many hosts.
This is a user-submitted French translation of my “777: The number of the beast” blog post. Please do not post questions in the comments in French. My French is very rusty 🙂
Je vous promets, cet article n’a rien à voir avec la religion, il traite de la sécurité des sites web. Le démon que je mentionne se refaire au fait d’ouvrir une éventuelle porte pour permettre aux pirates de compromettre votre site. Cet article est long mais je vous promets que vous allez apprendre des choses que vous n’avez jamais imaginées. Faisons la lumière sur le mystère du numéro 777 et tuons le démon !
I promise you, this article doesn’t have to do anything with religion. It talks about site security. The beast I am referring to is unwittingly opening a back door to your site to potential hackers. You may not know it, but you could be a sitting duck. It all lies in the dark world of ownership, users, groups and permissions. This is a long article, but I promise you to learn things you would have never imagined. Let us shed some light to the mystery of the 777 number and kill the evil beast!
If you are a serious web developer, you might have already figured out that performing experiments and untested upgrades on production servers is a disaster waiting to happen, bringing down the live site with them. Staging live servers (in the form of dev.example.com) usually don’t cut it either, especially if you have a lot of file transferring or editing to do. However, local development is still a kludge, as you have to develop in a sub-directory, something like http://localhost/mysite. This has all sorts of implications, the most evident of which being that it breaks cross-content links if you try to pack it and deploy it back to the live site.
Ideally, you would need to develop in subdomains, something like http://mysite.localhost, which would mean that you have the flexibility of local development with the peace of mind of not having to develop in a sub-directory. But, face it. Setting up subdomains is an involving process, requiring hacking around your Apache configuration files. This is suboptimal if you want to do it regularly. Unless you come up with a way to turn http://mysite.localhost to automatically understand where it should find its files.
This article will explain you how to combine WampServer and BIND to create this kind of Holy Grail local web development server on Windows. You will configure a single DNS entry and a single virtual host in order to create a server which can handle infinite subdomains! The only pre-requisite is having a fixed IP address for your server. Well, even 127.0.0.1 will do if you can’t do anything better than that!