Programming

Fixing the SSH tunnel with Sequel Pro on MacOS Sierra

Sequel Pro is one of the most popular database tools for the Mac. With the release of MacOS Sierra, I had a few issues connecting to my saved databases that used the SSH tunnel method of connecting. The error I kept getting was:

debug1: Offering RSA public key: /Users/username/.ssh/id_rsa.pub
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read_passphrase: can't open /dev/tty: Device not configured
debug1: permanently_drop_suid: 501

The fix involved two steps. The first is to be sure your id_rsa file has the proper permissions.

chmod 600 id_rsa

Then, in your Sequel Pro connection change the key file from id_rsa.pub to the none pub version, id_rsa.

The push to HTTPS

Last year, Google started giving websites that have an SSL cert a ranking boost. As part of that announcement they said it was done to push the web to be more secure. But they also wanted to go even further and push for “HTTPS everywhere”.

This week it was announced this measure is going to be taken a step further with a new feature in Chrome where it will show a big red “X” on unsecured sites. Firefox also has plans for this.

The EFF and security researchers are applauding the move. One example is it prevents governments from blocking specific pages. They instead have to block the whole domain which is much more noticeable. You can read about Russia’s WikiPedia ban for more context.

Dave Winer is one proponent against this and in a recent post he said:

I wonder if they’ve even tried to quantify the outages they’ll cause. So many sites are simply residing on a hard disk somewhere, served by an ancient version of some unknown and not maintained server software, chugging along as someone keeps paying the electric bill, and replaces a broken hardware component when needed. The people who created the site might not have understood HTTPS or how to deploy it, and many are long gone. Some of course are dead. We are certainly not all sitting around doing nothing waiting for a handful of programmers on a mail list to make us perform a ridiculous act of security theater for our blog posts written in 2002. 

Most of these sites do not need HTTPS. It isn’t an issue for my ancient blog posts. Or yours.

I personally think the current proposal with a red “X” is not the right solution. Yes, users will notice it at first, but give it two weeks and that icon will be totally ignored. I like the proposal on the Firefox report where someone suggested the browser just alert when submitting a form on an unsecure site, but I think it’ll be ignored after a while as well.

Free SSL’s

Let’s Encrypt and AWS are two service now offering free SSL certs. As the market shifts toward free services I’m sure implementation will get easier and easier until all web hosts just have support by default.

Of course, this would be a lot of work and a lot of companies would need to make big architecture​ changes.

The GitHub Silo

People have been complaining​ about silos since the first one was built. I think if we took a trip back in time with Marty McFly we would see hundreds of people standing by that first one and arguing about it.

Of course, we can all agree silos are mostly bad and especially whenever it’s such an integral piece of modern tooling.

Tonight, GitHub is down and that means it’s impossible to read project documentation, install packages, or browse gists. Everything just comes to a halt.

The irony in this is that Git is distributed​ and designed to work even if you don’t have an internet connection but because we, as developers, rallied​ around this one company now literally everything is in their hands.

It’s one of those things where you don’t think about it until it’s down. Then you realize just how fragile a developers toolkit is.

How to send both HTML and Plain Text Password Reset Emails in Laravel 5.1

Laravel comes with an included Authentication system complete with password resets that saves you from the burden of having to set it manually on all your projects. In one of the apps I built, there have been reports of the password reset not making it to the end users. It just so happens that all email is being sent through a third party system which tracks sends and deliveries.

In this case, the emails were being sent and reported being delivered but the user kept claiming they didn’t receive it, the obvious culprit of it going to spam/bulk mail. In the research process, it was discovered that we only sent an HTML password reset without any text fallback. Maybe that was the reason?

This seemed like a simple improvement and could at least rule out that as a possibility. However, now all the mail is handled inside the Illuminate components and I couldn’t find any documentation on how to send both.

At this point, I started digging to try and see how Laravel is sending the email. Inside PasswordBroker I found an emailResetLink method which is how it is actually sent:

$view = $this->emailView;
return $this->mailer->send($view,

Now it’s just a matter of figuring out where “$view” came from and I didn’t have to look far. Inside the constructor it is injected:

public function __construct(TokenRepositoryInterface $tokens,
                            UserProvider $users,
                            MailerContract $mailer,
                            $emailView)

Next question is, where is the instantiated? Doing a project search for the class name lead me to the registerPasswordBroker in the PasswordResetServiceProvider. This pulls in from the config file:

$view = $app[‘config’][‘auth.password.email’];

Opening `config/auth.php` shows how it’s defined by default:

'password' => [
    'email' => 'emails.password',

Almost there. Going back to the mail documentation it shows you can send both with this call:

send(['html.view', 'text.view'], $data, $callback);

That means it’s just a matter of adjust the auth.password.email to be an array instead of the string:

'password' => [
    'email' => ['emails.password', 'emails.text-password]',
Don’t leave your users stranded–send both for an important email like this.

One of the benefits to Laravel is at almost every turn there is a simple way of solving a given problem and this is just one example. I hope by me outlining the steps I took to solve the problem it gives you insight into finding your own way around the next time you get stumped.

Get The Most Popular Posts From The WordPress API

As of right now the WordPress plugin directory holds 40,367 plugins. Finding the one you need is typically pretty easy with the hardest part choosing which one suits your needs the best.

In my particular use case, I am building a new section on a site that will be completely outside of WordPress. Even though it’s outside WordPress, I still wanted to pull in a list of the most popular posts.

Searching for most popular in the plugin directory returned 614 different plugins, but I couldn’t find any that would work in this context. A lot of them do their calculations by literally storing views for each visit. I see no reason to fill up my database with this data when an external system is already logging it. That is when I remembered WordPress has it’s own API and can be utilized directly from the Stats package.

I went on a mission to implement this and wanted to share how to do it. (more…)

photo by pixabay

Passing Referrer data from SSL

Google is now recommending all sites to start moving to HTTPS by installing an SSL certificate. The benefits include a more secure experience and a rumored slight bump in SEO. I implemented Stripe payments on a site which required an SSL certificate and made the decision to go ahead and make the whole site run over HTTPS. One of the downsides to doing this is I noticed that referral data was no longer sent to sites I linked to.

For some, this may not matter but to me I look at referrer data as a form of marketing. When I link to a site and they see traffic from my site then they will not know I appreciate their work, and hopefully be interested enough to visit my site.

Sending Referrer Data

After a bit of research, I found a draft W3C spec on just this issue and it includes a simple fix in the meta section. By simply adding the following to your HTML you can send this data automatically:

<meta name="referrer" content="unsafe-url">

The W3C document outlines all the available options here and if you would like to have this more restricted please look at those options. For the purpose here unsafe-url, or all in older specs, will send a Referer HTTP header to any URL you link to. One thing to note is, “this will leak origins and paths from TLS-protected resources to insecure origins”. So if you are in admin area or something that shouldn’t be known to the outside world you would never want to use this.

In my case, the site is just a blog and I’m not concerned about leaking any information.

As a final caveat, this W3C spec is a draft. Some browsers Chrome and Firefox are already included support for this meta tag, but others might not be. So if that is important to you, then you will need to figure out a more advanced way of passing this data.