I’m a big fan of PHP DotEnv for creating my environment variables for my scripts. (It’s always a good thing to keep your passwords and credentials separate from your source code, according to OWASP).
Today I was faced with an interesting quandary about whether I should write the code to exploit an application vulnerability in our software at work. This vulnerability is not necessarily a “security” one, but more-so a known-risk: it was theorized that someone with enough knowledge could bypass a mechanism in our software.
I’m all for coding standards and rigorous approval processes for software in app stores, I really am. However, I’m currently responsible for creating a number of different CMS plugins that all share some code. Unfortunately, that shared library will never follow the coding standards and requirements for all app stores - each has some differences. That’s why I created…
If you haven’t been following my twitter feed or my open source on github, you might not have seen that I recently released PHProblemLogger, an environment and run-time logger designed to help log everything during an error condition.
I manage any WordPress plugins I create using git. In order to create a distribution of those, I need to zip up the source code and use that to upload to the marketplace (or directly upload). This was easy with SVN - I just used an svn export command and there we go.
Every year, they come out with a list of the top 20 most used passwords and it makes me wonder… how many users on any one of my websites are using those passwords?
At my current job, we keep both a private copy of the code in BitBucket (where all of our code resides), and make a few repos public on GitHub. (Wish I didn’t have to do that, but really, GitHub is the premier place to get your code it seems these days.) So, I decided to come up with a solution to keep both repos up to date as I do my development.
With technology changing so rapidly and people in such a big hurry, sometimes older suggestions or out of date recommendations are the first things that programmers run into. You know you’ve fallen for it - a quick google search and you get your first result and you give it a shot; never mind that it’s a blog entry from 7 years ago.
In a perfect world, when testing your website you’d have a giant device library, a number of different internet connection speeds, and a bunch of users using the system simultaneously. A perfect world? Pfffft. But, I can help you at least get close to this set of requirements for your test. Let’s see how we can use Google Chrome to simulate different devices and change our internet connection speeds.
I’ve been working with Swagger, also known as the OpenAPI Initiative lately, and I’ve come to the issue of issuing an update to an object. I’m planning on using the HTTP verb PATCH (yes it is a standard in case you forgot… like I did).