Monthly Archives: August 2016

Secure certificate registration – ensure you choose ‘www’ or not

I’ve been helping a client move their website from their existing host to a new one, as their old host is closing down.

This was quite straightforward once they’d decided to only move the site I had written the code for, not another which was a complicated unknown entity.

The only wrinkle was they have a secure certificate to give them an https connection and we had to register a new certificate as part of the move. I did this through their host at their request, but hadn’t realised that most SSL certificates are specific to the domain, including the sub-domain. This was a mistake as they used the ‘www’ version of their address for their website, and I registered the new certificate for the non-www version.

To stop this being a problem, I put a redirect in to the .htaccess file to redirect all traffic to the non-www version on the secure connection:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.(.*)
RewriteRule ^.*$ https://%1/$1 [R=301,L]

The only further foible was as this was an existing site, Google had indexed the site, and shows the https version in the search results, even though the home page is not explicitly https. Now, because it points people to the https://www version of the site, it shows an unsecure error before showing the site, because the certificate isn’t valid for that on the new site.

Solution?

  • Used Google Search Console (AKA Webmaster Tools) to update the preference to the non-www name
  • Updated the DNS of the www. version to point to the old server while it is still working
  • Added the above .htaccess redirect on the old server to point everyone across to the secure version of the non-www address
  • Created a new XML sitemap of the site at the secure, non-www address and re-submitted it to Google Search Console
  • Wrote an apologetic e-mail to the client explaining the mistake
  • Wrote this blog post and linked to the new site address to help the non-www address get indexed

All this means – searchers go to the old host so no security warning, then get forwarded to the new host while we wait for Google to respond to the preference change. I hope it comes through quickly.

And now I’ll go back to my scheduled work a wiser, if more tired, man.

Sending a push notification to your browser or mobile with ColdFusion and Push Engage

Push Engage is a service which lets you easily send push notifications to a browser or mobile phone, using a little code on your website. It’s very easy to set up and they currently have a very generous free account, allowing you to send a notification to up to 2,500 browsers/devices.

I’m using it as part of some alerts in the background of a client’s website. They’re using ColdFusion, so I needed to work out the code to send the alert from them, the API documentation on Push Engage has an example in PHP, but it’s very simple to convert. Here’s a CFHTTP call that will send a notification:

<cfset api_key = “(your API key here)”>

<cfhttp method=”Post”
url=”https://www.pushengage.com/apiv1/notifications”>

<cfhttpparam type=”header”
value=”#api_key#”
name=”api_key”>

<cfhttpparam type=”Formfield”
name=”notification_title”
value=”The text for the alert title”>

<cfhttpparam type=”Formfield”
name=”notification_message”
value=”The smaller text of the message of the notification”>

<cfhttpparam type=”Formfield”
name=”notification_url”
value=”http://www.example.com/”>
</cfhttp>

I’ve already followed their steps for adding Javascript to a page on the website, visiting it using a browser on my computer and my phone and accepting notifications from the site. Now, when I trigger the page with this on, I get a notification a few moments later. Lovely!

Thanks to Dave Child for introducing me to Post Engage.