Trackserver v5.0 released
So… here we are! A new version of my Trackserver WordPress plugin was released! If you don’t know what Trackserver is, please have a look at its dedicated page on this website and the plugin’s details on WordPress.org.
Almost five years have passed since the last major release, and the last minor release, v4.3.2, was more than three years ago. In the first few months after the last release, a lot of work was done on restructuring the plugin, but the job at hand turned out to be bigger than expected, and before I could finish it, life got in the way.
So here’s a small disclaimer: after so much time, and so many failed attempts to release a new version, I decided to just do it: release a new version on WordPress.org, exactly as it currently is on Github. This means that some features, and most notably the upgrade process have not been tested very well. Version 4.3.2 is old, and I have always been running the latest code myself. It also means that not every known issue that may still be present in v5.0 is fixed. If things don’t work for you the way you expect, I apologize. Please open an issue, preferably on Github, and I’ll try to help you as well as I can.
As with every major release, there are a few big changes that deserve some special attention. Here we go.
Universal URL slug for all supported apps
In earlier versions of Trackserver, each supported client app (TrackMe, OruxMaps, etc.) had its own URL slug, which allowed Trackserver to quickly pick a the right protocol to listen for.
Trackserver v5 introduces a new universal slug, that can be used in all supported clients. The server will use different heuristics to pick the correct protocol. This means that all clients have to be reconfigured to use the new slug, which is ‘trackserver’ by default. You can configure the slug in Trackserver’s options.
To illustrate this with an example:
With v4, in TrackMe, you would use https://yourhost/wp/trackme in the ‘URL Header’ setting.
In OruxMaps, you would use https://yourhost/wp/mapmytracks.
With v5, you would use https://yourhost/wp/trackserver in either of them!
Your Trackserver profile in the WordPress backend will display this URL at the top of the page. The old, app-specific URL slugs still work in Trackserver v5.0, so nothing will break right away, but they are marked deprecated in the options page, and they will be removed in a future version.
The universal URL does, however, take two different forms. It is possible to embed authentication credentials in the URL, for apps that do not support a more secure method of authentication, like HTTP POST or HTTP basic authentication. TrackMe, OsmAnd and SendLocation are the known clients that need this. In earlier versions this was already possible (and necessary) for some apps, while for example OsmAnd would normally be configured to send the credentials as URL parameters (?username=abc&password=xyz). In v5, I decided to standardize this on having the credentials in the URL as components, rather than as parameters, although the parameters still work. For named apps, the Trackserver URL would look like this:
https://yourhost/wp/trackserver/<username>/<password>
Either of these methods are inherently insecure, because the credentials will likely be logged in the webserver’s access logs. That’s why Trackserver stopped requiring your WordPress password for these apps a long time ago. And please, please, please.. always use HTTPS!!
And that brings me to the second big change that needs some more explanation.
App passwords
In earlier versions of Trackserver, there were different authentication credentials for different apps:
- Some apps (OruxMaps, OwnTracks) were considered secure enough to use your WordPress password.
- For the other apps, each one had a different ‘secret’ in your Trackserver profile.
Apart from the confusion and the hassle of managing all these different secrets, there was the problem of sites that use SSO for logging in to WordPress, in which case users don’t really have WordPress password to use with Trackserver.
In version 5, these app-specific passwords and access keys have been transformed into ‘App Passwords’, and are now app-independent. Existing access keys are automatically converted to App Passwords during the upgrade, and will all be valid for all supported apps, including the apps that worked with your WordPress password before.
Your WordPress password will still work for those apps, but that may change in a future release. Switching to App Passwords is recommended, regardless of the app you use for tracking. The main benefit is an increase in security, because your WordPress password will no longer be necessary for using Trackserver. Trackserver App Passwords can be changed often without impacting WordPress logins. As an added bonus, App Passwords also work in WordPress installs that use SSO mechanisms like OAuth2 for user logins.
App passwords can be managed in your Trackserver profile. They also have permissions attached to them: ‘read’, ‘write’ and/or ‘delete’. Most apps only create tracks and send location updates, and they would only need ‘write’ permission for that. If you configure an app password with only write permissions, it cannot be used to download your tracks or delete anything, in case it would fall into the wrong hands.
Some apps, like TrackMe for example, have functionality that requires read and/or delete permissions. If you use that functionality, you have to configure an app password with appropriate permissions. But even TrackMe can be used for online tracking with only write permissions.
Other changes
There were also a lot of more or less minor changes, that I should mention here:
- You can now search / filter tracks with a search box at the top of the tracks list.
- A bulk action for duplicating tracks was added.
- The PHP code was restructured in a major way, separating code into different classes in a logical way.
- Leaflet was updated to version 1.9.3.
- Experimental support for µlogger.
- Numerous small changes and fixes, improving usability, robustness and error handling.
A complete list of changes can be found in the changelog.
No changes at all were made in the shortcode or the presentation side of things.
