All posts by Brendon Dugan

Recently at work I have been working on a project that has made me have to think about project flexibility in a whole new way. The project involves a service we are creating which companies will be able to purchase and label as their own. We plan on accomplishing this by making use of the Smarty Templating Engine and some server-side magic so that we only have one code base for infinite iterations of the service.

For the most part all of the underlying logic is identical, but Access Control has to be configurable on an individual company basis. Our company has three access levels which map basically to “Basic”, “Pro”, and “Premium”, but Company A may only have “Basic” and “Pro” while Company C may have “Basic”, “Pro”, “Premium”, and “Super-Epic-AwesomeTown”. To complicate matters further, the access levels are not strictly hierarchical. A user who registers on a site may have purchased the “Basic” package and the “Premium” package while opting not to purchase “Pro” or “Super-Epic-AwesomeTown”.

After researching PHP Access Control libraries for a while, I discovered nothing that seemed to meet my needs in an easy to use and flexible way. So, like any good nerd I decided to write and Open-Source my own.

PHP-Bouncer uses the idea of roles to manage permissions, so in the above examples “Basic”, “Pro”, “Premium”, and “Super-Epic-AwesomeTown” would map to roles each of which would give access to specific sets of pages. Each role also has the option to override a page from any other roles, so if “Pro” gives you access to a page called “Buy Premium”, Premium may override that page and send you to “Premium Home”. Roles are defined Like this:

$bouncer = new Bouncer();
// Add a role Name, Array of pages role provides
$bouncer->addRole("Public", array("index.php", "about.php"));
// Add a role Name, Array of pages role provides
$bouncer->addRole("Registered User", array("myaccount.php", "editaccount.php", "viewusers.php"));
// Add a role Name, Array of pages role provides List of pages that are overridden by other pages
$bouncer->addRole("Admin", array("stats.php", "manageusers.php"), array("viewusers.php" => "manageusers.php"));

With our roles defined, we can now create some users and give them roles (NOTE: The User class in this example extends the BouncerUser class, which provides basic role management functionality and is totally optional):

// Here we add some users. The user class here extends the BouncerUser class, so it can still do whatever you
// would normally create a user class to do..
$user1 = new User();
$user2 = new User();
$user3 = new User();
$user1->addRole("Public");
$user2->addRole("Registered User");
$user3->addRole("Admin");

And now, we take our users and our roles and check to see if they would have access to certain pages:

Today I stumbled upon the following article. I encourage you to read the article, but for brevity I will sum it up. Basically, when creating a for loop in most C-based languages, there are two basic incrementation operators: Pre-increment (++i) and Post-increment (i++), with Post-increment being by far more common. From a functional standpoint, in C# they are equivalent within a loop and always produce the same output. The premise of the article is that while Post-incrementing is recommended by most computer science professors, due to it’s implementation in the ECMA standards it is actually slower than Pre-incrementation.

I tend to be a skeptic, so when I read the article I thought the author must have been mistaken. After all, I assumed that computer science is a field where something as common as the for loop would be well documented and understood by the academics. In order to test the author’s claim I decided to write some code to test how long it took each operator to iterate 1 billion times incrementing a variable on each iteration. Here is the code:

While there is a measurable difference between the two operators, it is so minute that over the course of 1 billion iterations it only amounted to .02 seconds difference on average on my machine. In a loop used in an every day program, this would most likely make no measurable difference. Although the difference was minute, I may still start using the Pre-increment operator since it is such a small change.

Today I was reading about managing hierarchical data using MySQL when I stumbled upon an excellent and extremely informative article. There’s nothing I can add to the article that isn’t better articulated there, so head on over and check it out!

Unless you have been living in a cave recently you have heard of the bills SOPA (Stop Online Piracy Act) and PIPA (PROTECT IP Act). These bills have been introduced as a way to prevent the distribution of copyrighted materials over the internet by allowing the government increased powers for censoring websites which facilitate the illegal distribution of intellectual property. This would be accomplished mainly by identifying websites which are accused of distributing copyrighted material, and ordering all American DNS’s (Domain Name Server) to stop referring requests to those websites. According to House Judiciary Committee Chairman Lamar Smith (R-Texas),

The Stop Online Piracy Act helps stop the flow of revenue to rogue websites and ensures that the profits from American innovations go to American innovators. The bill prevents online thieves from selling counterfeit goods in the U.S., expands international protections for intellectual property, and protects American consumers from dangerous counterfeit products.

