uu59のメモ | ウェブサービスAPIの認証（OAuthとかAPIキー）について考えた
最近社内ツール（ウェブサービス）のAPIの認証について考えてる。 ユーザーがブラウザからIDとパスワードを使ってログインする伝統的な感じのサービスだけど、Mechanizeとかを使ってブラウザ以外から操作する要望が高まってきているのでAPIを用意しようみたいになってる。そのAPIでの認証をどうするかという話。特定少数用の小規模なものを想像してもらうといい。 ざっと思いつく案は、 ID/パスワードを使ったBASIC認証 ID/パスワードを使ったBASIC認証以外の認証方式 OAuth SSH key pair ブラウザから設定画面でAPIキー/トークンの発行をするやつ くらい。SSL経由なので盗聴リスクやリプレイ攻撃や改竄については無視していいし、TwitterやFacebookみたいに不特定多数のサードパーティが居るわけでもない。1は便宜的にBASIC認証と書いたけどDigest認証でもあ
uu59のメモ | fluentd-uiを作った
https://github.com/fluent/fluentd-ui 開発者としてはあれが足りてない、こうなってると良さそう、などなど理想が次から次へと明確に見えてくるのでなかなか満足できないものですが、今のところ概ね好意的な評価を頂けているようでよかったです。 @kzk_mover, @repeatedly, @kiyototamuraの御三方には大変お世話になりました。社としてのあれは社としてあれされるだろうということでそれ以外のあれを書いときます。 制約について 珍しいものとして以下の2つがある。 RDBMSは禁止（別デーモンのpostgresqlとかは論外。sqliteもwindowsで少し怪しい） coffeescriptは禁止（ユーザーがnode.jsを持ってない可能性は充分ある） RDBMSがないことでバージョンアップとマイグレーションについて悩まなくて済んだ、などのいい
uu59のメモ | RailsとJS(vue.js)の連携
前書き Railsを使いつつJSもそこそこ書きたい、という条件であればまず前提としてjQuery脳を捨てましょう。jQueryスタイルで考えるかぎり何をどうやっても破綻するのでJSを諦めるか保守性を諦めるかして覚悟を決めましょう。 捨てるのは「jQuery」ではなく「jQuery脳」です。jQueryでグローバルな領域に進出してメソッドチェインで狼藉を働いたり、いま現在目の前にあるHTMLだけを考えてDOM操作をしたり、$.onと$.triggerを使ったクロージャ内部へのGOTOなどを記憶から消しましょう。 可能な限りスコープを小さく保つのはプログラミングの基本原則といえます。その原則を思い出し、JSを軽く扱わず、一般的なプログラミングと同様に閉じられた関心事にのみ注力するようにしましょう。 RailsとJSと役割分担 Railsもviewとしてテンプレートエンジンの処理を持っていますが
uu59のメモ | cramでvagrantのVMをテストする
cramという便利なものがあります。これは語弊のある言い方をするとRubyでいうcucumber/turnipのようなテストツールです。サンプルを見たほうが早いと思いますが、普通にMarkdownとかを書く感じでテストを書けて、コマンドの想定される出力と実際のものを比較してtrue/falseを判定するみたいなやつです。想定と実際の出力とのdiffがなければグリーン、期待と違えばレッドです。 Vagrantのテストというとserverspecが勢いありますが、cramはもっと生っぽいテストをかけます。serverspecではshould be_enabledのように、書くのは簡単だけど実際に何をテストしているのかはソースコードを見ないとわからないので、テストがこけた場合の原因調査がちょっと厄介です（例えばRedhat系ならchkconfigの結果を見ています）。とはいえcramでパッケージ
uu59のメモ | vimのsyntastic + jshintでwarningとerrorを無理やり区別する
jshintのerror出力はwarning出力と同じ処理です。よってvimのerrorformatを使ってエラーメッセージを解析し、そこからエラーの種類を判断しているsyntasticではwarningとerrorの区別ができず、すべてがエラーとして扱われます。 ⚔ 1 foo; ⚔ 2 bar( , , , ); 1行目はfooが未定義というwarning、2行目はシンタックスエラーというerrorです。どちらも直すべきものではありますが、jshintの性質上、特段問題でなくとも++や==をif(cond) return;などを使うと警告を出すことが設定によってはありえます。また設定項目は膨大であり、これを自分が望むように正しく設定するのはjshint初心者には不可能でしょう(参考: うちの発展途上のjshintrc)。その結果、syntasticをインストールしたあと試みに開いたjs
uu59のメモ | Rails4でデフォルトで入るturbolinksがオープンリダイレクタと合わさると何でもできてかなり危険
Rails 4.0で入るturbolinksですが、これが有効だと無効の環境と比べてセキュリティリスクが微増するという話です。具体的にはRailsサービス内（同一ホスト内）にオープンリダイレクタがあり、CGMサイトであるとかユーザーが任意のリンクを張れる場合に、悪意あるスクリプトがそのサービスのホスト下で実行されてしまう。というのをmalaさんに指摘されました。 Railsであれば基本的にredirect_to :action => "show", :id => @model.idみたいな感じで書いてリダイレクトしてるだろうけど、redirect_to params[:hoge]みたいに書いてる場合は?hoge=http://evil.example.comとかでevilなページに飛ぶし、turbolinksと関係なくよろしくないので暇を見て直しましょう。 話を戻してturbolinksだ
uu59のメモ | Angular JSをSinatraと使ってJasmineでテストするまで
Backbone.jsは触ったことがあったので、次は違うのに手を出してみようと思ってたらタイミングよくAngular JS 1.0リリースのニュースを見つけたのでちょいちょい触っていました。 主観的かつ大雑把な感想をいうと、Backbone.jsはプレーンなHTMLに対してイベントやコントローラをがしがしくっつけてずっとJavaScriptワールドで作業するのに対し、Angular JSはHTMLに独自属性を付与してDOMをそれぞれ独立したコンポーネントとみなしていろいろする感じです。 サンプルで必ず出てくる<div ng-app="hoge"></div>のng-appについてですが、ngというのがAngularのnamespaceでappが具体的なモジュール（ディレクティブ）です。以下のようにして自由に定義できます。 angular.module('hoge.directives').
uu59のメモ | jQuery.Deferred その1 JSDeferredとの基本的な違い
JSDeferred $.Deferred 長年JSDeferredを愛用してましたが、jQueryにDeferredがついたらしいので記憶を整理して慣れていきます。 おさらい 基本チェイン // JSDeferred Deferred.next(function(){ alert("a"); }).next(function(a){ alert('b'); }).next(function(b){ alert('c'); }); // $.Deferred $.Deferred().done(function(){ alert("a"); }).done(function(a){ alert('b'); }).done(function(b){ alert('c'); }).resolve(); 値のリレー // JSDeferred Deferred.next(function(){
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.uu59.org/2013-06-01-zsh-optimize.html