【发布时间】:2012-04-04 13:14:09
【问题描述】:
我正在尝试在 ec2 上设置反向代理,以通过使用 nginx 的自定义域提供对我的 appengine 应用程序的安全访问。它似乎工作正常,除非页面需要用户服务。它重定向到 Google 帐户登录,然后转到 apppot 域,而不是我的自定义域。我知道 appengine 在测试中有 ssl,但我想要一个我现在可以使用的解决方案。是否有可能克服这个问题,还是我需要创建自己的用户?
以下是我的配置:
server {
listen 443;
server_name <custom-domain>;
keepalive_timeout 70;
ssl on;
ssl_certificate /etc/nginx/cert/server.crt;
ssl_certificate_key /etc/nginx/cert/server.key;
ssl_session_timeout 30m;
location / {
proxy_redirect off;
proxy_pass https://<appid>.appspot.com;
proxy_set_header Host <appid>.appspot.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_intercept_errors off;
}
}
我的域有一个指向 ec2 的 CNAME。
===
我找到了解决方法。仍然希望有一个更简单的,并希望得到反馈。
1) Client hits https: //mydomain.com/blah which goes through EC2 proxy https://appid.appspot.com/blah
2) The client is redirected to the google login page, with continue set as /aa?continue=/blah
3) Client logs into Google Accounts and is then redirected to https: //appid.appspot.com/aa?continue=/blah
4) Client hits https: //appid.appspot.com/aa which serves a redirect to https://mydomain.com/sc?c=ACSID&continue=/blah where ACSID is the Google account session cookie read by the handler for /aa.
5) Client hits https: //mydomain.com/sc?c=ACSID&continue=/blah which sets the ACSID session cookie for the domain mydomain.com and redirects to https: //mydomain.com/blah based on a continue parameter in aa passed to sc
以下是我的 web.xml
/ is publicly accessible
/aa is publicly accessible
/sc is publicly accessible
/* is restricted to logged in users
以下是处理程序中的限制(带有一些棘手的 url 转义):
/ --> if not logged in, redirect to login page continue=/aa
/aa --> if not logged in, redirect to login page continue=/aa
/sc --> if not logged in, redirect to login page continue=/aa
/* --> if not logged in, redirect to login page continue=/aa?continue=*
在此之后,即使通过使用 SSL 服务的代理,用户服务似乎也能正常工作。 ACSID cookie 现在位于 mydomain.com 上,并通过代理发送到 appengine。
appspot 域仍会显示给精通技术的用户,但这不是我主要关心的问题。我的目标是通过 https 提供服务并将我的自定义域保留在 url 栏中,并且使用我的自定义域通过不 SSL 提供用户数据更加安全。由于整个事务是通过 https 进行的,我认为这不会比使用没有 SSL 的 mydomain.com 暴露会话 cookie。无论如何,即使没有这种方案,任何其他跨站点攻击都可以工作。
我仍然不确定为什么 mydomain.com/_ah/conflogin?state=blah 会失败并需要此解决方法。
【问题讨论】:
标签: google-app-engine ssl nginx reverse-proxy