CSS loading issue after hosting keycloak on linux with nginx as proxy server

[pramodprk]

Describe the bug

Hi,
We have hosted the Keycloak 18.0.0 version on Linux server with nginx as reverse proxy. We are getting following issue in console on keycloak login page in browser console. Css file app.css and base.css file that exists in @patternfly folder is not getting loaded.

Refused to apply style from 'https://authqc.gc-solutions.net/resources/hu2zt/common/keycloak/web_modules/@patternfly/react-core/dist/styles/app.css' because its MIME type ('') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
auth:1

   Refused to apply style from '[https://authqc.gc-solutions.net/resources/hu2zt/common/keycloak/web_modules/@patternfly/react-core/dist/styles/base.css'](https://authqc.gc-solutions.net/resources/hu2zt/common/keycloak/web_modules/@patternfly/react-core/dist/styles/base.css) because its MIME type ('') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

auth:1

We have checked that the files are available there.
Event after much googling, not able to find the proper solution of the issue. Please suggest the reason and the possible solution. Here the screenshots are attached for reference.

Version

18.0.0

Expected behavior

CSS should be loaded properly. For reference

Actual behavior

CSS is not loading properly. For reference.
Hosted URL is https://authqc.gc-solutions.net/realms/master/protocol/openid-connect/auth?client_id=security-admin-console&redirect_uri=https%3A%2F%2Fauthqc.gc-solutions.net%2Fadmin%2Fmaster%2Fconsole%2F%23%2Frealms%2Fmaster%2Ftheme-settings&state=27ce51b1-341f-491f-a40f-0b5185b56e0d&response_mode=fragment&response_type=code&scope=openid&nonce=8d3b2b6f-ef06-4bab-8514-0cee95cc3229&code_challenge=PnSMBAJOyLSSY9QMrO-zyUnQZnr4G9iQ1DgbIZXynQc&code_challenge_method=S256

How to Reproduce?

No response

Anything else?

No response

[mazenaissa]

Hello, I was getting the same issue. There were many requests returning 404 (js & CSS) that's why the page is not correctly loaded. My problem was fixed after configuring my reverse proxy like the below :

location /keycloak {
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Server $host;
            proxy_set_header X-Forwarded-Port $mapped_server_port;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

[pramodprk]

proxy_http_version 1.1;

Thanks for prompt reply, we have already done these settings, but still getting same issue.

[mazenaissa]

Could you share a screenshot from the network tab of the chrome-dev-tools when trying to open the admin-console?

[pramodprk]

Could you share a screenshot from the network tab of the chrome-dev-tools when trying to open the admin-console?

Thanks, here is the screenshot:

It is displaying 404 not found, but I have checked these files are available there.

[malweka]

I was seeing something similar with Keycloak v19.2 and Nginx as reverse proxy. Some resources were returning with a 404 response on the browser, but I was getting a 200 response when I used CUrl. I tracked it down, and for me the difference was the **Accept-Encoding** header. The browser's request included that header while I didn't in my CUrl command.

Basically, for some requests if the request had an Accept-Encoding with gzip in the value, Keycloak would return 404 not found. If Accept-Encoding is not present or any other value except gzip is passed, Keycloak served the resource fine. What I ended up doing was:

1. Enable Nginx compression: I followed this guide
2. Overwrote Accept-Encoding header I received from the client and let Nginx do the compression. I added proxy_set_header Accept-Encoding *; to my configurations.

My complete Nginx configuration:

server {
    server_name   auth-server.mydomain.dev;

    location / {
        proxy_pass         http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_set_header   Accept-Encoding *;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_buffer_size   256k;
        proxy_buffers   4 512k;
        proxy_busy_buffers_size   512k;
        proxy_hide_header       X-Content-Type-Options;
    }

This solved the issue for me. I believe there may be an issue on how Keycloak handles gzip compression when behind a reverse proxy.

[dominikschlosser]

We have a similar but slightly different issue since Keycloak 19... I noticed that the random-looking part behind /resources/ in the URL (/resources/z6yq4/common/keycloak/web_modules/@patternfly/...) seems to differ in each instance we start. So when there are multiple instances running behind a load-balancer, we get a 404 each time we dont hit the correct instance (the one which generated the Web-UI)...

[stianst]

If you get different URLs and have the same versions of Keycloak in the cluster it may be that clustering isn't configured properly

[dominikschlosser]

If you get different URLs and have the same versions of Keycloak in the cluster it may be that clustering isn't configured properly

Further testing showed, that it is a side effect of using the hotrod-MapStorage. Created #14683 to track this issue.

[mikesutton]

I don't know if this will help but I had the same issue, it was happening intermittently (no idea why). Then it would happen permanently. Ignore the intermittent - because I think that was just poorly remembered as I was trying all kinds of things.

What worked is:

the themes/keycloak.v2/account/src

• run npm install
• run npm run-script build

This creates everything required puts them in the right places.

Seems convoluted, but it solved my issues of missing files.

[SpiderD555]

2. Overwrote Accept-Encoding header I received from the client and let Nginx do the compression. I added proxy_set_header Accept-Encoding *; to my configurations.
   This solved the issue for me. I believe there may be an issue on how Keycloak handles gzip compression when behind a reverse proxy.

Thank you @malweka
I had the same problem, but with Haproxy. When I set the Accept-Encoding header to * as you wrote it all started to work for me again

[bahaa]

I think this problem happens because you are not passing --optimized parameter to the kc.sh start script. If you are using Docker you should use something like this:

ENTRYPOINT ["/opt/keycloak/bin/kc.sh", "start", "--optimized"]

[vmuzikar]

I believe the issues with Accept-Encoding are more related to the UI, hence re-assigning to @keycloak/ui. The --optimized flag should not affect this. What that does it turns off the automatic re-augmentation for improved start-up time, see the related docs.

[edewit]

maybe this is going wrong

keycloak/services/src/main/java/org/keycloak/encoding/ResourceEncodingHelper.java

Line 8 in 76f7fbb

String acceptEncoding = session.getContext().getRequestHeaders().getHeaderString("Accept-Encoding");

[cvallesi-kainos]

Having this issue today with keycloak 21 running in codecentric/keycloakx helm chart.

Deploy in single replica have no issue whatsoever but of course as soon as there are 2+ I can start seeing this issue as well.
Maybe I am missing some configuration for the sh.exe command?

[Lexachoc]

I also have the problem and it has been bothering me for a long time, today I solved it simply by adding user: root

  keycloak:
      build: .
      volumes:
        - ../nginx/cert_sso/cert_sso_combine.pem:/opt/keycloak/conf/cert.pem
        - ../nginx/cert_sso/key_sso.pem:/opt/keycloak/conf/key.pem
      depends_on:
        - keycloak-db
      networks:
        - internal
        - proxy-net
      command:
        - --verbose start
      ports:
        - "8443:8443"
      restart: always
      user: root  # Run the container with root user *This solved the issue!*

But I don't know if there would be a security problem when using user: root.
If anyone knows, please let me know!

P.S. I'm using Nginx Proxy Manager, below is my configurations:

  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP		$remote_addr;
    proxy_pass       https://keycloak:8443;

    # add these to solve 502 error in registration
    # see: https://keycloak.discourse.group/t/nginx-reverse-proxy-shows-502-for-keycloak-registration-form-submission/10550
    proxy_buffer_size 128k;
    proxy_buffers 4 256k;
    proxy_busy_buffers_size 256k;
  }

[jonkoops]

@vmuzikar I don't believe this is a UI issue. We simply create a bunch of static files that are served from the Keycloak server. I don't think this belongs in our domain.

[sekroots]

Hello. How can we solve this issue?

I am facing it locally ( with no nginx). The resource from “http://localhost:8080/resources/fniuz/welcome/keycloak/node_modules/patternfly/dist/css/patternfly.css” was blocked due to MIME type (“”) mismatch (X-Content-Type-Options: nosniff).
The resource from “http://localhost:8080/resources/fniuz/welcome/keycloak/node_modules/patternfly/dist/css/patternfly-additions.css” was blocked due to MIME type (“”) mismatch (X-Content-Type-Options: nosniff).

This is my docker-compose.yml:

` version: '3'

services:
keycloak:
image: quay.io/keycloak/keycloak:22.0.3
user: root
container_name: kc
command: start-dev
env_file:
- .env
ports:
- 8080:8080
depends_on:
db:
condition: service_healthy
networks:
- keycloak_network
volumes:
- ./themes:/opt/keycloak/themes
- ./configuration:/opt/keycloak/standalone/configuration

db:
image: mysql:8.0.30-debian
container_name: kc_db
volumes:
- ./.docker/dbdata:/var/lib/mysql
env_file:
- .env
ports:
- 3307:3306
security_opt:
- seccomp:unconfined
healthcheck:
test: ["CMD", "mysqladmin" ,"ping", "-h", "localhost"]
interval: 5s
timeout: 10s
retries: 3
networks:
- keycloak_network

networks:
keycloak_network: `

GPT3.5 said: The error you're encountering in Keycloak, specifically the MIME type mismatch with the X-Content-Type-Options header, can be resolved by ensuring that the web server (in this case, Keycloak) is correctly configured to serve the requested resources with the appropriate Content-Type header.

Here's how you can troubleshoot and potentially fix this issue:

Check Resource URLs: Ensure that the resource URLs in your Keycloak configuration or HTML files are correct and properly reference the CSS file. The URL you provided appears to be a relative path to a CSS file. Make sure that it's accessible from your Keycloak Docker container.

Server Configuration: Make sure that your Keycloak Docker container or the web server it's running on is properly configured to serve CSS files with the correct Content-Type. The server should be able to determine the MIME type of the file and set the appropriate Content-Type header.

Content-Type Header: The error message mentions that the MIME type is empty (""). You should check if the web server is setting the Content-Type header for CSS files. It should be set to text/css. If it's not being set correctly, you may need to configure your server to handle CSS files appropriately.

X-Content-Type-Options Header: The X-Content-Type-Options header is a security feature that instructs the browser not to interpret files as something other than what is declared by the server. Ensure that your server is not blocking the CSS file by setting this header to "nosniff." In most cases, "nosniff" is a sensible and secure value for this header.

CORS Policy: If you're loading resources from a different domain or port, you might need to configure Cross-Origin Resource Sharing (CORS) policies to allow these requests. Ensure that your server allows requests from the domain where your Keycloak instance is hosted.

Browser Cache: Sometimes, issues can be related to cached files in your browser. Try clearing your browser cache and reloading the page to ensure you are not getting a cached response.

Docker Network Configuration: If your Keycloak Docker container is trying to access resources from another Docker container or a different host, ensure that your Docker network configuration is correct and allows communication between the containers or hosts.

Proxy Server Configuration: If you are using a reverse proxy (e.g., Nginx, Apache) in front of your Keycloak container, ensure that it is correctly configured to handle requests and set appropriate headers.

Keycloak Configuration: Check the configuration of Keycloak itself. Ensure that the base URL and realm settings are correct. If you have a specific theme configured, verify that it's set up correctly.

Docker Network Bridge: If you're running Keycloak in a Docker container, ensure that your container is using the correct network bridge mode and can access the necessary resources.

[yash2code]

Hello. How can we solve this issue?

I am facing it locally ( with no nginx). The resource from “http://localhost:8080/resources/fniuz/welcome/keycloak/node_modules/patternfly/dist/css/patternfly.css” was blocked due to MIME type (“”) mismatch (X-Content-Type-Options: nosniff). The resource from “http://localhost:8080/resources/fniuz/welcome/keycloak/node_modules/patternfly/dist/css/patternfly-additions.css” was blocked due to MIME type (“”) mismatch (X-Content-Type-Options: nosniff).

This is my docker-compose.yml:

` version: '3'

services: keycloak: image: quay.io/keycloak/keycloak:22.0.3 user: root container_name: kc command: start-dev env_file: - .env ports: - 8080:8080 depends_on: db: condition: service_healthy networks: - keycloak_network volumes: - ./themes:/opt/keycloak/themes - ./configuration:/opt/keycloak/standalone/configuration

db: image: mysql:8.0.30-debian container_name: kc_db volumes: - ./.docker/dbdata:/var/lib/mysql env_file: - .env ports: - 3307:3306 security_opt: - seccomp:unconfined healthcheck: test: ["CMD", "mysqladmin" ,"ping", "-h", "localhost"] interval: 5s timeout: 10s retries: 3 networks: - keycloak_network

networks: keycloak_network: `

GPT3.5 said: The error you're encountering in Keycloak, specifically the MIME type mismatch with the X-Content-Type-Options header, can be resolved by ensuring that the web server (in this case, Keycloak) is correctly configured to serve the requested resources with the appropriate Content-Type header.

Here's how you can troubleshoot and potentially fix this issue:

Check Resource URLs: Ensure that the resource URLs in your Keycloak configuration or HTML files are correct and properly reference the CSS file. The URL you provided appears to be a relative path to a CSS file. Make sure that it's accessible from your Keycloak Docker container.

Server Configuration: Make sure that your Keycloak Docker container or the web server it's running on is properly configured to serve CSS files with the correct Content-Type. The server should be able to determine the MIME type of the file and set the appropriate Content-Type header.

Content-Type Header: The error message mentions that the MIME type is empty (""). You should check if the web server is setting the Content-Type header for CSS files. It should be set to text/css. If it's not being set correctly, you may need to configure your server to handle CSS files appropriately.

X-Content-Type-Options Header: The X-Content-Type-Options header is a security feature that instructs the browser not to interpret files as something other than what is declared by the server. Ensure that your server is not blocking the CSS file by setting this header to "nosniff." In most cases, "nosniff" is a sensible and secure value for this header.

CORS Policy: If you're loading resources from a different domain or port, you might need to configure Cross-Origin Resource Sharing (CORS) policies to allow these requests. Ensure that your server allows requests from the domain where your Keycloak instance is hosted.

Browser Cache: Sometimes, issues can be related to cached files in your browser. Try clearing your browser cache and reloading the page to ensure you are not getting a cached response.

Docker Network Configuration: If your Keycloak Docker container is trying to access resources from another Docker container or a different host, ensure that your Docker network configuration is correct and allows communication between the containers or hosts.

Proxy Server Configuration: If you are using a reverse proxy (e.g., Nginx, Apache) in front of your Keycloak container, ensure that it is correctly configured to handle requests and set appropriate headers.

Keycloak Configuration: Check the configuration of Keycloak itself. Ensure that the base URL and realm settings are correct. If you have a specific theme configured, verify that it's set up correctly.

Docker Network Bridge: If you're running Keycloak in a Docker container, ensure that your container is using the correct network bridge mode and can access the necessary resources.

facing the same. have you resolved it ?

[mwllgr]

For anyone seeing this after an upgrade to Keycloak 23:
I had to change my login/theme.properties:

stylesCommon=node_modules/@patternfly/patternfly/patternfly.min.css node_modules/patternfly/dist/css/patternfly.min.css node_modules/patternfly/dist/css/patternfly-additions.min.css lib/pficon/pficon.css
## Pre-23: stylesCommon=web_modules/@patternfly/react-core/dist/styles/base.css web_modules/@patternfly/react-core/dist/styles/app.css node_modules/patternfly/dist/css/patternfly.min.css node_modules/patternfly/dist/css/patternfly-additions.min.css lib/pficon/pficon.css

[pedroigor]

Looks like #24928 is enough to fix this issue. Based on one of the screenshots and the last reply from @mwllgr, the built-in theme was using an unexpected location (web_modules/...) to reference static resources from patternfly.

Perhaps we should also have added this to the release notes to make it easier migrating custom themes as per @mwllgr comment.

[latchukarthick98]

I still have this MIME type issue on Keycloak 21.0.1
Refused to apply style from https://redacted/res /realms/master/accouad36-70f3320904:1 ources/a8ymg/common/keycloak/web modules/@patternfly/react-core/dist/styles/base.css' because its MIME type ('') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

Also few resources especially under the command folder are not found:

GET https://redacted/resources/a8ymg/common/keycloak/web_modules/react-router-dom.js net::ERR_ABORTED 404 (Not Found)

This happens only when I access the account console page with the keycloak.v2 theme. If i switch back to legacy account theme there are no issues. I tried installing in my local machine and it seems to work fine.

here is my reverse proxy (NGINX) config:

upstream keycloak-web {
 server <IP>:8080;
}

server {
  # set proper server name after domain set
  server_name <your-domain>;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-XSS-Protection "1; mode=block";
  # log files
  access_log  /var/log/nginx/-access.log;
  error_log       /var/log/nginx/-error.log;
  #   increase    proxy   buffer  size
  proxy_buffers   16  64k;
  proxy_buffer_size   128k;
  proxy_read_timeout 900s;
  proxy_connect_timeout 900s;
  proxy_send_timeout 900s;
  proxy_next_upstream error   timeout invalid_header  http_500    http_502
  http_503;
  types {
    text/less less;
    text/scss scss;
  }
  #   enable  data    compression
  gzip    on;
  gzip_min_length 1100;
  gzip_buffers    4   32k;
  gzip_types  text/css text/less text/plain text/xml application/xml application/json application/javascript application/pdf image/jpeg image/png;
  gzip_vary   on;
  client_header_buffer_size 4k;
  large_client_header_buffers 4 64k;
  client_max_body_size 0;
  location / {
    proxy_pass  http://keycloak-web;
    # by default, do not forward anything
    proxy_redirect off;
    proxy_set_header Host $host;
  }
  location ~* .(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 2d;
    proxy_pass http://keycloak-web;
    proxy_set_header Host $host;
    add_header Cache-Control "public, no-transform";
  }
  # cache some static data in memory for 60mins.
  location ~ /[a-zA-Z0-9_-]*/static/ {
    proxy_cache_valid 200 302 60m;
    proxy_cache_valid 404      1m;
    proxy_buffering    on;
    expires 864000;
    proxy_set_header Host $host;
    proxy_pass    http://keycloak-web;
  }
  location /js/ {
    proxy_set_header Host $host;
    proxy_pass    http://keycloak-web/js/;
  }


    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/<your-domain>/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/<your-domain>/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
  listen 80;
}


server {
    if ($host = <your-domain>) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


  server_name <your-domain>;
    listen 80;
    return 404; # managed by Certbot
}

Any idea what might be wrong? I also tried with Keycloak 22.0.3 it had the same issue.

[est357]

I'm using keycloak 23.0.4 in kubernetes as a cluster. I had configured infinispan clustering correctly but I used old DB env vars ( which I found online) to configure DB connection which are no longer honored: DB_VENDOR, DB_ADDR, DB_USER, DB_PASSWORD, DB_DATABASE. I found this out when I checked the DB and saw there no tables created in it. Because of this, the cluster had no common DB and so I had a lot of MIME errors and css was not being applied. Also sessions were not persisted between members of the keycloak cluster. Once I switched to the new env vars: KC_DB, KC_DB_URL_HOST, KC_DB_URL_PORT, KC_DB_URL_DATABASE, KC_DB_USERNAME, KC_DB_PASSWORD the DB got populated and everything worked flawlessly.
I'm saying that the DB is one more thing to check if you have these kinds of issues...