Error on aggregated css files for users forced to reset password

I ran into this issue on our Drupal 10 site this week. A user updated his password, and after the Admin css would not load. Found this post and followed the steps above, which would temporarily allow the user to display the site correctly. Unfortunately, upon logout and login, the css would again fail to load for that user.

I ended up uninstalling the Password Policy module completely to resolve this issue. We completed our Drupal 9 -> 10 upgrade on Nov. 1, 2023. This is the first account to update its password since the upgrade was released.

I ran into the same issue in a Drupal 10 site, when testing this module for the first time (version 4.0.0).

Changing the version to 4.0.0, since version 8.x-3.x-dev works with Drupal 8 and 9, which are not supported anymore.

One of the items in the Drupal 10.1.0 changelog

CSS and JavaScript aggregation performance improvements
Instead of the aggregated JS/CSS files being generated when the page is loaded they are (as of Drupal core 10.1.0) generated when they are requested.
A site using Password Policy will force a user to change their password when it has expired... When a user logs in with an expired password the are redirected to their account edit page. My supposition is that when a user with an expired password gets to the account edit page and the styles/script aggregations haven't been recently generated (since the most recent cache clear) their browser tries to request these files but Password Policy is instead causing a redirect to the user's account edit page... this is sent as a text/html page instead of the normal CSS or Javascript mime type... I imagine if you looked at your browser's Developer tools network tab you would see h HTTp status code as a 302 redirect as I am seeing.

thinking about this the same probably prevent derivative images from being generated... we should go to the EventSubscriber that is causing the redirect and have it check the path... if the request path is equal to the "public://" path we shouldn't redirect

As this problem has come up at work and is at the top of my priority list I am working on this, I expect to have a patch before I finish for the day.

Here is the patch to add the following to the ignore_routes list

• system.css_asset
• system.js_asset
• image.style_public

I tested the patch from #9 and it works as expected. It applies cleanly and fixes the issue with the aggregated CSS.

Thank you @jrglasgow!

Patch from #9 is working. Earlier this message was displayed in the console and styles were not applied to the page
Refused to apply style from '<URL>' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

I've applied the patch from #9 and it's working well (thanks @jrglasgow). @arun.testing3 are you saying it is working or it is not?

Could we look to get this patch merged in please? I think we could see this as a critical issue for the module. Thanks everyone.

Assigning to myself as I'm reviewing/merging ready RTBC fixes/updates over the next few days.

This doesn't happen on 9.5. Updating steps to reproduce.

Thanks everyone for the help on this issue. The fix has been merged and will be part of the next release.

Adding credit from duplicate issue:

#3380929: Expired users log in, css and js will not be loaded

Thanks! Looking forward to the next release.

This is part of the new 4.0.1 release.

Just to update here, where the bug has returned. I wonder if this is from TFA then?

I see now another path in the console.

Refused to execute script from '/user/xxx/security/tfa' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

Looks like it was another module called force_tfa. Sorry!

We had to add

      'system.js_asset',
      'system.css_asset'

to $ignore_routes = in_array($route_name, [ ]);