Monthly Archives: February 2020

Staying ahead of the Curve

This one is mostly thanks to Paul Ockenden’s PC Pro column. The magazine has survived the changing IT landscape well and a subscription is good value for money, IMO.

As mentioned a couple of months back, one annoyance about my new smart watch is Samsung Pay, which Monzo do not support. Given their client base, and given also that such “legacy” banks as Nationwide and the Co-Op (neither famed for their IT) have managed to support it, a conspiracy theorist would wonder if Monzo are deliberately taking a stand against fragmentation of payment services. But it’s probably a good old-fashioned lack of developers.

Either way, an “aggregator card” like Curve – which supports Samsung Pay et al – is a neat way round this. It simply “forwards” transactions to the underlying card, which can be any MasterCard or Visa (switch between them in the Curve app). As well as fixing lack of support for Samsung Pay on Monzo, this could also be useful to anyone with a “work” credit/purchasing card, since none of the banks seem in any hurry to add even basic Google Pay support to these.

Naturally, having another layer involved in the transaction should make you a bit nervous in cases of large purchases or anything where a refund might need to be requested – especially since your finance team at work might not be too keen on finding out you’re using a third party card “in front” of your company issue one.

However, the solution to this seems simple – use Curve for the small(er) stuff when out and about, e.g. travel and subsistence. It’s things like paying for the tube which is so much easier with phone/watch than digging the right card out of your pocket – and for the big ticket items, you’re probably sitting at your desk with plenty of time to fish out the actual card and use it directly.

Downsides? Well, the items appearing on the underlying card statement are all prefixed with “CRV*” – you do still get the original merchant details after that, but it makes it a bit harder to follow and makes a slight hash of logos and stats on Monzo.

Also, activating the Curve card on Google Pay and Samsung Pay requires confirmation text messages, which failed to arrive for me until I phoned Curve and they fixed something at their end.

All that sorted though, I should finally be able to use Google Pay when travelling for work, and use my watch to pay via Monzo in places which don’t support American Express.

Grandstream HT801

Everyone wall mounts their electronics with sticky back velcro, right?

In a final postscript to my new internet … now that my landline number is on VoIP, it diverts straight to my mobile. But that leaves me with a couple of analogue handsets which no longer do anything.

(Actually, they play an amusing message saying “this is a broadband-only line, please don’t disconnect it”).

For myself, I’d probably bin them and leave it at that, but there are a couple of reasons to want to keep them working on VoIP – first, most “old fashioned” phone handsets are much easier to hold next to your face for an hour that a smartphone which gets annoyingly warm and is quite heavy.

Secondly, when relatives stay with me (the same relatives who still use landlines to call me), they expect the old phone handsets to work.

I had a Zoom 5801 in my electronics box (goes all the way back to 2011), but although I got it working against the A&A VOIP service for incoming calls, outgoing calls got a busy tone. In the end I got fed up of poking its hateful configuration interface, threw it away, and ordered a Grandstream HT801 from Amazon.

So, have things got better in ten years? Well, sort of. On the downside, the Grandstream needs rebooting after some settings changes and takes forever to come back; on the upside, after a certain amount of prodding, I have it working both ways and it even supports IPv6! I’ve got it set to IPv6 only, which means no NAT to get in the way of VOIP traffic, and it works well.

I have it connected to the analogue phone extension ring in my flat, and it manages to ring line-powered handsets as well as a cordless phone. The AAISP support site links to the UK/BT settings; it’s a boring amount of copy/paste to fill them in, but once done, it has the right ring and dial tones, and even manages to display the caller ID.

Of course, as you can see in the picture, they clearly should have printed “Grandstream” on it the other way up to make it wall mount with the ports on the bottom.

P.S.: The automatic firmware update URL is for an IPv4 only hostname. I changed to s3.dualstack.eu-west-1.amazonaws.com/gs-firmware – no idea whether it will work yet, but seems better than a setting which I know won’t!

P.P.S.: There is no encryption on AAISP’s VoIP service at the time of writing, so you don’t want to use it away from trusted networks – VPN up first. Last time I asked I got told that calls on the PSTN aren’t encrypted anyway, which is true as far as it goes but not the leg of the call I’m most worried about. May be time to ask again. To be fair, they are not alone in this decision – most other VoIP providers are the same.

A&A update

DSL Gear

The day finally arrived. The broadband switch went through around 7AM, so I spent five minutes reconfiguring the router once I got up, and it’s all working perfectly.

