Posted on

Configuring Sublime for PHP Development

Word Separators

One of PHP’s most distinctive features is the dollar sign. All variables in PHP start with ‘$’.

e.g.

$var = 123;

In Sublime, if you double click on a variable name to select it the ‘$’ prefix will not get selected.

To fix this you can edit Sublime’s “word_separators” setting.

To change this setting, go to Preferences -> Settings. Then paste this in your user settings and save.

"word_separators": "./\\()\"'-:,.;<>~!@#%^&*|+=[]{}`~?",

Notice the ‘$’ is missing.

Caps Lock to CTRL

When Caps Lock is pressed it is almost always on accident. On the rare occasion I need something in all caps, it is simpler to hold the SHIFT key.

On the other hand, I use CTRL key constantly. One of the first customization I make on new computers is remapping the caps lock key to CTRL.

You can do this on a Mac in System Preferences -> Keyboard -> Modifier Keys. And on Linux key remapping can be accomplished by using the Gnome Tweak Tool.

On Windows, key modification is a bit more difficult. On Windows, you need to modify the registry. You can do this manually or there are small applications to help remap keys.

Making ‘$’ Easier to Type

Finally, because of the dollar signs position it is not the easiest key to type. I am looking for an optimization to make that character faster and easier to type. I have not found a good solution yet.

Posted on

[Solved] Install Hipchat 4 on Fedora 23

Hipchat has documentation for installing on Debian-based distros but not on RPM-based distros like Fedora and RHEL.

However, there is an undocumented repository for RPM. The undocumented RPM repository is: https://atlassian.artifactoryonline.com/atlassian/hipchat-yum-client

To install the repository:

sudo dnf config-manager --add-repo https://atlassian.artifactoryonline.com/atlassian/hipchat-yum-client

Next, to install Hipchat 4:

sudo dnf install hipchat4 --nogpg
Posted on

Solved: Laravel 5 Calling the Wrong Controller

I recently encountered an issue that took me far longer to solve that it should have. Laravel is an excellent framework for building PHP websites. I have used it to build several sites now and it is by far the best framework I have seen. The latest version, Laravel 5, is powerful and well documented. With Composer, Laravel is easily extendable and allows you to pull in common php packages.

Up to this point, I had used Composer to pull in packages and manage dependencies without really knowing how it worked. Unfortunately, due to my lack of understanding, Composer’s Autoload feature caused an issue that was very hard to debug.

In the site I was making, I created a new configuration file that was used to dynamically set routes so I could create new sections and add those sections to the navigation menus in one step.

Next, I created a template controller that I would simply copy, rename, and start working with for each of these new sections.

Everything was working fine until I used Composer to install a new package on my production system. I installed Guzzle to which is need to interface with MailGun. When you install a new package Composer updates composer.json, installs the package, and reruns dump-autoload.

After setting up email, I thought the site was ready for production. All the sudden, one of my many dynamically created sections was not working. For some reason, the route for this one section was calling the Template Controller instead of the proper controller.

First, I though one of Laravel’s many layers of caching was the issue. I disabled Laravel’s route caching, configuration caching and view caching. I even turned off mod_pagespeed and CloudFlare just to be sure no caching was the problem. But it still was not working.

I decided to hard code the routes to skip over my dynamic route generator. But still for just one section the Template Controller was being called instead of the proper controller. I checked the routes file again and again to ensure there was no earlier route being called.

Eventually, I removed the Template Controller entirely and the section in question would error out saying TemplateController.php was not found. But how was this controller being called? The section was working before. Everything was working on my development machine. Just in production, this one section of the site was not working. For some reason, this route:

Route::get('/quarters',
['as' => 'quarters', 'uses' => 'Content\QuartersController@index']);

would call the TemplateController@index

At this point I had completely deleted the Template Controller. Something must be calling Template Controller somewhere.

So I decide to SSH into my production server and run:

$ grep -R 'TemplateController' public_html/

That grep command searches the entire web directory recursively for the string ‘TemplateController.’

grep_solution

As you can see, the string was first found in an error log file. But the final match led to the solution.

We can see a file called `vendor/composer/autoload_classmap.php` contains a line that seems to be mapping the `QuartersController` class to the `TemplateControllers` class. How did that get there?

It turns out, that when I created the `TemplateController` file, I did it by copying the `QuartersController` and stripping out all of the code specific the that section. Unfortunately, I forgot to change the name of the class in the `TemplatesController.php` file. I accidentally left that class name as `QuartersController`.

