Django proxyの設定方法

porxyを設定する理由
一般的に私たちのエージェント設定はブラウザに対して、通常はブラウザ設定で構成するだけですが、ブラウザに対してのみ有効で、私たちが自分で作成したプログラムに対していかなる効果もありません.この場合、ソフトウェア符号化にエージェント設定を追加する必要があります.---
Djangoのプロキシ設定
Pythonを使用してWebページにアクセスするには、urllib、urllib 2、httplibの3つの一般的な方法があります.その中でurllibは比較的簡単で、機能も比較的弱い.httplibは簡単で強力ですが、sessionはサポートされていないようです.したがってDjango開発ではurllib 2の方式,すなわち後述する方式が一般的である.
urllib 2の機能は非常に強力で、ここでは一般的な使用プロセスの紹介だけをします.

//    
proxy = "http://10.167.251.83:8080"
//      
opener = urllib2.build_opener(urllib2.ProxyHandler({'http':proxy}))
//      
urllib2.install_opener(opener)
//      
data= urllib2.urlopen(webUrl).read()

install_についてOpener(opener)の問題発生
グローバルエージェントの設定Opener(opener)以降は、後で使いやすいというメリットがあります.Javaのstaticメソッドとして理解できます.構成に成功すれば、再構成する必要がなく、直接使用すればいいです.例えば、私の図書館管理システムプロジェクトでは、図書の入庫情報源は2つに分けられ、1つは社内ネットワークサーバから、1つは豆弁サードパーティサーバから、urllib 2のエージェント設定は頻繁に切り替える必要があります.最初の書き方は

if request.GET.get('json_inner'):
   data= urllib2.urlopen(InnerUrl).read()
if request.GET.get('json_douban'):
//    
   proxy = "http://10.167.251.83:8080"
   opener = urllib2.build_opener(
		    urllib2.ProxyHandler({'http':proxy})
		    )
   urllib2.install_opener(opener)
   data= urllib2.urlopen(DoubanUrl).read()

これにより、プログラムが最初に実行されるのは問題ありませんが、2回目の図書情報検索操作でurllib 2がグローバルエージェントinstall_を設定したためです.Opener(opener)では、社内ネットワークサーバから図書情報を取得すると、直接外部ネットワークから接続され、情報が取得できなくなります.最後に、実行可能な折衷案を考えました.

//    
proxy = "http://10.167.251.83:8080"
if request.GET.get('json_inner'):
    opener = urllib2.build_opener(
		   urllib2.ProxyHandler({'http':proxy})
		   ).close()
	urllib2.install_opener(opener)
    data= urllib2.urlopen(InnerUrl).read()
if request.GET.get('json_douban'):
    opener = urllib2.build_opener(
		    urllib2.ProxyHandler({'http':proxy})
		    )
	urllib2.install_opener(opener)
    data= urllib2.urlopen(DoubanUrl).read()

大まかな考え方は、イントラネット接続を行う前に、グローバルな外部ネットワークエージェント設定をオフにし(closeメソッドを呼び出し)、外部ネットワークデータにアクセスする必要がある場合に外部ネットワークエージェント設定を再復元することです.
もちろんもう一つもっと良い方法があります(私はまだ使ったことがありません.正確性は検証されています).installを使用しません.Openerはグローバルの設定を変更し、直接openerのopenメソッドを呼び出してグローバルのurlopenメソッドの代わりにするだけで、興味があれば実践してみてください.
最後の「穴」
最後のピットと呼ばれるのは、この「ピット」がソフトウェア開発の最終段階である配置で発生したためです.私が書いたDjango符号化部分はwindow環境で行われているため、最後のプログラムの配置環境はUbuntu上にあります.Pythonはスクリプト言語がプラットフォームにまたがっているため、意外な問題は発生しません.しかし、導入後、urllib 2がどのように設定されても、プロジェクトプログラムは常に外部ネットワークo()＾)oにアクセスするしかないことがわかりました.最後に、以前のUbuntuが使いやすいようにシステムプロファイルを発見した.bashrcにグローバルproxyエージェントが設定されているため、プロジェクトソフトウェアプログラムはデフォルトで外部ネットワークから接続され、urllib 2構成は失効します.しかし、問題はまだ終わっていません.システムプロファイルbrashを変更してもプロジェクトプログラムは外部ネットワークプログラムにアクセスするしかなく、原因を探し続けていることに気づきました.最後に仕方なくコンピュータを再起動して最後の試みを行うしかありません.そして、プログラムは正しく実行することができます.その後、問題をまとめたところ、私たちが問題を解決する考え方に問題はないことが分かった.システムのプロファイルのためだ.bashrcにグローバルproxyエージェントが設定urllib 2の構成が失効するが、システムプロファイルを変更することが肝心である.bashrcが有効になるには、構成を再起動またはログアウトする必要があります!!これはどんなに痛い悟りなのか、小さな考えが足りないと数時間の浪費を招き、本当に「大きな穴」ですね.
http://www.xyczero.com/blog/article/4/.