Our October system update


On 6 October we upgraded our EU-based systems to the latest version of our platform, and today, 20 October, we did the same upgrade on our US-based system. There are a bunch of changes to report!

Legacy TLS sunset

The big change this time around is that we’re sunsetting default support for TLS 1.0 and 1.1. From now on, sites that we host will, by default, only support HTTPS using TLS 1.2 or 1.3. This is more secure, and the right setup for pretty much all sites these days. However, for custom domains, on request we can provide support for the older “legacy” versions.

This is a pretty complex issue, but essentially means that all sites on PythonAnywhere will be more secure without needing any changes. The only reason it might affect you would be if you have lots of visitors to your site using old (pre-2012) Windows machines, or Android devices older than 2014. If you do, we will probably have already emailed you about it so that you can continue to support those visitors (albeit with reduced security). If we missed you out, and you do start getting contacted by users of your site who can’t see it over HTTPS with their old devices, let us know.

Confusing and spurious error message removed

Our last system update introduced some code that would sometimes put errors like this at the start of a scheduled task run, or when a console was started:

rm: cannot remove '/mnt/chroots/yourusename/yoursystemimage/dev/shm': Device or resource busy

The message was harmless, but it was confusing – so now it’s gone. Please do let us know if you see it in the future, though!

Unbranded error pages

Normally, errors in your website code will trigger your web framework’s error handler, so you can use that to customize what is displayed. But if your code has an error that stops the framework from initializing, or triggers some kind of very low-level bug, our own error-handling cuts in.

In the past, the pages we displayed for these kinds of errors had our logo and contact details on them, which we had felt was the right thing to do – if you have problems debugging, it’s useful for you to be able to easily contact us.

However, over time we’ve learned that most people don’t want that, at least for commercial sites – it confuses site visitors about who it is that actually owns the site that they’re visiting, which is doubly problematic given that the page relates to an error.

So we’ve removed our branding or contact details, leaving cleaner, simpler, and less potentially confusing pages. After all, you already know where to reach us if you need us :-)

Long log messages no longer cause logging issues

On the subject of errors in websites – if you print stuff in your website’s code, it’s written to the site’s server log (for standard output) or to the error log (for standard error). We had a bug where if you printed a particularly long line, the logging system would raise an error, which it then tried to write to the error log (including a full dump of the long line in question), which triggered another error, which it tried to write to the error log, which… you get the picture. You would wind up with a lot of junk in the log before the recursion limit was reached and stopped it.

We now detect output that is long enough to cause problems like that, and truncate it.

New API functionality: password protection for websites

For many years, we’ve provided a way to set a simple username and password for your website – now you can set that up over our API too.

Security fix: username and password was included in the server log

On the subject of those usernames and passwords, an eagle-eyed user spotted that they were visible in websites’ server logs. Those logs are private, so that was not a serious problem, but it’s certainly not best practice. Now they are no longer logged.

Other changes

There have been a bunch of other smaller fixes and updates; some that are worth mentioning:

  • Better handling of annual accounts
  • Our editor now has better error handling for non-Unicode files
  • Better handling of errors from Let’s Encrypt when generating or renewing HTTPS certificates

And that’s it!

That’s all for this time around. Happy coding!

comments powered by Disqus