yuw27b’s blog

技術メモと雑記

RESTful APIで長い検索クエリを扱う

Webアプリケーション用のRESTfulっぽいAPI*を作っていて、複雑な検索クエリを受け取る必要が出てきたときのメモです。

悩み

RESTfulの原則に従うと、検索クエリを投げて結果の一覧を取得する、というリクエストは、
「リソースの取得」なので、GETを使うべきです。
/api/entries/?q=xxx とか
/api/entries/?created=20161129&status=active
みたいなURIになりますよね。

こんな感じで検索キーワードが1つ2つなら良かったのですが、
今回作っていたのが限定されたユーザー向けのアプリで、多少検索に時間がかかってもいいから複雑なクエリを投げたい、というのが要件でした。
こんなふうに検索条件を組み合わせられるようになっていました。
f:id:yuw27b:20161202233544p:plain

問題は、
①検索条件がいくつ来るか分からない
②「q=xxx」の形式では「equals」「not equals」のところが渡せない
という点です。

まず①で、GETのクエリパラメータが長くなる==URIが長くなるので、ブラウザ〜ファイアウォール〜サーバまでのどこかで制限される可能性がありそうです。
さすがにそこまで長くは・・・とは思うものの、理論上は無制限に検索ワードを指定できるので、「たぶん大丈夫」ではやっぱりダメですよね。

②も、そのままJSONを文字列にエンコードするとか、「?key__equals__value&…」とか考えるものの、やはりクエリが長くなってきます。
そもそもフロント側でクエリを文字列に変換し、それをサーバ側でまたパースする、というのがあまりイケてないような気もします。

POST使っちゃダメ?

GETが厳しいとなるとPOSTで、と思うものの、
RESTful APIでは、POSTはリソースの新規作成なので、検索クエリを投げて良いのだろうか、と悩むし、
そもそも「/api/entries/」に対するPOSTリクエストは、当然"entry"の新規作成用に使ってしまっています。

解決策:検索用エンドポイントを用意してPOSTする

「/api/entries/search」というURIにPOSTでJSONを投げることにしました。
参考にしたのはこれ↓です。
rest - Design RESTful query API with a long list of query parameters - Stack Overflow

レスポンスのステータスは迷いましたが「201 Created」を返しています。
上のリンク先にもあるように「検索結果というリソースを生成している」と捉えています。まあ200でも良さそうですが。

新たな悩み

検索条件が設定されているかどうかをフロント側で判別して、あれば「POST /api/entries/search」、なければ「GET /api/entries」にリクエストをかけているのですけど、
もう全部POSTに統一のほうがいいのだろうか・・・?


ひとまず、そこまでREST原理主義でなくてもいいかと思いこんな感じにしましたが、何かもっといい方法があれば知りたいです!




RESTfulっぽいAPI・・・最近、業務で作っているWebアプリケーション専用のAPIなので、API単体で一般に公開するような性質のものではないです。
フロントがReact、サーバ側がRuby(Sinatra)+MySQLで、XHRリクエストにJSONを返しています。

Content Security Policyの今後(2016年10月現在)

先月の勉強会での発表の内容と少し重なりますが、CSPの各レベルの仕様とブラウザ対応状況などのまとめです。

Content Security Policyとは

CSP (Content Security Policy) - Web セキュリティ | MDN

ざっくりですが、WebサイトからXSSの危険を取り除くための仕様です。
現在は、サーバ側でHTTPヘッダーにCSPを追加することで利用できます。

きちんと指定すればWebサイトの安全性が高まるということで、私もJavaScriptがいろいろしているサイトには導入してみているのですが、まだまだ仕様が変わっていきそうな雰囲気ですね・・・。


Content Security Policy Level1

W3Cの公式ページ

Content Security Policy 1.0
※最終バージョンの内容はここにある↓
https://www.w3.org/TR/2012/CR-CSP-20121115/

ブラウザ対応状況

Can I use... Support tables for HTML5, CSS3, etc

  • 長い間「勧告候補」だったが、Level2に引き継がれてこちらは今後の更新はないようです。
  • IE10以降とモダンブラウザが対応。※ただしIEは「X-Content-Security-Policy」
