Bug#1060897: standalone is permitted, when the local web server is in use
Hello, I deleted the first line in the file furo.css, which contained « @import url(/javascript/normalize.css/normalize.css); » and replaced it by the contents of the file normalize.css The release 2023.09.10+dfsg-3 might fix the bug, please feel free to reopen it, if it doesn't. Best regards, Georges. On Fri, 19 Jan 2024 09:46:57 +0100 Raphael Hertzog wrote: > Hi, > > On Thu, 18 Jan 2024, Georges Khaznadar wrote: > > On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog > > wrote: > > > [...] reported here and that you can see here: > > > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html > > > > when I browse this URL with the debugger's console active, I see that: > > > > The resource from > > “https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” > > was blocked due to MIME type (“text/html”) mismatch > > (X-Content-Type-Options: nosniff). > > > > Probably, it the webserver is configured to serve normalize.css as MIME > > type "text/css", the issue might be fixed. > > No, this is unrelated. The URL you list is just not valid. This domain > is managed by GitLab Pages and anything generated by the CI must > be self-contained in > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/ > > The fact that you have hardcoded an absolute link to > "/javascript/normalize.css/normalize.css" (which might work on a default > installation of a Debian server) means the resource is now looked up > outside of its artifact directory, and there's just nothing there > that can understand the purpose of its URL. You could have received > an error 404 just as well but you got something else presumably because > GitLab Pages has a number of hardening features to avoid malicious > behaviour. > > Cheers, > -- > ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ > ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1060897: standalone is permitted, when the local web server is in use
Hi, On Thu, 18 Jan 2024, Georges Khaznadar wrote: > On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog wrote: > > [...] reported here and that you can see here: > > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html > > when I browse this URL with the debugger's console active, I see that: > > The resource from > “https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” was > blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: > nosniff). > > Probably, it the webserver is configured to serve normalize.css as MIME > type "text/css", the issue might be fixed. No, this is unrelated. The URL you list is just not valid. This domain is managed by GitLab Pages and anything generated by the CI must be self-contained in https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/ The fact that you have hardcoded an absolute link to "/javascript/normalize.css/normalize.css" (which might work on a default installation of a Debian server) means the resource is now looked up outside of its artifact directory, and there's just nothing there that can understand the purpose of its URL. You could have received an error 404 just as well but you got something else presumably because GitLab Pages has a number of hardening features to avoid malicious behaviour. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#1060897: standalone is permitted, when the local web server is in use
On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog wrote: > [...] reported here and that you can see here: > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html when I browse this URL with the debugger's console active, I see that: The resource from “https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff). Probably, it the webserver is configured to serve normalize.css as MIME type "text/css", the issue might be fixed. Best regards, Georges. signature.asc Description: PGP signature
Bug#1060897: standalone is permitted, when the local web server is in use
Hi Georges, On Thu, 18 Jan 2024, Georges Khaznadar wrote: > Would you like to enable documents generated with furo to be usable even > when accessed under a file:// scheme? Yes, but I'd also like them to work when hosted on a random non-Debian webserver. My use case is documentation generated out of git and hosted on Gitlab pages. This is how I manage https://freexian-team.pages.debian.net/debusine/ and it works well, but when I tried to move that to furo I encountered the issues that I reported here and that you can see here: https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html > (1) I made an ITP for furo and packaged it for Debian, primarily because > I am maintaining the package sympy, and that once upon a time, it began > build-depending on furo. I assumed it was needed as a dependency and not your primary interest, thanks for packaging it anyway! It's actually a nice theme. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Bug#1060897: standalone is permitted, when the local web server is in use
Hello Raphaël, "normalize.css" can be found at the URL "/javascript/normalize.css/normalize.css" when one accesses the html files through a webserver, rather from the raw file system. For example, when I install the package python-sympy-doc, which depends on furo(1), the URL file:///usr/share/doc/python-sympy-doc/html/index.html misses furo's dark/light theme switcher, but the URL http://localhost/doc/python-sympy-doc/html/index.html does not miss it, as my local webserver (apache2) serves by default /usr/share/doc under http://localhost/doc and /usr/share/javascript under http://localhost/javascript. /usr/share/doc/* and /usr/share/javascript/* are usually not served worldwide, but one can write a configuration to allow some exceptions. Would you like to enable documents generated with furo to be usable even when accessed under a file:// scheme? Best regards, Georges. Notes: (1) I made an ITP for furo and packaged it for Debian, primarily because I am maintaining the package sympy, and that once upon a time, it began build-depending on furo. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
