Canalplan Bug Tracker

Anonymous Login
2018-03-24 06:16 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000253Canalplan [All Projects] Generalpublic2017-11-13 10:30
Assigned Touser3 
PlatformMicrosoftOSWindowsOS Version8.1
Product VersionProduct Build 
Target VersionFixed in Version 
Summary0000253: Migrating to HTTPS [was: Insecure password warning in Firefox]
DescriptionI couldn't find a HTTPS site for CP so assume there isn't one.

Insecure password warning in Firefox is a new feature that is available starting in Firefox version 51. It displays a grey lock icon with a red strike-through in the address bar, when a login page you’re viewing does not have a secure connection.
TagsNo tags attached.
Attached Files





Last edited: 2017-03-10 13:35

View 5 revisions

No there aren't any SSLs for Canalplan yet.... we either have to buy them or mess around with letsencrypt or other free SSL cert providers.

As we're basically using virtual SSL hosts this turns letsencrypt into a painful manual process every 90 days...

I'm going to look at startssl again to see if their 3 year certs will be usable - their control panel is a lot better but I seem to recall it not being happy working across domains once you'd installed your client certificate in their browser.

Also until all external sites (like geograph) are on HTTPS then upgrading Canalplan to HTTPS will just cause countless insecure content warnings.. which will be more worrying for people not logging in... and things like UKWR and FlagCounter will stop working.



Start SSL have been blacklisted by Mozilla and Google.

I've done some work reconfiguring my sites and now have auto renew for lets encrypt working. So we should be able to do it for canalplan once we've worked out how to handle the non SSL content.


Nick Atty (administrator)

For example, just viewing the home page over HTTPS generates warnings for the following things: - these are the UK waterways web ring - the website ranking tool - the visits counter with flags - the search box

and blocks these: - this is the "social log-on" feature. (twice)' - the adverts that pay for the site! - more of the search box - the "like us on Facebook" box

Many of these are going to be trivial to fix just by changing the URL, but either we need to fix them all, or we need to parametise all the URLs for testing HTTPS while still running on HTTP.

At some stage we will definitely do it, but for the time being there are other things to do.

The real threat to your password is that I've not secured the database properly - which is why I strongly recommend you don't use the password you use for CanalPlanAC for any other site, not that some national intelligence agency is targeting users of CanalPlan.



I'm sure the FB one can be upgraded to HTTPS without any issues at all (even on the live site).

You can fix the google ad errors by moving from

<script async src=""></script>

<script async src="//"></script>

We're using the second version in the ads for here and the boat index and it works perfectly.

So it might be worth making those changes on the next release just to streamline things.

There seems to be no secure version of the rpxnow page.


Shultzy (updater)

Thanks for the info. I use secure passwords generated by a password manager so I should be "reasonably safe"


Nick Atty (administrator)

Google ads and Facebook successfully migrated. Janrain (rpx-now) (social-media logon) should work - I can call it but need some magic configuration to ensure I return to the HTTPS beta site...

We're going to lose some features - I'll use the same magic configuration to turn them off (currently the web ring and the two counters).

Hope to have a working index page on beta by the end of the weekend.



Last edited: 2017-03-12 09:44

View 2 revisions

Social media logon fails with:

Invalid Parameter: token_url must be a URI

Edited to add : it seems to work now... Wonder if it was a caching issue?



Last edited: 2017-03-12 09:57

View 2 revisions

Flagcounter will work with SSL but you need a pro subscription (this is from their FAQ) :

I have an SSL encrypted page, how can I use Flag Counter without a warning message from my browser?

With a Flag Counter Pro subscription, we do support SSL. A subscription is required because encrypting the image puts an additional load on our servers. After upgrading, simply regenerate your HTML code, and check the "Use SSL" option.

It looks like this would cost $29.99 per year...... which is a lot to just put a little counter on the site.


user3 don't seem to support HTTPS at all.

We've talked to UKWR about SSL - might be worth restarting that discussion. Let's encrypt should allow them to create and maintain an SSL.


Nick Atty (administrator)

Social media things wasn't a caching issue - it was me changing the code to try to get the return working (and I'd never registered beta with them, nor configured it to return to beta!).

ukwr is working over https - looks like they've got it working on your advice. So is flagcounter without a subscription (at the moment). Flagcounter is fun but not worth paying for.

I'm now deciding whether to download the web ring to the server, find a way of hiding it on the https sites (the index page is not fully dynamic to reduce load, so I can't do it that way) or just dump it. It must be about the last webring in operation. I doubt many people use it.

The nice thing is that the location services are working again.

This isn't as painful as I thought it might be. I'm moving away from protocol neutral URLs as there's no harm in making them HTTPS all the time.



