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:

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:

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.

Alan’s Exif Viewer

Last week I launched exif.alanreed.org an online Exif viewer. This tool allows you to view the metadata embedded within images such as brand, model, and serial number of the camera. Some cameras even store the latitude and longitude of where the image was taken. Cell phones especially store tons of good information in Exif.

I wanted to make this tool for a while and finally got the chance during a 20 hour drive to Orlando, Fl for the annual HTCIA conference.

Right now the tool only works for images, but in the future I hope to add the ability to extract metadata from other file types such as pdf, docx, and exe.

Online WGET Tool

About a year ago I came across a page that my browser flagged as malicious. I wanted to look at the source but my browser would not allow it. The solution is to run WGET on the page in order to view the source without executing it.

wget

I did not have a WGET utility on my computer and did not feel like downloading it just for one use. So I googled “online wget tool” and there was nothing. Just links to the WGET application.

I had just started learning PHP and LAMP stack at the time so I decided to make my own online WGET utility. Here is what I came up with: Online WGET Tool. The tool allows you to enter a URL and see the HTML code without rendering it.

The page sat around for a while – I have used it a couple times over the past year. It has also come in handy as a limited proxy server several times.

Recently, the page was indexed by search engines and has started getting traffic. The tool is free to use and as long as my server does not get overwhelmed it will stay that way.

On-screen Keyboard

On-screen keyboards are useful for people who need alternate keyboard layouts frequently or people with disabilities. On-screen keyboards can also be used to thwart keyloggers. Hardware or software keyloggers can easily be installed on public computers allowing an attacker to see anything that is typed on an infected computer.

Some operating systems come with a built-in on-screen keyboard. However if you are on a public computer the application may be missing or be modified.

I created a web-based on-screen keyboard to solve this problem. This tool lets you type passwords or other sensitive information without a keylogger recording what you type. The input is obfuscated and can be copied to where ever you need it.

The keyboard can be used from anywhere with an Internet connection and a web browser. You can also download the webpage and use it offline. This isn’t foolproof, but it’s a good solution if you are wary of the computer you are currently on.

If you are paranoid you should inspect the page source before using the on-screen keyboard. I have made the page as simple as possible so it should be straightforward to inspect.

The tool can be found at keyboard.alanreed.org