之前做了一個項目，要求用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可執行配置文件會好一點應該。
這是開發過程中的奇思妙想，有不中聽的不專業的還請各位海涵。