主な機能
  • 「default-src」「script-src」「style-src」等のディレクティブに、コンテンツの読み込みを許可するドメインを指定できる
  • inlineでの実行を許可するかどうかを指定できる
  • script-src(JavaScript)に関しては、evalの実行を許可するかどうかを指定できる
  • レポートの機能


Content Security Policy Level2

W3Cの公式ページ

Content Security Policy Level 2
2016年10月現在勧告候補

ブラウザ対応状況

Can I use... Support tables for HTML5, CSS3, etc


Content Security Policy Level3

W3Cの公式ページ

Content Security Policy Level 3

  • Working draftの段階なので、ブラウザ実装等はこれからと思われる。
  • fetchやService Workersなどの、新しい(?)仕様への対応
  • strict-dynamic他、いくつかのディレクティブの追加

いろいろと追加されているようですが、草案段階なのでまだ変わるかもしれないですね。


本当に安全なのか問題

Googleのエンジニアによる論文

発表のスライドでも触れましたが、CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy という論文が発表されています。
これによれば、現在のCSPではXSSの危険を完全に取り除けているケースはほとんどないそうです。
特にホワイトリスト経由の攻撃が可能である場合が多い、と指摘されているのですが、
そうなると外部ドメインからJavaScriptを読み込む場合は、CSP(Level 1)ではXSSを防げないことになります。

論文中ではそこで、CSP Level2および3で実装予定のnonceとstrict-dynamicが有効だ、と述べられています。
が、CSPの実装を待てず(?)に、XSS-Protectionヘッダという新しい仕様の提案も出ているようです。
こちらが詳しいです:
XSSを防ぐ新しいXSS-Protectionヘッダ - あすのかぜ

使う側としては、仕様の混在はできれば避けてほしいところですが、今後どうなるのでしょうか。


nonceによるホワイトリスト

※CSP Level 2における「nonce」についてです。XSS-Protectionのnonceはまた別の仕様です。

例えば、https://example.comから、JavaScriptファイルを読み込みたい、とします。
Level 1では以下のようにCSPを記述していました。

Content-Security-Policy: default-src 'self';
script-src 'self' https://example.com

Level 2では、上記に加えてnonceを利用した記述ができるようになります。

Content-Security-Policy: default-src 'self';
script-src 'self' 'nonce-Nc3n83cnSAd3wc3Sasdfn939hc3'

HTML側でexample.comJavaScriptファイルを読み込むときには、

<script src="https://example.com/lib.js" nonce="Nc3n83cnSAd3wc3Sasdfn939hc3"></script>

のようにすれば読み込むことができます。

どちらもホワイトリストの指定ですが、nonceを使用するほうが安全性が高い、と前述の論文でも述べられています。
また、JavaScriptだけでなく、例えばCSSを外部から読み込む場合も、同様にして使用できます。



hashによるホワイトリスト

こちらはなかなか豪快(?)な仕様です。
インラインスクリプトのコードを暗号化したものをあらかじめCSPに記述しておくと、そのコードは実行可能、というものです。
なので、CSPのほうには暗号を記述します:

Content-Security-Policy: script-src 'sha512-YWIzOWNiNzJjNDRlYzc4MTgwMDhmZ..............'

例として考え付くのは、Google Analyticsのコードを暗号化したものを指定しておき、
HTML側ではいつもの(?)var _gaq = 〜のようなAnalyticsのコードを貼り付ける、という場合でしょうか。

※CSPではデフォルトでinline-scriptを許可しておらず、また許可してしまうと安全性は下がるので、不許可が好ましいのですが、
そうするとGoogle Analyticsのコードをわざわざ個別のファイルにしてのように読み込む必要がありました。
このhashを使えば外部ファイルにする必要はなくなります。


strict-dynamicとは

JavaScriptを対象とした仕様です。
こちらはLevel 3からの仕様なので、今後変わるかもしれませんが、2016年10月現在の仕様書によれば以下のようなものです。
仕様書の例そのままですが、

Content-Security-Policy: script-src 'nonce-abcdefg' 'strict-dynamic'

のようにCSPを記述し、HTMLでは以下のようにJavaScriptを読み込むとします。(nonceが一致しているので読み込まれます!)