We could do our own flag counter... you can get high level IP address block to country data...



OK I've got the certificates and created the configuration for the canalplan ssl server.

I suggest once we're happy that we enable a HTTPS redirect on the existing canalplan site and let that run...



Looking ahead I've raised a ticket with Geograph asking about HTTPS support....



Waterways Webring has 46 sites... You should be able to see your stats on how many people have come via there.

Looking into the server logs it looks like none this year and 7 last year....


Nick Atty (administrator)

Thanks for putting that query in - I'd just determined that geograph doesn't work under HTTPS.

You can now plan routes on the beta and visit gazetteer pages. So it is sort of working. I think, from your stats, I'll just kill the webring and tidy the home page up a bit.

Fairly soon I think we need a little logging script and to start using Content-Security-Policy-Report-Only



We seem to have lost Facebook on the list of social logins


Nick Atty (administrator)

I get it - a new private window pointed at beta gives me:

Google + Facebook
Flickr Wordpress
Yahoo! Blogger



Last edited: 2017-03-12 13:40

View 5 revisions

Its there now but if I login using FB it then gets stuck in a loop when you try to go the bugtracker..... It does it on the live site too.

It looks like MANTIS_STRING_COOKIE isn't getting set properly - its set to a dash rather than an MD5 hash.

Logging in using the Canalplan native logon works and the cookie gets set



Reply from Geograph:

A member of the team has replied to your support request, #716595 with the following response:

Yes, this is currently being implemented.

ETA is at least a few weeks out however :(

Hope that helps,

So that's good to know....


Shultzy (updater)

Sorry its causing you a lot of hassle.



It's not really causing us hassle - it's something that we were going to have to do in order to keep our search rankings up and to keep up the google ads (they haven't said that they wont show them on non ssl sites but they've made it quite clear that ads on non ssl sites will have reduced payments).

We can upgrade each bit in turn and then once everything is on HTTPs we can turn on HTTPS for canalplan.



All sites now running with HTTPS available(certificate auto renew is working). Geograph have not yet updated to HTTPS which means that using the HTTPS site gives a mixed content warning.

Apart from that we're ready to go I think.



Just noticed that the og tags are still http based not https even on BETA


Nick Atty (administrator)

Will look at the OG tags but - frankly - doubt their value.

I see that letsencrypt will shortly be offering wildcard certificates which could ease things for you.



I've got the auto renew for the certs working fine (all the blogs and canalplan renewed at 03:00 this morning).. Will certainly be looking at the wildcard certs when they introduce them....



if the OG tags aren't useful then lets pull them....



I've made BETA https only now - so all access to the http site get redirected.



Geograph is now supporting HTTPS.

So we need to update the code that generates geograph URLS (or rather the code that stores them away).

I've updated my geograph utility (which returns the JSON array needed to render the geograph part of the page) so it returns https urls. So if we could implement that then we could trash the cached geograph data and get that call to simply return the data from my utility.

Also we need fix the OG tags



I assume that its the options xml file?

I've changed that but it looks like the geopgraph API still returns non HTTPS urls..So I'm chasing them on that...



Looks like Geograph forgot to add HTTPS to their syndication.php api - so we either need to fix their data when we get it or move to my local version.



Geograph support https in their calls - but it looks like they have huge caches on their servers which means we keep getting the stuff we've pulled in the past. (i.e not https)



They cache for 6 hours - so I've made a change to the options.xml to use https and I'll check on it tomorrow evening and see if things are changing over.




redirects to



File modification notes for Nick:

cached_gaz_data.can ( removed hard coded http and replaced them with // )

options.xml in plugins/gazetteer/geograph ( fetch changed to https, plus text descriptor changed as well) .

geograph.php (local data copy) in utils directory changed to return https



I've removed the forced HTTP to HTTPS redirect on BETA and split the SSL and none SSL access and error logs. This means that we can see if we've got any calls in the SSL site that are firing across to the none SSL site..


Nick Atty (administrator)

Doing so playing around to generate some events in your logs. I've found one definite problem - opening the gazetteer from the photo on the index page drops back from https to http.


Nick Atty (administrator)

I've been doing a few tests and advance releases to beta. Important things:
a) we do need to get rid of the web ring as that is the only thing on the home page now
b) fixing the internal redirects (we do have a strange gazetteer->place with showmarker for the home page image, but that's part of another bug) to protocol neutral URLs works and we get to the https gazetteer from the home page
c) the share code needs an explicit https URL, not a neutral one. I've temporarily hand-wired it and will do it programatically the way they already do in the JS.

We now have entirely clean gazetteer and view photo pages - definite progress.



