ユーザー認証の手抜き
Webアプリ作っているといろんな局面でユーザー認証が必要になる局面がある。まじめにつくると果てしなく面倒だし、適当につくるとセキュリティ上問題になるので、要件に応じて適切に手抜きする必要がある。
適当なやつからしっかりしたやつまでなんとなくソートしていくとこんなかんじだと思う。
- 認証なし
- IPで弾く
- Basic認証(ソースコード、設定ファイルにパスワードベタ書き)
- Basic認証(DBにUserテーブルをつくってパスワードを保存。追加はcliとかで手動)
- login/logout画面作成。cookieなりmemcacheなりにセッションを保存
- webからユーザーを追加できるように
- password変更機能
- OAuth
- OpenID
- mailを送ってリンクをクリックさせてメールアドレスの所有確認
- メールアドレス変更機能
- メールを使ってのパスワードリセット機能
- OAuthで作ったアプリへの後からのメールアドレスとパスワード追加登録機能
- 二段階認証
不特定多数のユーザーが登録する場合に開発として楽なのはid/password方式。
メールアドレス認証とかがない純粋なidだとすごい楽です。
こういうときOAuth選びがちだけど意外と使い勝手悪い。
OAuth使うと発生する問題
- ライブラリの依存とか諸々ではまりやすい
- OAuth provider (TwitterとかFBとかギッハブとか)に依存することになる
- 複数のOAuth providerに対応すると1人のユーザーが複数アカウント重複してしまう可能性がでてきてめんどくさくなる
- Native Appつくるときに認証でWebView開いて(myapp(web) -> Twitter -> myapp(web) -> myapp(native))みたいなcallbackの嵐をやるハメになる
- Native Appのバイナリ内にサーバー側と同じConsumer Key/Consumer Secretを持つとセキュリティ上問題があるのでNativeでは持たないようにするなり、別のConsumer Keyを持つなりしないといけない
- 更にマジメな話をするとアプリ内WebViewで外部サービスのパスワード入力させて認証させるのはfishingのおそれがあるのでアドレスバーが信頼できる外部ブラウザアプリに飛ばして認証させたほうが良い
追記
OAuthは認可であって認証ではないうんぬんの話は承知しておりますが現実としてその辺に詳しくないエンジニアの皆様は「Twitterで認証」とおっしゃられてますし、TwitterにOAuthで認可を得てverify_credential.jsonを叩いた結果からuser_idを取得するとそれは認証として問題なく使えてしまうという現実もあります(余計な権限の認可もついていますが、そっちもなんだかんだで使うし)。OAuth単独だと認証機能がないというのは事実なんですが一般的に言うOAuthとは要するにTwitterでありFacebookでありそれらのAPIと組み合わせることで認証機能を得ることができるし、IDな人たちが大好きなOpenIDの最新規格であるOpenID ConnectだってOAuthでaccess_token取得するついでにIdentityもついてくるというTwitter APIのverify_credentialを呼ぶ手間が省けて共通規格にしましたみたいなもんだし、日曜深夜にこんな長文書くハメになるのでOAuthがどうとか認証とか認可とかの議論やめたい。
TwitterのRSSを生成する Twitter Great RSS をつくった
つくりました。
Twitter Great RSS
- 1人のユーザーのツイート一覧
- list
- 検索結果 (←NEW!)
がRSS化できます。
検索にも新たに対応しました。エゴサーチが捗りますね!
以前つくっていたもの(Twitter Good RSS)が、一部壊れているようで新規登録ができないとの連絡を受けていたんんですが、以前のやつは今見るとDB周りが色々絶望的で直したくなかったので新しいものを作りなおしました。
機能的にも上位互換なので今後はこちらをお使いください
neovimで新しくなったところまとめ
neovimは「vimを近代化させよう」というvimのforkです。
https://github.com/neovim/neovim
http://news.mynavi.jp/news/2014/02/26/097/
なかなかかっこいいので、現状どのような改修が行われたのかcommitを追いかけてみました
TL;DR
- 開発始まったばっかりなので総Commit数まだ少ない
- CMake使うようにした
- ゴミ掃除とサポートしたくない環境の切り捨てをした
- 実用段階になるには少なくとも半年以上はかかりそう
詳しく
Import vim from changeset v5628:c9cad40b4181
- ファーストコミット
- いらなそうなファイルとかマクロとか消したらしい
- Cmakeにビルドを移植したらしい
- fork元との差分はなし。あんまり丁寧じゃないね
Fix build on OSX/Archlinux and add README
- SELinux対応面倒なのでとりあえずコメントアウト
- OSX/Archlinuxでビルドが壊れているのを修正
- OSXでlibintl(gettextなどから使用される)を探すように&なんか色々ハックしてる
- Archlinuxでリンク時に-ltermcapをつけても名前が見つからずリンクできないのでtermcapを包有しているcursesをリンクすることで(-llibcurses)回避
わりと雑なハックが行われている模様
- 古いマクロとかさまざまな環境に対応するためのコードとかをごっそり削除
- Mac OS 9とかBorland C++ CompilerとかMSDOSとか
- libuvの乗り換えるためかsys/poll.hとか使うのやめている
- GUIは別プロセスにしてTCP接続する疎結合に切り替える予定のためかGUIまわりのコード(X11, GTK, ...)もごっそり削除
Automate libuv download and build
Add libtool to OSX installs
Add Arch dependency instructions to README.md
include a copy of the Vim License
- うっかり忘れていたっぽい。雑っぽい
Cleanup refactoring in main
Clean up main.c:parse_command_name
- 長いコードを別の関数に切り出したり
- 王道リファクタリングなことをしている
- TravisCI導入
First pass on getting build working on FreeBSD.
- FreeBSDでビルドできるように
- みんな自分のOSに対応させるし使ってないOSはどうでもいいということがわかっておもしろい
- バザール開発だ
README.md: fix ubuntu/debian deps
- 「For Ubuntu 12.04」ってなんだよ、俺はdebian使ってるんだという心の声が聞こえる
build-essentialはubuntuにしかないんだよ。要するに必要なのはlibtool, autoconf, g++だという心の声が聞こえる
追記: debianにもbuild-essentialはあるらしい(thx KoshianX!)。今手元のsqueezeで確認したら確かにありました。build-essentailではlibtool, autoconfは入らないようなのでそこを直したと思われる
Added 'neovim' to the feature list, following discussion on #44
- VimLからhas("neovim")でneovimがどうか判定できるように
scripts/common.sh: remove a couple bashisms
追記:bashでしか動かないバグをbashismsというらしい(thx KoshianX!)。
シェルスクリプト詳しくないので精進します
Adding neovim formula for Homebrew
Updating README file to use Homebrew for local builds
- Homebrewのfomula書いたぜ
> brew install neovim/neovim/neovim
でneovimが入る便利ライフに
コーディング規約とかガイドとかって難しいよねという話
注:細かくてどうでもいい話です
Cookpadの規約スタイルガイドについての話
https://github.com/cookpad/styleguide
@yayugu ?
2014-02-25 19:25:39 via YoruFukurou to @yayugu
@r7kamura なんかいきなり無言リプライしてすいません。ここ問題があると思ったんですけど中村さん的にどうですか
2014-02-25 19:28:09 via web to @r7kamura
@yayugu んー、問題があるって言えるほど知識無いから分かんない。規則じゃなくてガイドだから良いんじゃない?でも確かに、あえてlookupのコストを理由として上げるのはあんまり効果的じゃないね。リテラルで書く場合のキーの数とかC側で配列に最適化されてるレベルの大きさだし
2014-02-25 19:47:52 via YoruFukurou to @yayugu
[SHOULD] ハッシュのキーを Symbol にして良い場合は、文字列よりも高速に lookup できるので積極的に Symbol を使うこと。
ここの箇所、言いたいことは分かるんですがちょっと誤解を招くなと思った
具体的には
- 「可読性と一貫性」*1を目的にしているならパフォーマンスの話をするのはおかしい
- ハッシュのlookup速度が問題になるケースはかなり少ないので、一般的な状況ではキーをSymbolにすることにパフォーマンス上の優位点はない
- SymbolはGCされないので新しいSymbolがガンガン作られる状況(ex. ユーザからの入力を.to_symする, 巨大な文字列の集合を.to_symしたものでハッシュをつくるなど)ではメモリリーク*2が発生する。
という問題があると感じた。
で、r7kamuraさんに聞いてみたところ
いくつか勘違いしていたことに気づいた
こうしたらいいんじゃないかなという解決策
↑のようなことを丁寧に書くとクソ長くなってしまうのでもっと率直な理由にすればいいのでは
[SHOULD] ハッシュのキーを Symbol にして良い場合は、タイプしやすいしかっこいいので積極的に Symbol を使うこと。
Conference With Developers 2 を開催します
2月1日にConference With Developers 2というイベントを開催します。
昨年に引き続き今回は、
- ninjinkun http://ninjinkun.hatenablog.com/
- fladdict http://fladdict.net/blog/
- 岸川克己 http://d.hatena.ne.jp/KishikawaKatsumi/
- ishkawa http://blog.ishkawa.org/
という、iOS界で今をときめく/不動の大御所な皆様にお話しいただきます。
LTも募集中ですのでぜひご参加ください
そして老害になる
闇 Advent Calendar 2013の7日目として老害化の話をします。
ベンチャーじゃなく大企業につとめてよかったことは、さまざまな技術バックグラウンドを持つ人と仕事ができていることだ。
色々な流儀や文化の人たちと接し、ぶつかることで自分の視野がどんどん広がっていくのを感じている。
昔話をすると、学生時代、自分は主にRubyを書いていてJavaやPHPをダサいものだと考え、時にはそれを口にすることもあった。
しかしdisるための根拠などをしっかりと持っていたわけではなく、なんとなくで
最新技術=かっこいい、べんり
古い技術=ださい、めんどくさい
と考えていた
社会人になってからダサいと思っていたまともなPHPの書き方を知りそれはそれで悪くない、むしろRubyよりすぐれだところもたくさんある素晴らしい道具と知った。
逆にcoolだと思っていたnode.jsやCoffeeScriptに手を焼き、PhoneGapのような技術で作られたプロダクトに苦しめられもした。
それらをiOSネイティブに書き換えていく作業をするなかで見た目だけで敬遠していたObjective-Cの思想が大好きになったりもした。
DB設計の正しいやり方を身につけ、それまでに自分がActiveRecordのmigrationで適当につくったものがいかにひどいものだったかも知った。
経験を積めば積むほど、今まで自分がバカにしていたものがいかに優れているかがわかるようになったし、逆に今まで無条件で最高だと考えていた技術の欠点も見えてきて、新しい技術が単に新しくてcoolそうだというだけで飛びついたりすることは減ってきた。
エンジニアは気付けば新しくて楽そうなものに流れる傾向がある。
しかし、最高のまともなエンジニアになるためには新しいもの、古いもの、有名なもの、無名なものをイーブンに評価できるようになるべきでなのではないだろうか。
そう考えもあり、最近はC++をずっと勉強していて楽しい。Javaも深く知りたい。他にも知りたいことがたくさんある。
しかし、そういうことをやっているとどんどん周囲と考えが離れていくのを感じる。技術の話をしても噛み合わないことが増えてきているような気がする。
Rubyやnode.jsかじったやつが使ったこともないのにPHPやJavaを叩いてるのを見るとぶん殴りたくなる。
RDBの大した知識もないのに「MySQLはめんどうそうなので、MongoDBを使おう」などと提案されると軽蔑してしまうしそいつとは仕事したくない。
このままいくと将来こんなことを言ってしまうかもしれない
「プロダクションでnode.js使うの?いいけど何か問題が起きたとき対応できるの?nodeのソースコードすら追えないじゃ困るじゃん。C++も読めないのに偉そうなこと言うなよ」
そして老害になる