Now, that should not be an issue. I am not even using the `TemplatesController` class. It is only there for a starting point when creating new sections.

What I did not know at the time is when your run composer dump-autoload , composer scans your entire project’s source code and creates a `autoload_classmap.php` file. The classmap files allows the application to more quickly find the file containing a particular class.

Because I had two classes with the same name (one of them not being used), composer mapped to the wrong file. I changed the TemplateController.php class name, reran dump-autoload and everything worked again!

This error only surfaced after installing Guzzle because after a package install, composer runs dump-autoload automatically.

The moral here is that you can only use a tool without knowing how it works for so long before it comes back to bite you.

Posted on

[Solved] Change httpd Document Root results in 403 Forbidden on Apache 2.4 and Fedora 22

Recently, I decided to take the leap and begin using Linux exclusively. I installed Fedora 22 and so far I like it. I hit my first major snag when setting up a LAMP development environment.
After installing Apache and setting up a virtual host all pages returned error 403 Forbidden. I am running Apache 2.4. The first thing I noticed is that Apache changed the syntax for allowing and denying access to a directory. Previously you would use:

Allow from All

to grand access to a directory. In Apache 2.4 you use:

Require all granted

After ensuring I was allowing access to the new document root in httpd.conf correctly, I started to get stuck. Only after much digging, I came across the root of the problem: SELinux Contexts. SELinux adds an additional level of security by layering more flexible and powerful access controls on top of the standard Linux access control. SELinux is found on Fedora and Red Hat systems.

You can check to see if SELinux is enforcing access control on your system by running:

$ sestatus

You must add the httpd_system_context_t context to the new document root so that Apache has access. You can read more about SELinux here.

In production you do not want to weaken security to get things working. You should give files the correct context so Apache works with SELinux. However, in a development environment, you can simply disable SELinux to make your life easier.

To disable SELinux modify /etc/selinux/config to look like:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Save that file then restart. You can run sestatus again to make sure SELinux is disabled. If you configured httpd.conf correctly, Apache should now be able to access the new document root.

 

Posted on

Solved: WordPress wp_insert_post problem with post_status and tax_input keys

wp_insert_post is the WordPress functions used to create new post. I used the function to create a plugin with a front end to allow anyone (anonymous users) to create posts. The function appeared to ignore several documented parameters. wp_insert_post would create the post but would not set the Category and Tags fields when anonymous users ran the code. The offending code:

$post = array(
	'post_title'    => $title,
	'post_name'     => $slug,
	'post_author'   => $poster_id,
	'post_content'  => $content,
	'post_type'     => 'music',
	'post_status'   => 'publish',
	'tags_input'    => $tags,
	'tax_input'     => array('genre' => $term)
);
$new_post_id = wp_insert_post($post);

It turns out that the post_type and tax_input keys only works if you user running the code is an administrator. If the user is not an administrator then all subsequent keys after the offending key will be ignored. To solve this problem, use wp_publish_post and wp_set_object_terms functions instead of using post_status and tax_input keys, respectively. These functions will work properly regardless of users’ permissions.

This code will allow anonymous users to create and publish posts:

$post = array(
	'post_title'    => $title,
	'post_name'     => $slug,
	'post_author'   => $poster_id,
	'post_content'  => $content,
	'post_type'     => 'music',
	'tags_input'    => $tags
);
$new_post_id = wp_insert_post($post);
wp_set_object_terms( $new_post_id, array($term), 'genre' );
wp_publish_post( $new_post_id );

If you omit the wp_publish_post then the post’s status is subject to the current user’s permissions (Reference). Anonymous users will create pending posts.

This behavior is not undocumented in the codex. Additionally, the behavior seems to be unintended. The function fails ungracefully by simply breaking when a permissions error is encountered rather than processing the remaining keys.

Posted on

ARP Cache Poisoning Defense

Last summer I attended the US Cyber Challenge Conference in Virginia. I was in the hotel room getting ready for a week of exciting security courses. The WiFi was unbearably slow but I attributed that to the masses of other conference goers downloading OS images needed for the morning classes.

The morning class was Packet Crafting with Scapy, a powerful packet manipulation tool for Python. I was refreshing my Wireshark skills for the morning class and noticed something odd — there was a flood of constant ARP traffic. Someone was poisoning my ARP cache and intercepting all of my web traffic. This was my first up-close and personal introduction to ARP Poisoning.

That experience inspired me to write a personal ARP Defense script. The script monitors a computer’s ARP table and notifies the user when an Attack is detected. The script can be found here. Additional information on ARP Poisoning can be found at arppoisoning.com.