SonarQube 10.x webfonts inaccessible with non-default webroot


The included webfonts at /web/fonts (/server/sonar-web/public/fonts in repository) (namely /web/fonts/Inter/inter.css and /web/fonts/Ubuntu/Ubuntu.css) use a fixed URL “src: url('/fonts/...')” to access the WOFF2 files. However, this does not work, if SonarQube is hosted at a non-default webroot, that is specified with sonar.web.context.

Hey there.

What specific version of SonarQube are you using? This information is requested in the template post.

Looking at commit history for the directory, /server/sonar-web/public/fonts, it can be determined that the affected versions are,, and

Essentially all versions that have these fonts embedded. This only excludes the very first release,, in the 10 series.

In the release versions these individual CSS files are not accessed directly, but thru the compiled / compacted version at /web/js/outXXXXXXXX.css.

Hi @null, welcome to our community forums.

Can you describe how you set up your SonarQube instance and what you mean by “not work”? By setting up SonarQube using our official Docker image and a custom sonar.web.context, I got a 404 on that request. Is that the same issue that you are facing?

If this is the same issue, I created a ticket (SONAR-21369) for it.


Here I’m indeed referring that if SonarQube instance is configured to be served from a custom sonar.web.context (say, /sonarqube) prefix, any absolute URL missing this set prefix is potentially about to fail from user webbrowser perspective.

In this case the SonarQube instance is used thru a transparent reverse-proxy, applied by an user facing webserver. So, the user facing webserver is used for multiple different applications. SonarQube is simply one of the tetants and therefore must use an unique URL prefix. Exactly what the sonar.web.context (and sonar.core.serverBaseURL to some extent) is for.

One could apply an explicit URL rewrite to the webserver handling the proxying (say, /fonts/ to /sonarqube/fonts/), but given the fonts name is fairly common this is almost guaranteed to fail at some point.

JS appears to be simply applying a runtime prefix to each resource URL (images etc.). Unfortunately, as CSS url() is not dynamic and the precompiled CSS file is shipped with the release package (meaning that all non-default configuration values are too late for that game), fixing this might be tricky.

1 Like