之前做了一个项目，要求用Angular7做前端，Django做后端。
其实标准做法是用Django RESTful Framework 做后端，Angular写WebApp。
然而Django是已经现成的，因为之前网站是完全用Django+Jquery做的，所以Django是原生的，要改版还有点小麻烦，所以我就想偷偷懒，直接拿原生Django做Angular的后端接口。
Angular的跨域问题已经是个老生常谈的问题了，在这里就不做介绍了。
但是以下的问题就不是Angular跨域的问题能解决了，因为Django原生自带的用户验证是基于session的，原生网站登录后，可以按F12打开控制台看见cookie中含有session key。但是由于浏览器的安全限制问题，导致如果是跨域请求，那么这个sessionkey会自动被浏览器过滤掉，所以就导致了angular登陆无限失败。
那么怎么办呢，苦思冥想后，突然，我发现在做Angular开发测试运行的时候，可以把npm命令修改，使得后台地址强行与Angular地址拉在一起，也就是代理。那么既然测试环境可以做代理，那我想Apache也可以做反向代理。话不多说，上Apache的配置文件代码：
首先你需要在/etc/apache2/ports.conf 中添加一行，使apache可以监听两个端口，我这里开的是79端口:
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Listen 79
然后关键的配置来了，在/etc/apache2/sites-available 文件夹中新建一个文件，我这边就取名django.conf啦，配置如下：
<VirtualHost *:80>
DocumentRoot 你的angular路径
<Directory 你的angular路径>
Require all granted
AllowOverride All
Options FollowSymLinks
</Directory>
ProxyPass /api http://localhost:79/
ProxyPassReverse /api http://localhost:79/
</VirtualHost>
<VirtualHost *:79>
DocumentRoot 你的django路径
WSGIDaemonProcess FrontEnd processes=6 threads=2 python-path=你的django路径
WSGIProcessGroup FrontEnd
<Directory 你的django路径>
Require all granted
</Directory>
Alias /static/ 你的django路径/store/static/
WSGIScriptAlias / 你的django路径/web_settings/wsgi.py
</VirtualHost>
到此部署配置就差不多快完成了，接着输入：
a2ensite django.conf;\
service apahce2 restart;
应用你的配置并重启apache服务，这样就完成了所有的部署。
当然了，要做这个配置需要启动apahce的proxy功能，大家可以看一下配置文件
可以看到，我用79端口配置了一个虚拟主机，发布了Django项目。然后用80端口配置了一个虚拟主机，发布了Angular项目，同时在这个Angular虚拟主机上配置了反向代理ProxyPass，设置/api这个路径自动转发给Django的虚拟主机，所以在Angular项目中应该避免有/api这个路由配置才能使这个配置生效，当然了“/api”这个转发路径是可以自定义的，大家可以根据自己的情况自己改名字。
反思（优缺点）：
优点：
可以完全规避Angular跨域的问题，Django可以不用设置跨域允许，Angular同样也不需要设置跨域头。因为Apache的反向代理已经强行将Django和Angular拉在了一个域里；自然而然，浏览器的跨域安全规则也就对这样的部署方式无效了，原生Django做API的后台验证的Session key可以正常传给Angular前台。
缺点：
由于做了反向代理的操作，所以在高并发性能方面可能要大打折扣了，不过Django本来就不是用来处理高并发的框架，它本身是用来做管理系统的，所以这个缺点似乎可以忽略。
配置可能麻烦了点，做成Dockerfile或者.sh可执行配置文件会好一点应该。
这是开发过程中的奇思妙想，有不中听的不专业的还请各位海涵。