I've shut down the non https beta site....



OK I checked the ampache logs (which is the default) and all we were getting were hits from external links.

I've re-enabled the beta non https with a forced rewrite to https.


Nick Atty (administrator)

I think we may be ready, at a time when we are around to monitor it, to move the whole site. How does Saturday 14th October sound?



Sounds good to me. I'll change the logging for the non-https service so it logs to a different file rather than the main canalplan one. I'll also put in a hard redirect in the config for the non-https site.

Changing the config and reloading apache will take a few seconds.



All work done....


Autoclose (administrator)

Closing automatically, stayed too long in feedback state. Feel free to re-open with additional information if you think the issue is not resolved.

-Issue History
Date Modified Username Field Change
2017-03-10 12:51 Shultzy New Issue
2017-03-10 13:19 user3 Note Added: 0000999
2017-03-10 13:29 user3 Note Edited: 0000999 View Revisions
2017-03-10 13:31 user3 Note Edited: 0000999 View Revisions
2017-03-10 13:33 user3 Note Edited: 0000999 View Revisions
2017-03-10 13:35 user3 Note Edited: 0000999 View Revisions
2017-03-10 19:43 user3 Note Added: 0001000
2017-03-11 08:12 Nick Atty Note Added: 0001001
2017-03-11 10:12 user3 Note Added: 0001003
2017-03-11 15:34 Shultzy Note Added: 0001004
2017-03-12 09:10 Nick Atty Summary Insecure password warning in Firefox => Migrating to HTTPS [was: Insecure password warning in Firefox]
2017-03-12 09:10 Nick Atty Note Added: 0001005
2017-03-12 09:37 user3 Note Added: 0001006
2017-03-12 09:44 user3 Note Edited: 0001006 View Revisions
2017-03-12 09:52 user3 Note Added: 0001007
2017-03-12 09:55 user3 Note Added: 0001008
2017-03-12 09:57 user3 Note Edited: 0001007 View Revisions
2017-03-12 10:06 Nick Atty Note Added: 0001009
2017-03-12 10:14 user3 Note Added: 0001010
2017-03-12 10:32 user3 Note Added: 0001011
2017-03-12 10:48 user3 Note Added: 0001012
2017-03-12 11:02 user3 Note Added: 0001013
2017-03-12 11:37 Nick Atty Note Added: 0001014
2017-03-12 12:24 user3 Note Added: 0001015
2017-03-12 13:09 Nick Atty Note Added: 0001016
2017-03-12 13:16 user3 Note Added: 0001017
2017-03-12 13:17 user3 Note Edited: 0001017 View Revisions
2017-03-12 13:28 user3 Note Edited: 0001017 View Revisions
2017-03-12 13:32 user3 Note Edited: 0001017 View Revisions
2017-03-12 13:40 user3 Note Edited: 0001017 View Revisions
2017-03-14 13:12 user3 Note Added: 0001023
2017-03-14 13:45 Shultzy Note Added: 0001024
2017-03-14 15:07 user3 Note Added: 0001025
2017-05-13 13:42 user3 Note Added: 0001108
2017-05-13 13:47 user3 Note Added: 0001109
2017-07-09 09:22 Nick Atty Note Added: 0001157
2017-07-09 09:44 user3 Note Added: 0001159
2017-07-10 15:12 user3 Note Added: 0001169
2017-08-12 09:29 user3 Note Added: 0001221
2017-08-17 18:39 user3 Note Added: 0001222
2017-08-17 18:54 user3 Note Added: 0001223
2017-08-17 20:01 user3 Note Added: 0001224
2017-08-17 21:29 user3 Note Added: 0001225
2017-08-17 21:45 user3 Note Added: 0001226
2017-08-20 09:34 user3 Note Added: 0001233
2017-08-20 09:42 user3 Note Added: 0001234
2017-08-20 16:55 user3 Note Added: 0001235
2017-08-20 18:35 Nick Atty Note Added: 0001236
2017-08-21 08:51 Nick Atty Note Added: 0001237
2017-08-30 22:05 user3 Note Added: 0001254
2017-09-22 15:45 user3 Note Added: 0001287
2017-10-09 07:26 Nick Atty Note Added: 0001330
2017-10-09 18:21 user3 Note Added: 0001331
2017-10-14 10:52 user3 Assigned To => user3
2017-10-14 10:52 user3 Status new => resolved
2017-10-14 10:52 user3 Resolution open => fixed
2017-10-14 10:52 user3 Note Added: 0001339
2017-11-13 10:30 Autoclose Note Added: 0001380
2017-11-13 10:30 Autoclose Status resolved => closed
+Issue History