<script src="https://cdn.example.com/script.js" nonce="abcdefg" ></script>

さらに、
https://cdn.example.com/script.js」内に以下のようなコードがあるとします。

document.write('<scr' + 'ipt src="/sadness.js"></scr' + 'ipt>');

このとき、「'strict-dynamic'」があると、この「sadness.js」は読み込まれません。
(逆に考えると、CSP Level2までは読み込めてしまうということですよね・・・だから安全でない、と言われるのでしょうか。)

ただし、

var s = document.createElement('script');
s.src = 'https://othercdn.not-example.net/dependency.js';
document.head.appendChild('s');

のような記述の場合は読み込めるそうです。



おわりに

仕様書やら論文やら、それなりにまじめに読んだつもりですが、そこまで英語に自信があるわけでもなく、おかしな解釈をしている点があるかもしれません。
何かお気付きの点があればコメントいただければ幸いです。

NDS第49回勉強会に行ってきたよ

少々日が経ってしまいましたが、NDS(長岡IT開発者勉強会)第49回勉強会に行ってきました。
今回のテーマは「セキュリティ」ということでしたが、貴重なお話がたくさん聞けました。
めずらしく(?)メモを取りながら聞いていたので、感想など書き残しておこうと思います。
そしてそんなところに紛れて発表もしてきたので、スライドも貼っておきます。

情報セキュリティ研修応用編ダイジェスト (30min) hiro_ishibashiさん

サイバー攻撃の歴史から!意外と通史で見ることはなかったので、新鮮な視点。
標的型攻撃
FireEye
ITストーキング
gmailはexeが送れないらしい。exe.zipも検知されるらしい。
ファイル共有サービスを使う
従業員より役員の方が標的型メールを開封しやすい
標的型攻撃は、社内で1人でも開封したら意味がない。10人が1人になっても同じこと。
→訓練は開封させない訓練ではなく、開封後の対策を訓練すべき。
ルールと運用の不整合。セキュリティといえども経営レベルの問題。
TCP/IPは善意を前提とした仕様
CSIRTと消防署、インシデントカード
未来には119番みたいな番号ができたりする・・・?
メール・FAX禁止の金融機関。まあ金融機関は仕方ない気もする。

Webサイト改ざんの事例紹介について (15min) nomeshi さん

事例というので汎用的(?)事例かと思ったら、知人の例だった。具体的でありがたい!
FFFTPで接続すると知らないファイルが・・・というのは、実は大昔に身に覚えがある。大事には至らなかったけど。)
Web diary professionalの脆弱性とのこと。まあ、WordPressにもあったし・・・。
Webサイトの放置はなんであれ危険ですよね。
ルワンダgoogle。あるのかgoogle・・・。
偽のショッピングサイトに飛ばされるようなので、クレジットカードの番号を盗んだりするんだろうか。
google search consoleっぽいファイルもウイルスらしい。sitemap.xmlも。

Content Security PolicyとWebサービスのセキュリティ対策 (15min)

自分の発表です。
スライドはこちらに

結局パスワードってどうしたらいいの? (30min) occhie3さん

情報モラルの布教大事!素晴らしいお仕事だと思う。
今の学校ではそういう講習があるのか。
情報セキュリティワークショップ
パスワードリスト攻撃ってやっぱりなくならないのね。不正ログインもすごく多い。
うちのサービスも簡単なパスワードは撥ねるべきなのか・・・。うーん、無理そうw
同一ホストからの連続ログイン試行を拒否、これも実装すべきか。
sha-1はもうダメ。sha-2とsalt化でDBに入れるべき。ハッシュ化を1000回くらい繰り返すのも有効。

セキュリティ (30min) MasatoMatsuokaさん

