For some reason the scanner is saying that it can't find HSTS headers on the site I'm testing, but they are definitely there, I can see them when I look at the responses, and a couple of other scanners of different kinds I've just tried also both pick it up and say it is valid.

I'm fairly sure that it used to find them on the same site, but now doesn't. Is there an issue with the scanner and HSTS?

    JohnP I assume you are talking about EKO Diena. There was indeed an issue with the lab, I have now pushed a fix 👍️ Website is now A+ as it should have been 👌

    It seems like Guzzle (the library I use to make requests) automatically transforms the header names when they are lowercase on most websites, but for your website they stayed lowercase when imported in my system and I was only looking for the headers with the first letters in uppercase. I have no idea why that is or why I didn't encounter this before, but I now made the code properly case-insensitive.

      clarkwinkelmann Yes, that's the site I was talking about.

      That's a bit of strange issue, but with a super fast find and fix, thanks 👍

      Hello everyone, I use flarum on my apache2 + mariadb server. Can you tell me how to fix these errors?

        Forhack Hi, the reason is that your Let's Encrypt ssl certificate is only valid for forhack.ru but not for www.forhack.ru. You can create a separate certificate for www using Certbot, e.g.

        sudo certbot certonly --apache -d domain.com -d www.domain.com

        and then adding this to the Apache configuration.

          It seems like I accidentally broke something during the last update. The reports missing HSTS no longer rendered in some browsers, and CSP would be shown enabled on all reports (assuming the report was showing up in the first place). Those issues are now fixed.

          I have added some information about the HTTPS certificate and the IP under the request log:

          Unfortunately websites that use Cloudflare and other similar proxy services will always show the same country (most likely the US) since those providers use Anycast to route their IPs to different locations close to the client's location, and the location of the origin server location behind the scenes can't be easily guessed.

          The hope with certificate information was to more easily identify what's going wrong when a certificate is invalid, but most self-signed certificates seem to not have any "issuer" data at all, so it's not that useful. I unfortunately don't have access to the full certificate but only some information that CURL outputs during its certificate validation. I don't want to make any additional requests just to download the full certificate for now. I'll see whether I can export the raw certificate out of CURL somehow but I didn't find any solution that could be implemented as a Guzzle plugin.

          2 months later
          a month later

          The lab is now able to distinguish between 1.1 and 1.2 Flarum versions, and able to find the versions of extensions compiled with webpack 5.

          Let me know if you notice anything out of the ordinary or if any extension is not showing up for your forum.

          7 days later

          This page isn’t working

          lab.migratetoflarum.com is currently unable to handle this request.
          HTTP ERROR 500

          🙁

            Thanks for this service, I managed to transform my forum from D to A+ 🙂 Wasn't easy since I'm on Siteground which ignores the .htaccess file, so had to create custom ignore URL-s on the Siteground interface as well as modify my DNS records, page forwarding rules on CloudFlare and other settings (enable HSTS for example).

            I have added a new page to the website https://lab.migratetoflarum.com/stats

            For now you have stats about ratings and extension count, but I'm thinking of adding Flarum version, javascript size and page generation time. Let me know if you have any other idea! (the stats are generated from data I already have inside the scans in the database)

            The minimum extension count probably doesn't make much sense because it likely refers to a scan where I was unable to find all extensions.

              11 days later

              DarkXero You have 2 issues:

              1. www.techxero.com needs to return a 301 redirect to techxero.com. Currently, both URLs return the site.
              2. You might want to enable HSTS headers which will require that your site be served via https.

                DarkXero you can use this extension to obtain the correct configuration in "1 step" https://discuss.flarum.org/d/19307-canonical-url-redirect

                If you want to do it "the proper way" without an extension, you can search something like "<your hosting> force www" or respectively "no-www" depending on your preferred domain. If your hosting is managed, it might be one click in the management panel. Or it might be in your provider's online documentation. If it's a VPS or if there's no documentation, you can search for "<webserver> force www", for Apache, Nginx or other webserver.

                Basically there are many different ways to achieve it depending on your exact hosting situation. If you need further help, please let us know what kind of hosting you are using for your forum and which company provides it.

                  clarkwinkelmann My hosting is shared with limited access... Plus no idea where to fix that... But will try extension easier