SOPA and PIPA (which I will refer to collectively as SOPA from now on) are dangerous pieces of legislation, and in my opinion you should actively oppose them. Here’s why:

SOPA is Unlikely to Prevent Piracy

In order to explain why SOPA is unlikely to stop piracy, I want to first give a brief explanation of how DNS (SOPA’s primary censoring method) works. All computers have what is called an IP address, which is a number representing that computer on the internet. Since every website on the internet is hosted on a computer, every website also has an IP address. This is a very convenient way to direct requests to websites if you’re a computer, but if you’re a human you are not likely to be able to remember more than a handful of IP addresses at a time. DNS is the solution to this problem. DNS stores a directory of domain names (such as www.newegg.com) as well as their corresponding IP address (216.52.208.187). As you can see, both the IP address and http://www.newegg.com will load the same page.

This is important because removing a website from DNS does not prevent anyone who is moderately technical from viewing a website. In order to prevent someone with reasonable technical ability from accessing websites, the government would have to start actively monitoring all data which makes it’s way across the internet in real-time. Not only would this be prohibitively expensive, it would be a massive breach of privacy for everyone on the internet (imagine someone from the government reading some of the more *ahem* exciting emails you have exchanged with your significant other). While this huge invasion of privacy would limit what normal people are willing to share over the internet, the most tech savvy of us would know how to make use of encrypted connections and proxy servers to bypass all restrictions the government tried to place. Every time a company or government has found a way to keep hackers from accessing something, the hackers have found ways to bypass those security measures; a great example of this is Gary McKinnon, the Scottish hacker who penetrated the security measures of multiple US Government agencies looking for evidence that the US covered up contact with Extra Terrestrial Life.

Those Who Are in a Position to Pass SOPA Don’t Understand the Internet

It is well known that the 50+ generation of Americans is largely ignorant to the inner workings of the internet and computers in general. While there are individuals from that generation who were the innovators who designed the internet, there are far more individuals who require a call to the kids to post a photo to Facebook. With that said, the last person you want to make major decisions about an industry is someone who is entirely unfamiliar with that industry.

Most of us remember several years back when Senator Ted Stevens referred to the internet as A Series of Tubes. If you haven’t listened to his speech recently, take a minute to do so now. I’ll wait. Throughout all of the stammering in that video, the only recognizable words describe something similar to Netflix, and a series of tubes. Also, it seems like he may have mentioned using the internet for the first time that day. There are no requirements in Congress for knowing what you are talking about before you can vote on a bill. Ted Stevens was given the ability to vote against Net Neutrality not long after that speech. Think about that. Also think about the fact that according to www.senate.gov (PDF) the average age of members of the 112th was 62.2 years.

The Websites You Love Could Be Banned

It should by now be clear that SOPA has almost no chance of successfully completing it’s goal, but it does have a great chance of accomplishing a much more harmful goal: ruining the internet. Many would agree that the strength of the internet is that people of all walks of life can share information about the things they understand, and find information about things they don’t. Sites like WordPress, Stack Overflow, and Wikipedia provide a great deal of knowledge to people all over the world every day. But sites like these are in danger of being taken down because of a clause in SOPA which makes domain owners responsible for content posted by their users. In short, if I posted copyrighted material on my blog in a world where SOPA was law, the entire domain wordpress.com could be taken down. As I write this article, wordpress.com is home to roughly 35,247,329 blogs. And they could all be taken down due to the indiscretion of one blogger. The same could be true of Facebook or any number of other sites you use on a daily basis.

SOPA is dangerous, and if it manages to pass the internet will change forever. Not in a good way. Call your local Representatives and tell them to oppose SOPA!

Recently at my job I have had several situations in which I needed to pass fairly large amounts of data to a particular page on a website for processing, and in which submitting a form isn’t a feasible option. Typically in this situation one would attempt to append the data to the url using GET parameters, but sometimes your data is too large or too sensitive to pass through the URL. Unfortunately, PHP does not provide an easy way to make post requests natively. Luckily for us, there is cURL. cURL allows us to communicate across multiple protocols to a variety of different server types. With cURL, we are able to make HTTP POST requests:

