- Magento Front Controller
- Reinstalling Magento Modules
- Clearing the Magento Cache
- Magento’s Class Instantiation Abstraction and Autoload
- Magento Development Environment
- Logging Magento’s Controller Dispatch
- Magento Configuration Lint
- Slides from Magento Developer’s Paradise
- Generated Magento Model Code
- Magento Knowledge Base
- Magento Connect Role Directories
- Magento Base Directories
- PHP Error Handling and Magento Developer Mode
- Magento Compiler Mode
- Magento: Standard OOP Still Applies
- Magento: Debugging with Varien Object
- Generating Google Sitemaps in Magento
- IE9 fix for Magento
- Magento’s Many 404 Pages
- Magento Quickies
- Commerce Bug in Magento CE 1.6
- Welcome to Magento: Pre-Innovate
- Magento’s Global Variable Design Patterns
- Magento 2: Factory Pattern and Class Rewrites
- Magento Block Lifecycle Methods
- Goodnight and Goodluck
- Magento Attribute Migration Generator
- Fixing Magento Flat Collections with Chaos
- Pulse Storm Launcher in Magento Connect
- StackExchange and the Year of the Site Builder
- Scaling Magento at Copious
- Incremental Migration Scripts in Magento
- A Better Magento 404 Page
- Anatomy of the Magento PHP 5.4 Patch
- Validating a Magento Connect Extension
- Magento Cross Area Sessions
- Review of Grokking Magento
- Imagine 2014: Magento 1.9 Infinite Theme Fallback
- Magento Ultimate Module Creator Review
- Magento Imagine 2014: Parent/Child Themes
- Early Magento Session Instantiation is Harmful
- Using Squid for Local Hostnames on iPads
- Magento, Varnish, and Turpentine
Just a quick writeup this time on how I’m using Squid to help debug PHP/Magento issues on an iPad with a non DNS hostname. I’m not exactly breaking new ground here, but I found none of the existing sources everything I needed or wanted to know. Big thanks to “my Twitter” for the lazy web research!
For extra credit, contemplate how changes made to “computing devices” for user simplicity have complicated the process of development.
PHP, Magento, and Hostnames
Development for modern, locked down devices like smart phones and tablets creates an extra problem for Magento developers. Magento requires/strongly-suggests systems owners configure a hard coded site url. To a novice PHP programmer or web developer, this may seems silly — but veterans know relying on the
$_SERVER['HTTP_HOST'] value opens your system up to potential cross site scripting (XSS) attacks.
During development, it’s common for Magento developers (and PHP developers in general) to setup their
/etc/hosts with fake top level domain names that point to their local development machine’s IP address.
127.0.0.1 magento.dev 127.0.0.1 www.magento.dev
/etc/hosts file is an old piece of computer functionality. Prior to the development of the DNS system, “The Internet” (actually ARPANET) was a list of shared IP addresses and host names, and sysadmins would be responsible for updating a hosts file on their machine. While the development of the DNS system created a more scalable method of resolving domain names to IP addresses, the hosts file stuck around as a useful bit of sysadmin duct tape, and web developers have been using it for local development since there’s been web development.
Unfortunately, while most smart phones and tablets are built on top of a unix operating system, traditional unix features (like the
/etc/hosts file) are locked away from all end-users. It’s also not possible to run a development stack directly on these devices. This means — short of development on a system that’s live on the internet, there’s no out of the box way to point something like an iPad at a development machine. An annoying fact of life in our brave, new, device driven world.
Use of Proxy Servers
Fortunately, and unsurprisingly, there’s a number of different ways for a developer to work around this problem. I’m never wild around relying on an internet connection for local work (see the first fallacy of distributed computing), which meant setting up a local a proxy server on my development machine.
Normally, when an iPad needs to download a website, the conversation goes something like this
iPad: Hey, internet! Give me the HTML page at this URL.
When you’re using a proxy server, the conversation goes something like this
iPad: Hey, proxy server! Give me the HTML page at this URL.
When you configure your iPad to use a proxy server, it’s the proxy server that will do the network lookups, and fetch the page. This means if you have a host file entry on the proxy server, you’ll be able to use that domain name on the iPad, since it’s the proxy server that’s looking up the domain name.
Once I decided on a proxy server, the next step was installing one on my local development machine (a Macintosh running OS X), and then pointing my development iPad at that proxy server. The following is a far from comprehensive guide — YMMV.
Installing the Proxy Server
The de-facto standard proxy server software to use for cases like this is the free and open source (GPL-v2) Squid. One of the nice things about de-facto standard packages is they’re installable via Homebrew.
$ brew install squid ==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/squid-3.4.9 ######################################################################## 100.0% ==> Pouring squid-3.4.9.yosemite.bottle.tar.gz ==> Caveats To have launchd start squid at login: ln -sfv /usr/local/opt/squid/*.plist ~/Library/LaunchAgents Then to load squid now: launchctl load ~/Library/LaunchAgents/homebrew.mxcl.squid.plist ==> Summary /usr/local/Cellar/squid/3.4.9: 2026 files, 14M
The post launch symlink command (
ln) sets up Squid as part of OS X’s
launchd system. The launchd system is (sort of) OS X’s version of linux’s
init.d service system. If that didn’t make sense, all you need to know is if you make the symlink above, Squid will launch every-time you restart your Mac. You can also start Squid manually by using the
launchctl command (
launchctl is part of
If you’re curious what
launchctl is doing, you can open the plist
#File: ~/Library/LaunchAgents/homebrew.mxcl.squid.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>KeepAlive</key> <true/> <key>Label</key> <string>homebrew.mxcl.squid</string> <key>ProgramArguments</key> <array> <string>/usr/local/opt/squid/sbin/squid</string> <string>-N</string> <string>-d 1</string> </array> <key>RunAtLoad</key> <true/> <key>WorkingDirectory</key> <string>/usr/local/var</string> </dict> </plist>
And then extract the start-up command from the
/usr/local/opt/squid/sbin/squid -N -d
This usually isn’t necessary, but it’s useful to know if you’re having trouble with an out of date Homebrew recipe.
One final note on Squid: If you change your
/etc/host file, Squid probably won’t pickup the changes automatically. You’ll want to stop your Squid process with the following command
$ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.squid.plist
and then restart it
$ launchctl start ~/Library/LaunchAgents/homebrew.mxcl.squid.plist
Covering every Squid configuration and feature could, by itself, be a complete book. Fortunately, for our purposes, once Squid’s running on a machine no further Squid configuration is necessary.
Configuring an iPad for Proxy Servers
Once you have Squid (or some other proxy server) up and running on your development machine, you’ll need to configure your device to use this proxy server. In iOS, on an iPad, (on October 3, 2015), you can do this by
- Opening the Settings App
- Tapping “Wi-Fi”
- Tapping the Network you’re connected to
- Scrolling Down to the HTTP Proxy section
- Tapping “Manual”
- Entering your proxy server information
The proxy configuration panel should look like this
The server is the local IP Address of your development machine. The port is the port Squid is listening on. By default Squid runs on port
3128 — but you can determine what port your squid is running on with the following command
$ lsof -i -P | grep -E -i 'squid.+?listen' squid 8012 alanstorm 11u IPv6 0x313e2987f16a85e5 0t0 TCP *:3128 (LISTEN)
The IP address should be the local IP address assigned to your development machine, most likely in the
10.* block. If you’re not sure what your IP address is, use the
ifconfig command, and then look for the
10.* based IP address (
$ ifconfig | grep inet inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet6 fe80::6e40:8ff:feb1:9114%en0 prefixlen 64 scopeid 0x4 inet 10.0.1.3 netmask 0xffffff00 broadcast 10.0.1.255 inet6 fe80::c4de:64ff:fea5:a5ba%awdl0 prefixlen 64 scopeid 0x9
With this configuration in place, your iPad should be using your development machine as a proxy server. Give your
/etc/host based name a go in the browser. Don’t forget to toggle your iPad back to HTTP PROXY — Off if you’re going to be out and about with your iPad.