使用 apache2 通过 https 运行 django admin
我有一个在 apache 2.2.14 上运行的 django Web 应用程序,我想通过 https 运行管理应用程序。
在阅读了大量有关使用代理、编写中间件、运行替代 wsgi 脚本的讨论后,#httpd 中的小伙子来拯救我了。解决方案非常简单,我很惊讶我没有在网上找到它,所以我很好奇我是否做了一些明显的假设或错误。
一个复杂之处是我还想通过 https 在网站中运行我的 django 应用程序之一,这就是 /checkout 上的所有内容。
本质上,如果用户在 http 上请求以 /admin 或 /checkout 开头的 URI,他们将被重定向到该 URI,但在 https 上。相反,如果用户在 https 上请求不以 /admin 或 /checkout 开头的 URI,则他们将被重定向到该 URI,但在 http 上。
解决这个问题的关键是在我的 VirtualHost 配置中使用 Redirect 和 RedirectMatch 指令。
<VirtualHost *:80>
... host config stuff ...
Redirect /admin https://www.mywebsite.com/admin
Redirect /checkout https://www.mywebsite.com/checkout
</VirtualHost>
<VirtualHost *:443>
... ssl host config stuff ...
RedirectMatch ^(/(?!admin|checkout).*) http://www.mywebsite.com$1
</VirtualHost>
I have a django web application that's running on apache 2.2.14 and I want to run the admin application over https.
Having read considerable discussions on using a proxy, writing middleware, running alternative wsgi scripts, the chaps in #httpd came to my rescue. The solution is so simple, I was surprised I didn't find it online, so I'm curious to see if I've made some glaring assumptions or errors.
One complication was that I also wanted to run one of my django apps in the site over https, that is everything on /checkout.
Essentially, if a user requests a URI starting with /admin or /checkout on http, they are to be redirected to that URI but on https. Conversely, if a user requests a URI that does not start with /admin or /checkout on https, they are to be redirected to that URI but on http.
The key to solving this problem was to use Redirect and RedirectMatch directives in my VirtualHost configuration.
<VirtualHost *:80>
... host config stuff ...
Redirect /admin https://www.mywebsite.com/admin
Redirect /checkout https://www.mywebsite.com/checkout
</VirtualHost>
<VirtualHost *:443>
... ssl host config stuff ...
RedirectMatch ^(/(?!admin|checkout).*) http://www.mywebsite.com$1
</VirtualHost>
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
另一种方法是使用@secure_required装饰器。这将自动重写请求的 URL 并重定向到 URL 的
https://...
版本。那么您不必在*:80
配置中进行重定向。如果您希望其他流量通过正常的 http 流量,出于性能目的,可能仍需要*:443
配置。Another approach is to use
@secure_required decorator
. This will automatically rewrite the requested url and redirect tohttps://...
version of the URL. Then you don't have to have Redirect in*:80
configuration.*:443
configuration may still be required for performance purpose if you want other traffic to go through normal http traffic.我尝试了您的解决方案,但遇到了几个问题。首先,管理站点上的格式消失了,就好像找不到管理静态文件一样。其次,如果我尝试通过 https 访问非管理站点,浏览器将找不到它并将我重定向到雅虎搜索。奇怪的是,如果我编辑 yahoo 搜索 URL 以消除除正确 URL 之外的所有文本(减去
http://
),它将继续通过 yahoo 搜索我的网站。然而,重新输入完全相同的 URL 会将我带到我的网站。我通过简单地删除该指令解决了所有这些问题
。
我应该提到,我的网站上没有 /checkout 部分,我只是想保护 /admin 的安全。 ...是的,我确实用我的 URL 替换了“mywebsite.com”
I tried your solution, but ran into several problems. First, the formatting on the admin site disappeared, as if it could not find the admin static files. Second, if I tried to reach the non-admin site through https, the browser would not find it and redirect me to Yahoo search. Oddly, if I edited the yahoo search URL to eliminate all text except my correct URL (minus the
http://
), it would continue to search through yahoo for my site. However, typing the exact same URL afresh sent me to my site.I solved all of these issues by simply removing the
directive.
I should mention that I don't have a /checkout section on my site and am only trying to secure /admin. ... and yes, I did substitute my URL for "mywebsite.com"
您所描述的内容应该有效,但如果您需要更改哪些路径是/不是 HTTPS,将来可能会出现问题。因为此方法需要能够正确修改 Apache 配置文件,这意味着您不希望新手参与其中。如果搞砸了配置文件,您的网站可能会在眨眼间出现 500 错误。
我们选择一个简单的文本文件,其中包含必须是 HTTPS 路径的列表。项目中的任何人都可以对其进行编辑,并在加载时检查其正确性。我们在中间件中处理任何需要的到/从 HTTPS 的重定向,它似乎工作得很好。如果您运行的是 Apache 以外的任何东西,此方法也将起作用。
What you described should work, but there may be a problem in the future if you need to make changes to which paths are/are not HTTPS. Because this method requires the ability to correctly modify the Apache config file it means you do not want novices in the loop. Screw up the config file and your site can go 500-error in the blink of an eye.
We chose to have a simple text file that had a list of the must-be-HTTPS paths. Anyone on the project can edit it and it is checked for correctness when it is loaded. We handle any needed redirects to/from HTTPS in middleware and it seems to work just fine. This method will also work if you are running anything other than Apache.