在我深入研究之前先澄清一下；我现在有工作要做，但我有一些担心&一个关于为什么和/或如何开始这个问题的问题。
我正在使用maven、reactjs、spring boot和cloudfoundry构建一个单页应用程序，在cloudfoundry中使用一个内部saml调用&一个在验证后重定向到应用程序的外部saml。
结构 classpath: /public 在目标jar中是这样的：

css/
   hashed.chunk.css
   main.chunk.css
js/
   some.chunk.js
   main.chunk.js
   maybeAnother.chunk.js.txt
media/
   images and icons stored here
index.html
some manifest
another file
another file
yada yada

saml由代理过滤执行，默认入口点是外部saml，内部是过滤后的代理。举个例子， www.example.com 会将您指向外部saml，但是如果用户访问 www.example_internal.com 这将在代理过滤器中定义，用户将被定向到内部saml，并在认证后由任一saml定向回主应用程序。
现在让我解释一下；默认情况下，在构建时使用默认 webpack.config.js 它将生成一个包含所有必要文件的构建目录，包括子目录，如 /css/**, /js/**, /media/** . 默认情况下，Spring Security 在身份验证过程中忽略这些子目录。当点击外部saml时，这个身份验证过程可以完美地工作，在身份验证之后，用户被引导回应用程序，应用程序按其应该的方式呈现。然而，萨米尔内部却采用了一种不同的战术，这让我感到难以置信。捆绑的 /**.css 文件和 /**.js 文件是index.html中定义的源文件（这是一个页面），将这些文件视为端点时没有直接引用。即使手动将所有内容设置为忽略身份验证调用中的所有css&js文件，问题仍然存在。在用户从内部saml被引导回主应用程序之后，安全服务接着继续执行 /**.css & /**.js 文件作为安全端点，这会导致应用程序错误地重定向，从而导致应用程序自身崩溃并出现多个mime类型错误。
两个saml如何重定向到完全相同的应用程序和页面，而内部却产生了这个问题？
我能解决这个问题的方法；现在我并不为它感到骄傲，因为我觉得这是一个黑客行为，而不是一个真正的修复方法是定义一个regex，在将索引作为视图加载时忽略请求Map中所有的*.css&*.js作为端点。我觉得这甚至是一个问题，这是非常奇怪和令人困惑的。我只是想了解这是怎么发生的。另外，如果有更好的方法来解决这个问题，那我一定要全神贯注。
谢谢你花时间读这篇文章。