Django における認証処理実装パターン - c-bata web
追記: 翔泳社さんからDjangoの書籍を出版するのでぜひ読んでみてください。 実践Django Pythonによる本格Webアプリケーション開発 作者:芝田 将翔泳社Amazon この資料は DjangoCongress JP 2018で話した「Djangoにおける認証処理実装パターン」 の解説記事になります。 2019/04/08 追記: GithubのコードはPython3.7 Django2.2にupdateしています) 何年か前に Djangoのユーザー認証まとめ という記事を書きました。今でもコンスタントに100PV/dayくらいアクセスのある記事なのですが内容が古く、実装時にハマりやすい注意点にもあまり触れることができておらず、おすすめできる資料ではありません。今回はDjangoCongress JPにて発表の機会をいただけたのですが、この機会に認証処理についてまとめ直すと同
CVE-2016-7401 CSRF protection bypass on a site with Google Analytics の解説
gistfile1.md CVE-2016-7401 https://www.djangoproject.com/weblog/2016/sep/26/security-releases/ https://hackerone.com/reports/26647 pythonのcookie parserが ; 以外もpairsの区切り文字として解釈するので、google analyticsのreferrer経由でsetされるcookieを使ってCSRF tokenを上書き可能だったという問題。 django側でcookie parser自前で実装、python本体は直ってないようだ https://github.com/django/django/commit/d1bc980db1c0fffd6d60677e62f70beadb9fe64a 多くのcookie parserは、pairsの区
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
パワフルではない言語が必要 – 表現力と合理性のトレードオフについて、Pythonを例に考える | POSTD
多くのシステムは“パワフル”であることを売りにしています。パワフルであることを悪いことだと指摘するのは困難に思えますし、この言葉を使う人々はほとんど全て、良いことと想定して使っているようです。 この記事では、 パワフルではない 言語やシステムが必要なケースも多いということを論じたいと思います。 まずその前に、この記事を書くにあたって、私自身のオリジナルの知見はほんのわずかしかない、ということを述べておきます。ここに述べた一連の考えの背景には、Hofstadterの著作 『Gödel, Escher, Bach: An Eternal Golden Braid』 （訳注：日本語版があります。 『ゲーデル、エッシャー、バッハ – あるいは不思議の環』 ）を読んだことがあります。この本を読んだことで、私自身の経験から得てきた原則について、考えがまとまりました。Philip Wadlerの投稿、
Jacob Kaplan-MossのPyCon 2015における基調講演: プログラミングの才能という都市伝説
Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTube The programming talent myth [LWN.net] PyCon 2015で、Djangoの貢献者であるJacob Kaplan-Mossが興味深い基調講演をしているので紹介する。LWM.netでほぼ全面書き起こしに近いまとめがあったので助かった。 自己紹介 Kaplan-MossはDjangoの貢献者であり、Herokuのセキュリテイ部門の部長である。PyCon参加者としては歴史が長く、その他のカンファレンスでもよく発表している。Pythonコミュニティは「自分にとってこの業界におけるとても重要なもの」であり、PyConの基調講演を行うということは、「自分のキャリア上の絶頂」である。 自分の最初のPyConの発表は2005年のことで、PythonとAppleScri
え？君せっかく Python のバージョン管理に pyenv 使ってるのに Vim の補完はシステムライブラリ参照してるの？ - Λlisue's blog
どうも、ご無沙汰してます有末です。 Pythonistaならpyenvだよねーってことで当初からバリバリ使わせていただいているのですが、最近djangoのプロジェクトを書く際に困ったのでまとめておきます。 具体的にはpyenvでPytho 3をインストールし、pyenv-virtualenvを用いて仮想環境を構築し、その仮想環境に django をインストールしただけでは jedi-vim の補完が効かないという問題です。 いくつかの要因が複合して複雑に成っていたので、ひとつずつメモしていきます。 忙しい人のための簡易書 普段からpyenvとpyenv-virtualenvを使用していてjedi-vimでdjangoの補完が効かなくて困っている。 とにかく補完を効かせたい。 戯言なんてどうでもいいという人は下記を~/.vimrcに記載してください。 " ~/.pyenv/shimsを$PA
Webフレームワークとは何か - HackerNews翻訳してみた
「HackerNews翻訳してみた」が POSTD (ポスト・ディー) としてリニューアルしました！この記事はここでも公開されています。 Original article: What is a Web Framework? by Jeff Knupp Weｂアプリケーションフレームワーク、略して「Webフレームワーク」がWeb対応のアプリケーション構築に広く使われているのは、皆さんご存じですよね。単純なブログからAjax機能を搭載した複雑なアプリケーションまで、Web上のすべてのページはコードで記述されています。最近気になるのは、FlaskやDjangoのようなWebフレームワークに興味を持ってはいるけれど、実際にはWebフレームワークの目的や機能をちゃんと理解していない開発者が意外に多いということです。そこでこの記事では、ややもすれば見落とされがちなトピックであるWeｂフレームワークの基
Python 2/3 両対応のために `unicode_literals` を使うべきか - methaneのブログ
背景 Python 2 用のコードを書くときは、 Python 3 対応を見越して # -*- coding: utf-8 -*- from __future__ import division, print_function, absolute_import をテンプレとして書いています。 __future__ はファイルごとにバラバラだと混乱を招くので、今関わってるプロジェクトでもこれを新規ファイルのテンプレとして登録してもらってます。 Python 3 の構文、リテラルを有効にする __future__ のうち、 unicode_literals だけは今まで使っていなかったのですが、ふと「あ、やっぱり使うべきだな」と思いついたので、そのへんをまとめます。 第三の文字列型 native string Python 2 には2つの文字列型 str (bytes) と unicode が
chefとcapistrano(Webistrano)っぽいのをPythonで（構築のみ） - dai-yamashitaの日記
Fabric+Webistranoっぽいのの構築したメモです。 rubyに入門しませんでしたm(_ _)m！！使用は、Pythonでいきたいなぁーっと。 pythonとshellの方が自分に実績があって、手に馴染むだけです。chefとcapistranoの方が、 現状では情報が多いので、誰得？になってしまうんだろうけど、自分用の記録。長編。。。 前は、phpでmakuoさん使ったデプロイツール作って使ってましたが（遠い目）今回は自前は辞め、 pythonで、chefっぽいものと、capistranoっぽいものを構築することが目的です。(capistranoはWebistranoを目標） 構築した環境は、Scientific Linux 6.4 x86_64です。 （インストール時のオプションは、Basic Serverで、カスタマイズで開発ツールを追加しています。） ■Fabricのインス
App Engine ドキュメント | App Engine Documentation | Google Cloud
App Engine は、大規模なウェブ アプリケーションを開発およびホスティングするための、フルマネージド型のサーバーレス プラットフォームです。アプリの開発では複数の一般的な言語、ライブラリ、フレームワークからの選択が可能で、開発したアプリのインスタンスのサーバー プロビジョニングとスケーリングは App Engine によってオンデマンドで行われます。詳細については、こちらをご覧ください。
Django と Python 3 - #python_adv
Django-ja の方からきました。こんにちわ。さて、昨日の Ian 先生のブログにも書いてある通り、ついに Django にも本格的に Python 3 の足音が近づいてきました。ただし現在 alpha 版が公開されている 1.5 では "実験的" なサポートで、1.6 以降で正式にサポートする予定となっています。あくまでも "実験的" であり、プロダクションでの利用は "非推奨" となっています。Django コミュニティでは、この 1.5 でサポートをテストしてもらい、そのフィードバックを呼びかけています。なのでプロダクションでの利用は 1.6 まで待ちでしょうね。また Python 3 サポートと同時に、Django 1.4 では Python 2.4 がサポートから外れ、1.5 では Python 2.5 がサポートから外れます。これで 1.7 以降から django.util
Pythonでの日本語メールはUTF-8がベストかも - TechTalkManiacs
Study Mailの開発で日本語メールの問題にぶつかりましたので、その解決方法を公開します。結論としては、Pythonの場合はUTF-8でエンコードしてしまうのがベストのようです。 Dajngo EmailMessageで文字コードを指定する よく知られているように、日本語で書かれたメールを送信する場合はiso2022でエンコードするのが一般的です。二バイト文字のエンコードに問題の多いことで知られるPythonですが、幸いエンコードそのものについては部品として切り出して使えるwebアプリケーションフレームワークDjangoを利用することで問題なく行うことができます。 Djangoには電子メールのメッセージを表現するEmailMessageクラスがあり、メールとしてのメッセージの組み立てを簡易化してくれます。文字コードについてもドキュメント化こそされていませんがソースを読むとencodin
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
Pythonフレームワーク、「Django 1.4」リリース
Django Software Foundationが「Django 1.4」をリリースした。Djangoは開発の効率化を実現する柔軟性の高いPythonフレームワークで、Pythonを使ってWebアプリケーションやWebサイトを構築する際に使用できる代表的なフレームワークのひとつ。 Django 1.4で最も注目すべき機能としてタイムゾーンのサポートが挙げられる。この機能を有効にすると、タイムゾーンに対応したオブジェクト内部では日付や時刻をUTCで保持し、ユーザに表示する時はローカルの時刻に変換するようになる。プロジェクトではDjango 1.4にアップグレードする場合に、タイムゾーンに注意する必要があるとし、ユーザへのケアとしてタイムゾーンの移行ガイドやFAQを用意している。 Django 1.4では、ORM(Object Relational Manager)に多数の改善も加えられて
CentOS 5.6 に Review Board 入れて日本語化 - めもめも
参考にしたものたち Installing on Linux | Documentation | Review Board mod_wsgiでDjangoを動かすまでを淡々と記録する - スコトプリゴニエフスク通信 mysql-python(mysqldb)のインストールで「error: Setup script exited with error: command 'gcc' failed with exit status 1」と出るときの対処法 - Layer8 Reference CentOSにPySVNをインストールする - スコトプリゴニエフスク通信 必要なものを入れていく libevent wget --no-check-certificate https://github.com/downloads/libevent/libevent/libevent-2.0.15-stabl
FireLogger
Usage Django: After installation, enable middleware by adding its path to MIDDLEWARE_CLASSES: firepython.middleware.FirePythonDjango. WSGI: After installation, enable middleware firepython.middleware.FirePythonWSGI. Custom: Look for inspiration at middleware.py Real-world examples FirePython added to Bloog (blog engine for GAE) FirePython added to DryDrop (GAE hosting engine for GitHubbers && !Pyt
Heroku 上で Django を動かす - Twisted Mind
Heroku | Cloud Application Platform Heroku と言えば Ruby/Clojure/Node ですが、 Django アプリ（というか Python アプリ)がデプロイできるようになったらしいので試してみました。 変更履歴 2011-09-21 gunicorn 対応しました github https://github.com/voluntas/heroku-template-django 環境 Mac OS X Lion でやっているので、Linux や Windows だとまた別だと思います。 必須 Git Python 2.7 Ruby (gem install heroku するためにいる) heroku にアカウントを作る というかそもそも Heroku のアカウントすら持っていなかったので、アカウント作るところから。 https://api
PythonとDjangoを使うときに押さえとくと良いもの - 偏った言語信者の垂れ流し
社内向け。 tokibitoの知識が偏ってるので、もっといろいろ知りたいなら社内チャットで他の人にも聞くこと。 Python easy_install setuptoolsかdistributeというパッケージで使えるコマンド。 @aodag 曰くsetuptools使わずに、distribute使えという話。 インストールはこんな感じ。 $ curl -O http://python-distribute.org/distribute_setup.py $ python distribute_setup.pyWelcome to Distribute’s documentation! — Distribute documentation pip パッケージのインストールに使う。後述のvirutualenvとかを使うならこれ。 インストールスクリプトで入れるか、easy_installなど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.yuku-t.com/entry/20101018/1287391988