INTERPOLにサイバー警察ができたとのこと。ニューロマンサー)の時代が来るのか(違)。
情報セキュリティ>サイバーセキュリティ(情報のほうは紙とかも入るからくくりが大きい)
アリアンツの格付け(?)によると、サイバーの脅威は経営リスクの第3位。
いまは変電設備もデジタルなので、攻撃できるとのこと→サイバーでフィジカルを壊すことができる。
銀行口座のお金を移された例もある。
ネットで繋がってないところも→例えば工場の内部に入る従業員や保守業者のパソコンから侵入する。
工場に(保守に)行く人がアクセスするようなページにマルウエアを仕込む。JARファイルとかドライバとか。
一般的なハッカーより、発電所なら発電所に詳しい人の方が早くハッキングできてしまう。
システムが動かなくなるとしてもパッチを当てろ!
2016年の予想:APTはメモリ等に移行(ファイルではない)、ランサム継続、モバイル、IoT
Android Pay, Apple Pay、株取引などが狙われる。iPhone7気をつけろ、とのこと。少額で広範囲から詐取する見込みとのこと。
・個人としては、とにかく踏み台にされないように。ウイルスソフト絶対。パスワードは複雑に。
とにかく自分のアカウントを守れば世界は平和に。他人に迷惑をかけない!
ご自身はMacカスペルスキーファイアウォールLittle Snitch)を使っていらっしゃるそう。

emailを安全に使うための心がけ (15min) civicさん

メール開くだけなら大丈夫そう。確かに。添付ファイルを開くのがダメなんですよね。
メールのFromはあてにならない。つまりオレオレ詐欺
メール内のリンクは使わない。
メールソフトやOSの警告は無視しない。基本だけど大事ですね。
メールの添付ファイルはOSはガードしていない。例えばzipだとセキュリティソフトも処理できないケースがある。
添付ファイルそのものが危険。
Adobe,microsoft,Javaは最新に。MacJava危険。
一般人の場合は、添付ファイルを開く前にウイルスチェックすればほぼ大丈夫。
IPAのバージョンチェッカー
zipやexcelのパスワードを別メールで送るのは全く意味がない。日本だけ。
.exeを暗号化して.zipにするとgmailでも送れるらしい。
MMSにもウイルス乗せられる。

C#関連で何か (15min) alightさん

MSのMVPの方。
Azure Active Directory B2Cについて
パスワードの変更対応サービス自作するの、確かに面倒だった。し、自前のユーザー管理システムはセキュリティに不安が残るのも事実。
なので、認証の外部サービスいいなあ。
(うちのサービスクラウドにできない、というか月額みたいな契約ができないから無理、というつらみ。。。)
Azureのコンソール画面けっこうかっこいい。
APIとして使えるの良さそう。
契約できそうなプロジェクトがあったらぜひ試してみたい。

SG受験のすすめ (LT 5min) ゑぬぽいさん

管理部門の人向けの試験、というの良さそう。「マネジメント」が入っているのはそういうことなのか。
全国的にリテラシーが上がるといいですね。
合格率すごい高い。のは最初の試験だったから?
今のところIT関連の資格とは無縁で来てしまっているので、何か勉強するのも良いかも、と思ったり。



以上、ちょっと自分用メモの側面が大きいですが、大変有意義な会でした。
ぜひまた長岡まで足を伸ばしたいと思います。
ありがとうございました!

stylelintを使い始めたので設定例など (2016年9月更新)

※2016年9月13日更新:stylelintのアップデートに伴い、ルールの記述方法が古くなっていたものがありましたので、訂正しました。

stylelintって?

名前のとおりCSSのlintツールです。
設定したルールから外れた書き方をすると警告してくれます。

