SVGをReact.js/JSXで使う
この記事はSVG Advent Calendar 2016の19日目です。
去年に引き続きグラフを描いての参加です。
React × SVG
React.jsなプロジェクトでSVGを描画したときのメモです。
React.jsでは、JSXという記法でJavaScriptコード内にHTMLタグを記述していきますが、SVGタグも記述できます。
React.jsの特徴は仮想DOMですが、SVGもSVG DOMというインターフェースを持っているので、HTML同様にサポートされているのですね。
Attributeはキャメルケースを基本に
まずタグ内の属性名については、基本的にハイフンがキャメルケースになります。ネームスペースを表すコロンも同様です。
通常のSVG
<svg version="1.1" width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <rect width="100" height="100" x="10" y="10" fill="#900" stroke="#666" stroke-width="5" /> <a xlink:href="http://blog.hatena.ne.jp/yuw27b/"> <text x="20" y="40" fill="#FFF" text-anchor="start" font-size="20">Text</text> </a> </svg>
JSX内のSVG
<svg version="1.1" width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <rect width="100" height="100" x="10" y="10" fill="#900" stroke="#666" strokeWidth="5" /> <a xlinkHref="http://blog.hatena.ne.jp/yuw27b/"> <text x="20" y="40" fill="#FFF" textAnchor="start" fontSize="20">Text</text> </a> </svg>
JSXはあくまでもJavaScriptの中なので、ハイフンやコロンが使えないからだと思われます。
サポートされている属性名のリストは以下の公式ページの最下部にあります。
https://facebook.github.io/react/docs/dom-elements.html
上記のリストには含まれていないのですが（HTMLと同じだから？）、「class」も「className」になります。
ブラウザにReactのDeveloper Toolsを入れておけば、使用できない属性名についてはコンソールに警告が出るので、まずはそのままSVGを書いてしまって、エラーが出たら都度修正、でもいいと思います。
または、自動的に変換してくれるnpmパッケージと、それを元にしたオンラインサービスもあります。
svg-to-jsx
SVG to JSX Online Converter
ただし、若干バグがあるような感じなので、全部お任せはちょっと難しいかもしれません。
RESTful APIで長い検索クエリを扱う
Webアプリケーション用のRESTfulっぽいAPI*1を作っていて、複雑な検索クエリを受け取る必要が出てきたときのメモです。
悩み
RESTfulの原則に従うと、検索クエリを投げて結果の一覧を取得する、というリクエストは、
「リソースの取得」なので、GETを使うべきです。
/api/entries/?q=xxx とか
/api/entries/?created=20161129&status=active
みたいなURIになりますよね。
こんな感じで検索キーワードが1つ2つなら良かったのですが、
今回作っていたのが限定されたユーザー向けのアプリで、多少検索に時間がかかってもいいから複雑なクエリを投げたい、というのが要件でした。
こんなふうに検索条件を組み合わせられるようになっていました。
問題は、
①検索条件がいくつ来るか分からない
②「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でも良さそうですが。
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/
ブラウザ対応状況
主な機能
- 「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
- モダンブラウザはほぼ実装済み。
- Edgeは開発中というステータスになっている。
- HTMLのメタタグでもポリシーの指定ができるように
- IETFで策定されていたX-Frame-Optionsが取り込まれた
- nonceまたはhashを使ったホワイトリストが利用できるように（これについては後述）
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.comのJavaScriptファイルを読み込むときには、
<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も。
結局パスワードってどうしたらいいの？ (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は最新に。MacのJava危険。
一般人の場合は、添付ファイルを開く前にウイルスチェックすればほぼ大丈夫。
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-quotes | single | シングルクオートを使う |
| color-hex-case | upper | 16進数の色コードは大文字 |
| color-hex-length | short | 色コードを省略できるときは省略する |
| color-no-invalid-hex | true | 色コードがおかしい場合に警告 |
| number-leading-zero | never | 数字の前にゼロをつけない |
| number-no-trailing-zeros | true | 数字の後ろに（不要な）ゼロはつけない（「10.0px」はダメ） |
length-zero-no-unit | true | 「0」の場合は単位なし（「margin: 0px;」はダメ） |
| value-list-comma-newline-after | never-multi-line | カンマの後で改行しない |
| value-list-comma-space-after | always | カンマの後は必ずスペースを入れる（「Arial, Helvetica」） |
| declaration-colon-space-after | always | コロンの後に必ずスペースを入れる（「margin:0;」はダメ） |
| declaration-no-important | true | 「!important」は使わない |
| declaration-block-single-line-max-declarations | 0 | 1行で全部書かない（「a {color: #000; }」はダメ） |
| block-no-empty | true | 空のブロックを許可しない |
| block-opening-brace-newline-after | always | 「{」のあとは必ず改行 |
| block-closing-brace-newline-before | always | 「}」の前に必ず改行 |
| block-opening-brace-space-before | always | 「{」の前に必ずスペース |
| selector-combinator-space-after | always | 「div +p」はダメ（「+」や「>」のあとに必ずスペース） |
| selector-combinator-space-before | always | 「div+ p」もダメ（「+」や「>」の前にも必ずスペース） |
| selector-list-comma-space-after | always | 「div, p」のとき、カンマの後に必ずスペース |
| declaration-block-no-duplicate-properties | true | プロパティの重複を警告（「display」が2個あるとか） |
| declaration-block-trailing-semicolon | always | ルールの後に必ずセミコロン |
| indentation | tab | インデントはタブ |
※設定ファイル（.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が見つからなければ、さらに上の階層にさかのぼって探しに行きます。
エディタのプラグインを利用してリアルタイムにチェック
このような実行方法でもいいのですが、エディタのプラグインを使えば、書いている最中にどんどん警告してくれるので便利です。
公式サイトにプラグインの一覧がありますが、現在Atom、Sublime Text、Visual Studio用のプラグインがあるようです。
GitHubのリポジトリを見ると、現在（2016年2月）も開発がどんどん進んでいるようです。新しいルールが追加されたりもしているようなので、何かあればまた追記したいと思います。