The port of my landline number to VoIP was a little less smooth – it spent most of Friday “in limbo” with calls neither ringing the handsets at home nor landing on VoIP – but by 6pm all was well.

So far the whole service Just Works including the IPv6. Result!

There’s one more post to follow on what I’m doing to keep my old landline handsets working.

Innotech Get It Right™

During last week’s heating issues, I needed to send someone a link to download the Windows software for our heating controller. I grabbed the link I made a note of nine years ago and tested it quickly before sending:

[[email protected]:~]$ wget https://innotech.com/DownloadFiles/Software/icomm_v130_rel19.exe                                 (02/02 19:25)
--2020-02-02 19:25:41-- https://innotech.com/DownloadFiles/Software/icomm_v130_rel19.exe
Resolving innotech.com (innotech.com)… 2606:4700:3037::6812:28dc, 2606:4700:3031::6812:29dc, 104.18.40.220, …
Connecting to innotech.com (innotech.com)|2606:4700:3037::6812:28dc|:443… connected.
HTTP request sent, awaiting response… 200 OK

Two things about this please me greatly:

  • Cool URIs don’t change. I had no doubt that the software would still be available; it’s used for a range of devices some of which are still for sale. But that the same link from 2011 still works is impressive.
  • The download happened over IPv6! Naturally, this isn’t because a random HVAC supplier has rolled it out explicitly for their website; they’re using CloudFlare. And why not? Takes care of the SSL, caches those downloads closer to global customers and thus saves bandwidth, keeps you up to date without you having to lift a finger. CloudFlare’s control panel doesn’t let you turn IPv6 off if you’re on their basic package – it rightly explains that there is no good reason to do so.

That htpasswd file of yours has got to go

If you’re my sort of nerd (which I suspect many of my readers are), this story or something like it will probably have happened to you.

Flashback: the summer of 2009. I’m setting up a private website, access for which needs to be restricted to a handful of friends. So I do the obvious thing:

htpasswd -c /srv/auth/my-site.htpasswd david

The htpasswd tool allows you to maintain a simple file of usernames and password hashes, then you just hook it up to your Apache (other web servers are available) with a few lines of config, like this:

<Location /private/>
    AuthType Basic
    AuthName "Top secret"
    AuthUserFile /srv/auth/my-site.htpasswd
    Require valid-user
</Location>

And now, when you visit the location, your browser pops up the usual dialog box:

The ’90s called, they want this dialog box back

Maybe, like me, you rounded it off by providing a simple scripted interface for users to reset their passwords if they forgot them.

And there the matter rested, in my case for over a decade. However, logging in to the aforementioned site yesterday, I realised there are several things wrong with all this (seen with the benefit of, ahem, 2020 hindsight):

  • Most password managers can’t fill in the dialog box most browsers use for HTTP basic authentication, so you have to copy/paste (or worse, use a well known password and never change it)
  • Why does a dinky little private site I run which we all use twice a year need its own password database? Yet another thing to remember, or risk people re-using a password on. Is it using an up to date, properly salted password hashing mechanism? I don’t even know.
  • This doesn’t allow for two factor authentication, which I view as practically mandatory for internet-facing systems these days.

Like me, you’ve probably had a vague intention to retire your various examples of this setup for years, but have been put off from doing so because it’s not clear what else can be done without adding a huge pile of complexity. Perhaps I can help you with that…

By using the mod_auth_openidc Apache module, you can swap basic auth for “sign in with Google” in about ten minutes.

Their site explains how. Don’t be put off by the references to the now-defunct Google+; the underlying APIs still exist and work. I did have to work out a couple of extra tweaks:

    OIDCRemoteUserClaim email
OIDCScope "openid email"

It’s not the nicest Apache module I’ve ever worked with, as it will segfault the process if you get its configuration wrong (e.g. leaving out the above). It also needs extra config if you’re running behind a proxy and the user-facing port number is different to the back end. But still, it’s packaged for Debian and once you have it working, it stays that way.

Finally, if you don’t have a Google Apps domain with all your users in it, and instead just want to restrict people to signing in with a whitelist of allowed Google/GMail accounts, you simply do this:

Require user [email protected] [email protected]

Result. Naturally, as well as meaning one fewer account for your users to worry about (realistically, they all had Google accounts already), this means that password reset, second factors, etc. etc. are all now Google’s problem, not yours.

Go get rid of your basic auth; the rest of the internet thanks you in advance.