使用Clouflare访问规则在依赖REST API的通配符域上应用程序
我们使用 Cloudflare Access 来控制谁有权访问我们的临时环境。我们使用简单的 Google Auth 来识别我们团队中的用户。
URL *.mydomain.com 定义的策略如下：
- 包含以
@myteam.com结尾的电子邮件
问题在于，我们在相关 URL 上使用通配符因为我们有各种应用程序正在运行，例如：
dashboard.mydomain.comclient.mydomain.com
当一个应用程序通过 REST API 与另一个应用程序通信时，这会导致问题。从 client.mydomain.com 到 dashboard.mydomain.com/api 发出的请求被 Cloudflare 阻止，即。重定向到身份验证页面。
我尝试为 dashboard.mydomain.com/api 添加另一个策略并允许所有人（只是为了尝试），但它不起作用：
是我如何设置的想法这对吗？
We are using Cloudflare Access to control who has access to our staging environment. We use a simple Google Auth to identify users on our team.
The policy defined is like this for URL *.mydomain.com:
- include email ending
@myteam.com
The issue is that on the URL in question we're using a wildcard because we have various apps running like:
dashboard.mydomain.comclient.mydomain.com
And that causes a problem when say one app is communicating with the other via a REST API. The requests made from client.mydomain.com to dashboard.mydomain.com/api are being held up by Cloudflare, ie. redirecting to the auth page.
I've tried add another policy for dashboard.mydomain.com/api and allow EVERYONE (just to try out) and it didn't work:
Is my idea of how to set this up correct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的配置看起来没问题，我相信可能发生的情况是身份验证（cookie）在 API 请求期间没有传递到您的第二个子域。这通常可以追溯到 CORS 问题。
https://developers.cloudflare.com/cloudflare-one/policies /zero-trust/cors/
具体来说，您的 API 子域可能没有正确设置
Access-Control-Allow-Credentials以允许发送 cookie。在启用之前，您需要确保其他 CORS 标头已正确设置，以限制哪些站点可以允许请求（由于您允许经过身份验证的请求，因此可以降低 XSS 攻击的风险）。Your configuration looks alright, I believe what is probably happening is the authentication (cookie) isn't being passed to your second subdomain during the API request. This can usually be traced back to a CORS issue.
https://developers.cloudflare.com/cloudflare-one/policies/zero-trust/cors/
Specifically, your API subdomain may not have the
Access-Control-Allow-Credentialsproperly set to allow sending cookies. Before enabling, you'll want to ensure you'll also want to ensure the other CORS headers are properly setup to restrict which sites can allow requests (reduce risk of XSS attack now that you are allowing authenticated requests).