If you are a regular visitor to the site, you may have noticed that there’s a new “Account” link in the navigation bar (situated below the title banner). That page provides access to the main site account where you can manage your notifications and keep track of any bug reports, feature requests, comments or typo reports that you have submitted.
Note that this main site account doesn’t include the shop or this blog as these two areas use third-party software (osCommerce and WordPress, respectively) with different databases. So if you already have a shop account (or plan to create one) and you also want a site account, you will need two separate sets of credentials as there’s no single sign-on (SSO) system. (The shop account can be accessed via the “My Account” link at the top of the shop pages.)
It’s still possible to submit bug reports, feature requests , typo reports and make comments on a bug report or feature request as a guest, but if you want to receive any email messages about updates to your post or if you want to receive any notifications about other posts then you will need to create an account. The reason for this change is that, in order to email you notifications, the site must necessarily store your email address. By having a password-protected account, you can more easily adjust your preferences or change your email address.
If you are signed in, you can also bump open bug reports. Sometimes a bug report comes in when I’m particularly busy, and I’ll open it with the intention of looking at it more thoroughly when my workload eases up, but sometimes I forget. If a bug that looks easy to fix (such as commenting out an end of line character or correcting a misspelt command name) has remained open for some months then that’s the most likely reason why. In which case, you can remind me by signing in, view the report and click on the “Bump” button. This will automatically send me an email to remind me.
The image above shows the header information for an open bug report. This starts with the bug ID followed by a permalink if you want to share or bookmark the report. This is followed by the submitter (me, in this case). This information will be omitted if the report was posted as a guest. If the report was posted by an authenticated user (some who was logged into the site account) then the report is linked to that user’s account (so it will show up in their account page) but the “Submitted by” information is determined by their account settings, which may be one of: anonymous (default), username or display name. In this example, the report was posted by me and I have the “display name” setting on, so it shows my display name (Nicola Talbot 🦜). It shows up in green to indicate that the user has administrator privileges (just in case, by some coincidence, another user happens to have the same name).
The status line shows that the report is still open. In this case, it’s a problem that’s very tricky to fix (which is why it’s been open for so long) but, if you want to remind me about it, you can click on the “Bump” button next to the status, which will automatically send me an email. Since I don’t want to be mail-bombed by a particularly enthusiastic user repeatedly clicking on it, the bump button becomes unavailable for a couple of weeks after it’s used.
Below the report summary (and after the button that will return you to the search results), is information about whether or not you have subscribed to receive notifications about this report with a button that allows you to subscribe or unsubscribe. You can view a list of all the reports that you have signed up for in the “Notifications” area of your account page. Notifications are sent whenever a significant change is made to the report, such as a change of status or a new comment. Notifications aren’t sent for minor edits, such as fixing spelling mistakes. By way of comparison, the above report is shown below where the user isn’t logged in.
The “Bump” button is no longer available. Instead there’s a link to sign in if you want to bump it. Similarly, there’s no subscribe/unsubscribe button.
Feature requests have something similar, but instead of bumping the post you can “like” it. The number of likes a post receives will give me some idea of how popular the request is, which I can use to determine whether or not it’s worth implementing.
Another advantage with being signed in is that the site will trust you more than it does for a guest. Unfortunately a high number of bots hit the site, and some of the forms are intentionally complicated to make them harder for bots to navigate. (In the past I used CAPTCHAs, but bots can break them, they can cause accessibility issues and they use third-party code, which may implement tracking.) This means that if you are logged in, some of the forms are simpler, such as the comment forms and the report a typo form.
There are four types of notifications you can sign up for: news, bug reports, feature requests, and books. I’ve already mentioned bug reports and feature requests above. In an earlier blog post, I described the RSS feeds available on this site, but it may be that you don’t have an aggregator and don’t want the hassle of installing one. If you prefer to receive an email notification whenever a new item is added to the News page then you can either subscribe to all news or you can select the tags that you’re interested in via the News Notifications area. For example, if you want to be notified whenever a new example is added to the Gallery, then you can subscribe to the “gallery” news tag.
The Book Notifications area allows you to sign up for notifications about any of the books published by Dickimaw Books. You can either sign up for notifications about a specific title or you can sign up for notifications about particular genres. For example, if you sign up for news about the title LaTeX for Complete Novices then you will receive a notification when the first edition goes out of print and when the second edition comes into print. If you sign up for a pending title, it helps me to gauge whether there’s enough interest in the book to make it worth publishing.
In the “Notifications” section of the Account page you can choose whether to receive an email for each notification or to receive a daily or weekly digest. There aren’t usually a lot of notifications in one day or week, but occasionally a post may receive multiple comments or there may be several news items in one day.
To create an account, follow the link to the Account page. This will automatically redirect you to the login page and from there you can follow the Create Account link. The site credentials (the information you need to supply in order to login) comprise a username (not email) and password. The username must start with a letter and consist only of letters, numbers, period/full stop (.), hyphen (-) or underscore (_) and must be a minimum of three characters. The password must be at least 8 characters long and mustn’t be easy to guess. Common passwords that have been exposed in data breaches won’t be accepted. Similarly, passwords formed from easy to guess patterns (such as 12121212) aren’t allowed. If you have difficulty remembering all your passwords (and you should have a different one for every account) then I recommend that you use a password manager.
You need to supply an email address when you create an account. If you have previously signed up for bug report or feature request notifications on this site then, if you use the same email address, you can retain your existing notification settings. (You can later change your email address in your account page once your account has been created and verified.)
You can optionally specify a display name. This may consist of most printable characters (letters, numbers and punctuation) and spaces. My display name includes an emoji (🦜) at the end mainly to test UTF-8 support. As long as the display name doesn’t breach the site terms and conditions (that is, as long as it isn’t offensive etc) you should be able to choose a display name to suit you. Note that browsers may use fonts that don’t support some characters so there’s no guarantee that a display name will be rendered correctly.
Once you have created an account, you will receive an email with the verification code, which needs to be used to activate your account. All emails from the site will address you by your display name (if set) or by your username and are sent as plain text (no HTML part) so there’s no unnecessary bloat from images and there are no hidden elements (such as web beacons).
Once your account has been verified, you can login and go to the Account page to view your settings. You can change your display name, email and password but not your username.
You can also set up two-factor authentication (2FA), which I recommend. This requires a time-based one time password (TOTP) authenticator app (which provides a six-digit code that changes at regular intervals, typically 30 or 60 seconds). TOTP is a public algorithm (RFC 6238) and is used by most authenticator apps. Some companies have a tendency to promote their own TOTP app as though it’s the only one that can be used with their site and it’s only in the small print that they acknowledge that you can actually use other authenticator apps. This has unfortunately led some users into believing that they need to install multiple authenticator apps, despite the fact that most of them are compatible.
(SMS authentication isn’t supported for this site. It’s not secure and requires an extra piece of personally identifiable information to be stored in the site database, which wouldn’t otherwise be needed.)
To setup 2FA, first make sure you have an authenticator app installed then go to the “Security” section of your account page and click on the “Enable 2FA” link. This will display a QR code for you to scan. Alternatively, you can manually enter the key below the image. This key (which is embedded in the QR code) is the secret part of the TOTP algorithm. A copy is saved on the site database (encrypted) and in your authenticator app. It’s this key that’s used by the TOTP algorithm to generate the 6-digit code based on the current time. In order to ensure that the key has been correctly entered into your authenticator app, you need to enter the 6-digit code generated by the app in the text box below the QR code and click on the “Verify” button to complete the process.
Once you have enabled 2FA, you can also setup recovery codes. These are single-use codes that can be used instead of the TOTP 6-digit code and should be stored in a private place (for example, write them down and put them in a safe). If you can’t use your authenticator app (for example, your phone’s battery is flat) then you can use a recovery code instead. Once you have used up all your recovery codes (or if they have been discovered by someone else), you can generate a new set.
When 2FA is enabled, the next time you login you will need to provide the 6-digit code from your authenticator app or a recovery code (in addition to your username and password). You have the option to trust the device and browser that you are using for 30 days. If you want to enable this, you need to make sure the “trust this device” checkbox is selected before entering your 6-digit code. This means that next time you log in using that particular browser on that device you will only have to supply your username and password. Note that this requires a persistent cookie (with a lifespan of 30 days). Once the cookie expires (or is deleted) you will have to supply the 2FA code again.
When you use the “trust this device” setting, the webscript will try to determine your operating system and browser from the user agent string. This information (if available) and your IP address is stored (encrypted) in the site database so that you can review your list of trusted devices to help determine whether or not you recognize them. The information isn’t used for any other purpose.
All this extra security may seem like overkill just to receive notifications from a small site, but it’s good practice.