The above function accepts two parameters, the URL to make the request to, and an associative array containing the keys and values you would like to submit with your POST request. The function returns an associative array containing two values: status, which will either be equal to “ok” or “failure” depending on the success or failure of the POST request; and either ‘content’ or ‘error’ depending on success or failure. In the case of a successful POST request, ‘content’ will contain the full output from the page you have posted to (In other words, you may need to be prepared for an entire html document). Otherwise, ‘error’ will contain the details of the error as returned by cURL.

Recently at work my co-workers and I have been working on a fairly large and complex website (which will be top secret until early next year 🙂 ), and we have encountered one of the pitfalls associated with group web development: Overwriting each other’s code with FTP. The natural solution was to use Subversion to manage our source code. We created our repository, checked out our local copies, and regularly updated and committed our code. While this greatly reduced the frequency and severity of our FTP mishaps, it did not eliminate them entirely. As tension began to mount (exaggerated greatly for literary value), we decided to seek a better solution… something that would allow for our development server to automatically reflect the contents of our source repository. We eventually settled on the use of a post-commit hook, which for those of you who are new to subversion is simply a script (which can be written in any language your server understands) which is executed every time anyone commits to the repository. Unfortunately for us our Subversion Repository was hosted on a third party server, and we did not have access to the server to write the hook. This meant that we were going to need to create a new repository on a server we could access. We chose to use the Web Server we host our site on, just because it reduces the overall complexity of our setup considerably. The following steps were implemented on an Ubuntu 11.04×64 server, but the steps should be nearly identical (with the exception of possibly the package management) on any modern Linux server.

Using Subversion to Automatically Publish Your Website

Install Subversion and Subversion Apache Support

sudo apt-get install subversion libapache2-svn

Create the SVN Directories

You can place your SVN Root anywhere you would like on the filesystem, but I chose to place mine in /svn, feel free to edit these commands to reflect your desired location. Also, in my example I change the ownership of the svn directory to the user/group www-data. If you are using a different Linux distribution you may need to check to see which user Apache runs as by default, and adjust the commands accordingly.

sudo mkdir /svn
sudo chown www-data:www-data /svn

Creating Your Repository and Configuring Apache to Serve It

We need to configure Apache to know the location of our repository (which I realize we haven’t created yet), so point your favorite text editor (I’m a Nano guy) at /etc/apache2/mods-available/dav_svn.conf:

sudo nano /etc/apache2/mods-available/dav_svn.conf

By default almost everything in the file is commented out. While it is possible to set up your repository to allow anonymous reading (and is in fact the default option), I opted to require authentication for every action on this repository since this source code will most likely end up containing database user credentials. Since an example of setting up anonymous reading is in the configuration file, I will allow you to un-comment it if you would like to use it. Here is an example of the config file I am using:

There are a few things to note about the above file. The first is the tag, which needs to point to the location we plan to create the repository in. Also note that SVNPath should point to the same location. The next section contains data about how to authorize users. I used basic .htaccess style authentication, with an auth file located at /etc/apache2/dav_svn.passwd. The last line before the closing tag states that only users with a valid username and password are able to access the repository.

Now that we have Apache pointed at the repository, let’s create it! In order to prevent permissions issues, we need to become the www-data user:

sudo su www-data

when asked for a password, enter your own password. Now that we are the correct user, let’s create the repository at the location we specified above.

svnadmin create /svn/repository
exit

Now that the repository exists and Apache is configured to see it, we need to restart Apache to refresh the configuration:

sudo /etc/init.d/apache2 restart

After a moment, try to point your browser to http://%5Byourdomain%5D.com/svn/repository. If everything is configured correctly you should see a password box pop up. Of course, there are no users authenticated for the repository, so at this point you can’t get in.

Creating Your SVN User Accounts

Now that the repository is set up, we need to have authenticated users to commit to and update from the repository. When creating users, the command to create the first user is slightly different from the command to create all other users. For the first user do:

sudo htpasswd -cm /etc/apache2/dav_svn.passwd username

and for the rest do:

sudo htpasswd -m /etc/apache2/dav_svn.passwd username

After creating a user for yourself, go back to http://%5Byourdomain%5D.com/svn/repository and enter your username and password. If all goes well, you should see a screen indicating that your repository is at revision 0.

Setting Up Your Website to Retrieve Data from the Repository