CSSを書くにあたって、インデントにタブを使うのかスペースを使うのか、スペースなら何文字分にするのか、「{」の前にスペースを空けるかどうか、といった「書き方」を統一する目的で使います。バリデーション(CSSの標準仕様に準拠しているかどうかの判定)は行いません。

公式サイト:http://stylelint.io/
日本語情報だとこちらが分かりやすかったです:CSSのLintをstylelintにする - Qiita


stylelintの特徴

  • ルールのカスタマイズができる
  • ルールセットの使い分けも簡単

CSSのlintツール自体は他にもありますが、stylelintが気に入った理由は、ルールのカスタマイズが簡単、ルールセットを簡単に切り替えられる、という2点です。
私は、デザインカンプをもらってHTML+CSSをコーディングする、という作業を定期的にするのですが、クライアントさんによってCSSのコーディングルールに違いがあるため、「このクライアントさんは小数点の前にゼロを入れちゃダメだったな」とか「こっちのクライアントさんはmargin-topは禁止だったな」とか、毎回資料を確認して見直しをしていました。
stylelintであれば、クライアントごとにルールのプリセットを作成しておき、警告の出た部分を修正するだけです。設定できるルールもたくさんあるので、これまでのところ、チェックしたい項目はすべてカバーできています。


インストールする

stylelintはnode.jsとnpmを使用するので、node.jsをインストール(インストールおよびバージョン管理方法は様々あるので、検索してみてください)してから、ターミナルで

npm install stylelint

と打つとインストールされます・・・と、公式サイトにありますが、私の環境では、

npm install -g stylelint

としてグローバルにインストールしないと、パスが通りませんでした。

次に設定ファイルですが、「.stylelintrc」という名前のファイルを用意します。ルールについては、公式サイトまたは、冒頭にあげた日本語情報が分かりやすいと思います。
全ルールを網羅したサンプルもstylelintのGitHubリポジトリにあります。


.stylelintrcの例

私が基本セットとして使っているルール一覧です。
多少ゆるめのルールになっていたり、個人的な癖もありますが、それなりに一般的な「書き方」になっているかな、と思います。
(打ち消してあるプロパティは、stylelintのアップデートに伴って使用できなくなった古い表記方法です。)

string-quotessingleシングルクオートを使う
color-hex-caseupper16進数の色コードは大文字
color-hex-lengthshort色コードを省略できるときは省略する
color-no-invalid-hextrue色コードがおかしい場合に警告
number-leading-zeronever数字の前にゼロをつけない
number-no-trailing-zerostrue数字の後ろに(不要な)ゼロはつけない(「10.0px」はダメ)
number-zero-length-no-unit
length-zero-no-unit
true「0」の場合は単位なし(「margin: 0px;」はダメ)
value-list-comma-newline-afternever-multi-lineカンマの後で改行しない
value-list-comma-space-afteralwaysカンマの後は必ずスペースを入れる(「Arial, Helvetica」)
declaration-colon-space-afteralwaysコロンの後に必ずスペースを入れる(「margin:0;」はダメ)
declaration-no-importanttrue「!important」は使わない
declaration-block-no-single-linetrue1行で全部書かない(「a {color: #000; }」はダメ)
declaration-block-single-line-max-declarations01行で全部書かない(「a {color: #000; }」はダメ)
block-no-emptytrue空のブロックを許可しない
block-opening-brace-newline-afteralways「{」のあとは必ず改行
block-closing-brace-newline-beforealways「}」の前に必ず改行
block-opening-brace-space-beforealways「{」の前に必ずスペース
selector-combinator-space-afteralways「div +p」はダメ(「+」や「>」のあとに必ずスペース)
selector-combinator-space-beforealways「div+ p」もダメ(「+」や「>」の前にも必ずスペース)
selector-list-comma-space-afteralways「div, p」のとき、カンマの後に必ずスペース
rule-no-duplicate-propertiestrueプロパティの重複を警告(「display」が2個あるとか)
declaration-block-no-duplicate-propertiestrueプロパティの重複を警告(「display」が2個あるとか)
rule-trailing-semicolonalwaysルールの後に必ずセミコロン
declaration-block-trailing-semicolonalwaysルールの後に必ずセミコロン
indentationtabインデントはタブ

※設定ファイル(.stylelintrc)はこれ
設定ファイルを見てもらうと分かるのですが、上に挙げた項目のほかに、「property-whitelist」というルールにCSSの仕様上定義されている全プロパティを突っ込んでます。プロパティ名のスペルを間違えたときに警告してほしいからなのですが、もっとスマートな方法がありそうな気もしています・・・
それともやっぱりこればvalidatorの範疇かな。


使ってみる

ターミナルで、

stylelint xxx.css

とすると、ルールから外れた記述が見つかった場合に、

30:3     Expected single space after "," (selector-list-comma-space-after)
128:14 Expected "#f0bd25" to be "#F0BD25" (color-hex-case)
129:2   Unexpected duplicate property "background" (rule-no-duplicate-properties)

・・・というように出力されます。左端が行数/文字数なので、その部分を直していきます。

実行時に読み込まれるルールセットは、実行時のディレクトリにある.stylelintrcの内容が読み込まれます。.stylelintrcが見つからなければ、さらに上の階層にさかのぼって探しに行きます。


エディタのプラグインを利用してリアルタイムにチェック

このような実行方法でもいいのですが、エディタのプラグインを使えば、書いている最中にどんどん警告してくれるので便利です。
公式サイトにプラグインの一覧がありますが、現在AtomSublime Text、Visual Studio用のプラグインがあるようです。



GitHubのリポジトリを見ると、現在(2016年2月)も開発がどんどん進んでいるようです。新しいルールが追加されたりもしているようなので、何かあればまた追記したいと思います。

カレンダーUIを実装する依存なしのJavaScriptライブラリ

カレンダーUIを実装するJavaScriptライブラリの紹介です。
Webアプリ上の入力フォームに、日付を選択する項目を実装したときのこと。

input type="date" を使いたいのだけど・・・

HTMLのinputタグに、「type="date"」を指定すると、一部のブラウザではカレンダーUIを表示してくれますが、主要ブラウザすべてにサポートされるのはまだまだ先のようで、案件で使うのは難しそうでした(2016年1月現在)。
参考:Can I use... Support tables for HTML5, CSS3, etc
※この仕様自体が、WHATWGのLiving Standardsであり、HTML5の仕様として勧告されているわけではないので、ブラウザのサポートはなかなか進まないのかもしれません。

jQueryjQuery UIに依存したくない

カレンダー方式で日付を入力するUIとなると、まずjQuery UIのDatepickerが思い浮かびました。デザインも色々なパターンがあり、jQuery製ということで各種のブラウザ対応や安定性も保証できて良いのですが、最近はjQueryを使わないWebアプリの案件もあり、カレンダーのためだけにjQueryjQuery UIを読み込む、というのはあまり良い方法には思えませんでした。

「Kalendae」

それで、ピュアJavaScriptで動作するライブラリを探したところ、「Kalendae」というものに行き当たりました。
GitHubにコードとドキュメントがあります:GitHub - ChiperSoft/Kalendae: A javascript date picker that just works.

GitHubのスター数は1,700を超えており(2016年1月現在)、開発も止まっていないようなので、良さそう!ということで、使ってみることにしました。

特徴としては、

  • 依存ライブラリなし(※)
  • 単一の日付選択と、期間選択の両方が可能。他にもオプションはいろいろある。
  • click、changeなどのイベント取得や、リセットなど、必要になりそうなAPIはきちんと揃っている印象
  • 見た目はCSSでカスタマイズ可能
  • モダンブラウザとIE8に対応

※ドキュメントにも「依存はないよ」というようなニュアンスのことが書いてあるのですが、実際にはmoment.jsを使っています。ですがKalendaeにはstand alone版があり、こちらはkalendae.jsのコードにmoment.jsを含めて配布しているものなので、読み込むファイルはこれ1つで済みます。
(どちらもMITライセンスなので、ソースコードに丸ごと含めてしまっても問題ないわけですね。)
つまり、

  • 基本的には・・・stand alone版のkalendae.js
  • すでにmoment.jsを読み込んでいるよ、という場合は・・・moment.jsを含まないkalendae.js

を使えば良い、と思います。

ファイルサイズ

  • kalendae.js 34KB
  • kalendae.min.js 17KB
  • kalendae.standalone.js 132KB
  • kalendae.standalone.min.js 51KB

上記の他に、

  • kalendae.css 7KB
  • ボタン用のpng画像が1KB×2ファイル

(バージョン0.5.5で確認)

実装例

kalendae.cssとkalendae.standalone.min.jsを読み込んで、ボタン用の画像はCSSと同じ階層に置いておきます。
そこで以下のように書くと、

<input type="text" class="auto-kal">

こうなります
f:id:yuw27b:20160108230952p:plain

オプション指定例:

<input type="text" class="auto-kal" data-kal="format: 'YYYY/MM/DD', months: 2, mode: 'range', direction: 'future'">

f:id:yuw27b:20160108231824p:plain
(フォーマットを年/月/日、2ヶ月分表示、期間選択、未来の日付のみ選択可能)



jQueryなプロジェクトでカレンダーが必要なときは、しばらくはこのKalendarにお世話になろうと思います!