/ 公开信息没问题，直截了当。使用ProxyPass 或ProxyPassMatch 将“/myApp”反向代理到您的内部Weblogic 服务器也很简单。您可能需要使用其他几个选项来确保正确设置代理主机名和 cookie 域。但是在“/private”中设置静态保护信息会有点棘手。
1) 您可以使用 mod_rewrite 检查 myApp 设置的 cookie 是否存在，如下所示：
RewriteCond %{HTTP_COOKIE} !the_name_of_the_auth_cookie
RewriteRule ^private - [F,L]
通过这样的方式检查 cookie 的问题在于，无法验证 cookie 实际上是一个有效的会话。人们可以任意创建一个具有该名称的 cookie，并能够访问 /private 中的数据。
2) 您可以对其进行设置，以便访问“/private”中的任何内容，将请求重写为 php 脚本或可以检查 cookie 以确保它是有效的session cookie，然后提供请求的页面。比如：
RewriteRule ^private/(.*)$ /cookie_check.php?file=$1 [L]
因此，例如，当有人访问“/private/reports.pdf”时，它会在内部重定向到“/cookie_check.php?file=reports.pdf”，这取决于这个 php 脚本来访问它需要的任何内容为了验证 /myApp 设置的 cookie。如果 cookie 是有效会话，则读取“reports.pdf”文件并将其发送到浏览器，否则返回 FORBIDDEN。
我认为这是最好的处理方式。
3) 如果您无法运行 php 或任何其他脚本，或者无法验证 cookie（例如使用 session_id 的数据库查找或类似的东西），那么您将不得不代理从 WebLogic 内部。这与通过“cookie_check.php”访问“/private”的基本思想基本相同，只是它是 WebLogic 服务器上的一个应用程序。就像 /myApp 一样，你需要设置一个反向代理来访问它，然后这个应用程序将获取请求（已从“/private/some_file”内部重写）检查 cookie 的有效性，读取“some_file”文件在 APACHE SERVER 上，然后将其发送到浏览器，或者发送 FORBIDDEN。这是总体思路：
ProxyPass /CheckCookie http://internal_server/check_cookie_app
RewriteCond %{REMOTE_HOST} !internal_server
RewriteRule ^private/(.*)$ /CheckCookie?file=$1 [L]
此条件通过 /CheckCookie 应用程序重新路由并非源自“internal_server”的所有“/private”请求，并且由于该应用程序在“internal_server”上运行，它可以访问“/private”中的文件就好了.这是一种迂回的做法，但如果 /myApp 发出的会话 cookie 的有效性只能在 WebLogic 服务器上检查，您将不得不来回重新路由请求或类似的东西。