There are several way to do this next step, and several things to consider before choosing a path. If your website already exists, you may want to set up a new virtual host on your server to hold the new copy until you are satisfied with the performance of the repository, or if you have an up to date local copy you may feel free to simply delete your old directory on the server (as we will be remaking it in a moment). Another thing to consider will be subversion configuration directories inside your website. If your server is configured like mine, it denies access to .svn directories, and an svn checkout command should be an easy way to accomplish our task. Otherwise, you may want to consider using an svn export command instead. Since my server is configured to be safe with .svn directories, I decided to go with the checkout command. Since my website is located at /var/www/mysite, the commands to do a fresh svn checkout is:

You should now have a basically empty directory, which has the distinct advantage of being able to be quickly updated to contain the contents of the repository.

Updating Your Website After SVN Commit

Now that the repository is set up and our website is pointing to a working copy, we can set up our post-commit hook to update the website every time a commit is made. Due to the somewhat complex nature of Linux permissions, we will be performing three main steps to accomplish this goal: Creating a script to update the working copy in our webroot, giving the Apache user (in my case www-data) the ability to run that script as root without a password, and then creating our hook to call that script as root.
First we create the script (Note: this command will open Nano to a blank file for you to edit and as soon as you save the file it will also make that file executable):

Testing Your Setup

Now that everything is theoretically set up, all we have left to do is test. The best way to do this would be to do an svn checkout on your local machine, copy the local backup of your website into the folder you performed your checkout into, and then attempt to run a commit on your working copy. If all goes well, you should be able to point your web browser at your Website and see what you just committed.

Hey all, I just wanted to take a break from my normal programming to give a personal update. Over the past few months I have not written very many blog posts, but this blog is far from abandoned. I have been extremely busy. In the last few months, I have started a new job for a fantastic company in Asheville, NC, as well as a Photography business with my wife. The real distraction, however, has been the birth of our son Aiden!

My Wife and I with our beautiful baby boy!

Now that things are calming down a bit, I hope to be able to post more regularly!

Introduction

Recently while working on a project for work, I encountered an interesting issue. I needed to develop a way to add and remove permissions from a User in a system we are building (which will be made open source as a service to the internet community once development is complete), but I needed the ability to push out these permission changes even if a user is currently logged in to the system.

As far as I know PHP does not provide a way to edit User sessions other than the $_SESSION array, which only applies to the current User’s session. After some research, I discovered that it is possible to change PHP’s default session storage method. This can be very useful if you are using a CDN to share server load between multiple servers while still allowing data persistence through the session. Another useful benefit of storing your sessions in the Database is the ability to alter User sessions (for any user) on the fly.

There are a few things to note about editing User Sessions on the fly:

If you aren’t careful you can inadvertently edit the wrong session, leading to security issues

The way session data is stored in the database is through a single serialized data field. This means that before editing a session variable you must either parse and change only the value you wish to change, or unserialize the entire session data string, edit the individual values, and then re-serialize the data for insert.

I have never tried the above method, and therefore cannot provide any code to accomplish this task. If this changes, I will edit this post with the relevant code

If you are only storing basic login type data in the session (which would be pulled from the Database), killing a User’s session and allowing them to log back in is the safest way to ensure that any changes to the session will populate correctly

Setting up the Database

The SQL in this tutorial is written to work with MySQL, so if you’re using something else just bear in mind that your syntax may need to be tweaked, especially in the DDL.

Replacing PHP’s Session with our Database Session

Now all we have left to do is actually utilize our new session handling. This is actually a relatively painless process. In my application the session is started in the header include file for each page. In this case, all I had to do was change:

Introduction:

If you’re like me, you hate using your touchpad when you could be using an external mouse. If you’re like me you also have a habit of disabling your touchpad when using a mouse, and forgetting to re-enable it until after you unplug your mouse. If you’re like me, this tutorial is exactly what you need.

What you need to get started:

You will need to make sure that you have xinput and halevt installed. You almost certainly already have xinput, but the following command will make sure you have what you need:

sudo aptitude install xinput halevt

I also recommend that you create a folder for scripts (if you haven’t already), and add it to your $PATH. I created a “bin” folder in my home directory for this. Create the folder with:

mkdir ~/bin

and add it to your path by issuing the following commands:

echo "PATH=\$PATH:~/bin" >> ~/.bashrc
echo "export PATH" >> ~/.bashrc

Configure the script:

First we need to create and configure the script which will actually toggle the touchpad:

cd ~/bin
touch toggleTouchpad
gedit toggleTouchpad

The script should now be open in gedit (feel free to replace gedit with your favorite text editor). Paste the following into the script:

If your touchpad has the word “TouchPad” (case sensitive) in it, the script is ready to go. If it doesn’t, edit the variable “touchpadString” in the script to match your touchpad… but remember everything is case sensitive. For now, your script is configured. Next step is testing.

Test the script:

Make sure your touchpad is working, and then open a new terminal window. We are going to do four tests. Before and after each test, try your touchpad.

Test 1:

toggleTouchpad

Did your touchpad stop working? Good!

Test 2:

toggleTouchpad

Did your touchpad start working again? Good!

Test 3:

toggleTouchpad off

Wait at least one second…
Did your touchpad stop working? Good!

Test 4:

toggleTouchpad on

Wait at least one second…
Did your touchpad start working again? Good!

Making the magic happen automatically:

We’re almost there! Now we need to set the script to run automatically when your mouse is plugged in. Making sure your mouse is unplugged, run the following command:

halevt -i >>~/connectedDevices.txt

While the command is running, plug in your mouse, and then unplug it. Now press Ctrl +c to kill the process. Open ~/connectedDevices.txt, and you should see something that looks like:

All of those devices are your mouse. Since each of those events will trigger every time you plug in your mouse, we only need to handle one of them. Pick one that ends in seemingly random numbers, and copy and paste everything after the “:” into a text file. We will be using it in a moment. Now, let’s create our halevt config file:

Test the Magic:

Now, connect your mouse. If all is going well, about ~1.5 seconds after you plug in your mouse your touchpad should stop working. Now, disconnect your mouse. Your touchpad should start working again.

Making it permanent:

If all went well in the tests, you will want to make this happen automatically forever. Go to “System->Preferences->Startup Applications”, and add a new startup program. Name it something you will remember, and for the command put “halevt -c ~/.halevt.xml”. You’re done!!

For me it is often frustrating trying to use my laptop’s touchpad to do anything that requires even the slightest bit of accuracy, so I use an external mouse whenever possible. Unfortunately, the placement of the touchpad means that I will invariably end up touching it with my palms while I type. Today I finally had enough and decided to take matters into my own hands. The following script will allow you to either toggle your touchpad based upon it’s current setting, or to explicitly turn your touchpad on or off (perhaps as an event to be fired when you plug in or unplug an external mouse). Without further ado:

# toggleTouchpad by Brendon Dugan
# Toggles a touchpad on or off depending on it's current state or CLI argument
#
# To configure, run the command 'xinput list' in terminal and identify your touch pad.
# Using the output of the above command, change the touchpadString variable to a substring
# of your touchpad's description that is unique to that device.
#
# To run, simply type 'toggleTouchpad' to toggle your touchpad on or off, or
# 'toggleTouchpad on' to explicitly turn your touchpad on, or
# 'toggleTouchpad off' to explicitly turn it off.
#
# Enjoy!
touchpadString="TouchPad"
touchpadID=$(xinput list | grep "$touchpadString" | awk -F " " '{print $6}' | awk -F "=" '{print $2}')
touchpadEnabled=$(xinput list-props $touchpadID | grep "Device Enabled" | awk -F ":" '{print $2}')
# Check for arguments on the command line
if test $# -eq 1
then
# Change the argument to lowercase
arg1=$(echo $1 | tr [:upper:] [:lower:])
cliArg=1
else
# There is no argument.
cliArg=0
fi
if [ $cliArg -eq 1 ]
then
# If there's an argument, check to see whether it is on, off, or junk
if [ $arg1 = 'on' ]
then
# The argument was 'on', so turn the touchpad on
xinput --set-prop $touchpadID "Device Enabled" 1
elif [ $arg1 = 'off' ]
then
# The argument was 'off', so turn the touchpad off
xinput --set-prop $touchpadID "Device Enabled" 0
else
# The argument was junk, so do nothing
sleep 1
fi
else
# There was no argument, so just toggle the touchpad to the opposite
# of the state it has now.
if [ $touchpadEnabled -eq 1 ]
then
xinput --set-prop $touchpadID "Device Enabled" 0
else
xinput --set-prop $touchpadID "Device Enabled" 1
fi
fi