君は心理学者なのか?

大学時代に心理学を専攻しなぜかプログラマになった、サイコ(心理学)プログラマかろてんの雑記。

Angular2/4で使えるdatatable「ngx-datatable」を使ってみた

Angular2/4にてテーブルのソートを簡単に行ったりpagerを簡単に作ったりしたい

pagerだけ作るのであれば以下のmoduleでも良い。

github.com

テーブルのソートなども行いたかったので、ngx-datatableを利用することにした。

github.com

star数も1800超えで、かなり活発に開発されているみたい。

特徴

仮想DOMを使っているので、かなり大きなデータ数を扱える

http://swimlane.github.io/ngx-datatable/#virtual-scroll

10,000件でもスイスイ動く。

jQueryのDatatableを使っていたときは1,000件超えたあたりから

モッサリ動いていた気がする。ngx-datatableすごい。

ページネーションとソートは、クライアント/サーバ両方に対応

今回はデータ件数が多いので、

ページングする毎にAjax通信をしてデータを受け取ろうと思っていたのでこれはありがたかった。

デモページを見るとかなりいろいろなことができそう。

ngx-datatable - Angular2 and beyond component for presenting large and complex data

ngx-datatableを使おうとしたらコンパイル時に「In ambient enum declarations member initializer must be constant expression」が発生

問題

Angular4で作っているアプリケーションにてdatatableを使おうとしたところ、

コンパイル時に以下のエラーが発生

In ambient enum declarations member initializer must be constant expression

解決方法

typescriptのバージョンを上げればよいらしい。

ERROR in E:/works/ferrari-update/ferrari/Grand/node_modules/@swimlane/ngx-datatable/release/types/column-mode.type.d.ts (2,16): In ambient enum declarations member initializer must be constant expression. · Issue #927 · swimlane/ngx-datatable · GitHub

プロジェクトディレクトリにて、

npm install typescript@latest --save-dev

を実行して、再コンパイルするとなおった。

ただangular-cliとtypescriptの相性等があるので、typescriptのバージョンアップには注意。

使っているnode moduleのバージョンを確認したい

バージョンを確認する

現在使っているnode moduleのバージョンを確認する必要がありました。

アプリケーションディレクトリにて、

npm ls

直下のmoduleのみ確認したいときは、

npm ls --depth=0

npm installでinstallされるパッケージのバージョンを固定する(その1)

確認した後は、他の環境でも同じバージョンがインストールされるよう、

package.jsonにバージョンを記載しておいたほうが良いと思われます。

^ や ~ を用いたバージョンだとバージョンに幅が出てしまうので。。

npm installでinstallされるパッケージのバージョンを固定する(その2)

バージョンを固定する方法はもう一つあります。

npm shrinkwrap

を実行すると

npm-shrinkwrap.json

というファイルが生成されます。

新しい環境で

npm install

した際はこちらのjsonファイルに記載されたバージョンに従って、

node moduleのinstallが行われます。

docs.npmjs.com

Angular Materialを導入しようとしたら"has no exported member 'MdCheckboxModule'"と怒られた話

Googleが提唱している「MaterialDesign」を、Angular2/4上で簡単に使うことができる

「Anglar Material」を導入しようとしたら、moduleの読み込みに失敗しました。

 has no exported member 'MdButtonModule'.

CHANGELOG.mdを見てみると

どうやら2017-10-05の変更で、

md-と記載していた部分をmat-と記載するようになったようです。

/** 今まで */
import {
  MdButtonModule
} 
from '@angular/material';

/** これから */
import {
  MatButtonModule
} 
from '@angular/material';
<!-- 今まで -->
<md-checkbox>Click me!</md-checkbox>

<!-- 2.0.0-beta.12以降 -->
<mat-checkbox>Click me!</mat-checkbox>

github.com

ただこの変更によって、幾つかバグが生じているようです(2017-10-17 現在)。

僕もチェックボックスのデザインが崩れる現象に遭遇しました。

安定するまでは前のバージョン使ったほうが良さげ。

ピザ◯ラから100枚のピザが届くまで 〜 CSRF対策とは(その2)

CSRF対策とは

  • その1「CSRF攻撃」について

  • その2「CSRF対策」について

  • その3「RailsにおけるCSRF対策」について

の「その2」です。

おさらい

CSRFとは

  • 悪い人が使うwebサイト攻撃方法
  • これをされるとすごく困る
  • 具体的には「ピザ◯ラから100枚のピザが届いたり」する

前回は、どうやって「ピザ◯ラから100枚のピザが届く」のかシミュレーションをしました。

問題点

f:id:karoten512:20171015194503g:plain

リクエストが正しいページから送られてきているのか

をサーバが判別することが出来ていないのが問題です。

今回はそれを解決します。

解決方法(抽象)

「今来たリクエスト、

 さっき俺(サーバ)が発行したページから来た正しいリクエストなのか?

 それともぜんぜん関係ないページから来たヤバいリクエストなのか?」

というサーバさんの悩みを解決すればよいということになります。

解決方法(具体)

サーバからページを発行する際に、「指紋(token)」をつけておき、

次回のリクエスト時にtokenを持っているか確認します。

以下、具体的にどうやっているのか説明していきます。

正常な場合

f:id:karoten512:20171015204114g:plain

ブラウザからページをリクエストされたサーバは、

token(特定の法則に従って作られた文字列)を作成しそれを保持します。

またそれをhtmlに含めて返します。

htmlのform要素(hidden)に含ませることが多いです。

f:id:karoten512:20171015202047g:plain

さて、購入ボタンが押されると、

data、cookieそして

hidden要素に含まれるtokenがサーバに送信されます。

サーバは送られてきたtokenとサーバ上に保持しておいたtokenを照合して、

「正しいページ」から情報が送られてきたことを確認します。

その後、ユーザ特定を行い、購入処理を行います。

CSRF攻撃された場合

f:id:karoten512:20171015202950g:plain

第3者が発行したページにはtokenが含まれないか、

間違ったtokenが含まれているので、以上のように購入処理が弾かれます。

まとめ

セキュリティを高めるには、

  • 正しい人からのリクエストであること(cookie

に加えて、

  • 正しいページからのリクエストであること(CSRF対策)

が重要ということがよくわかりました。

補足

ワンタイムトーク

なお、攻撃者がtokenを手に入れてしまうと悪いことをされてしまうので、

基本的にtokenは1回のリクエスト毎に新しくなります。

(ワンタイムトークンといいます)

tokenを保持する場所

今回hidden要素に含ませる方法を紹介しましたが、

http headerに含ませる方法もあります。

token照合の方法

今回簡単のために、

クライアント側で保持するtokenとサーバ側で保持するtokenを同一のものとして扱いました。

実際は文字列自体が異なっていることが多いらしいです。

クライアントから受け取ったtokenを、サーバ側でゴニョゴニョして照合するそう。

これについてはその3で触れられたらなあと思っております。

【性格診断テスト】16 personalities - INFP 和訳その2

f:id:karoten512:20171012181120p:plain

(画像は “仲介者”型の性格 (INFP-A / INFP-T) | 16Personalitiesより)

16 personalities 診断

私はINFPタイプでした。

INFP

より多くの情報を知りたいと思い、こちらの本の一部を和訳してみました。

https://www.amazon.co.jp/gp/product/B01ES8UZ4A/ref=kinw_myk_ro_titlewww.amazon.co.jp

ハイライト

  • 友人を作るときは慎重

  • 一人でいることを楽しめるタイプだがたまには人と話したい

  • 読書が好き

  • 空想が好き

INFPの人間関係

INFPは簡単に友人を作ろうとしない。

友人はかなり慎重に選ぶ。

そうそう、だから友達が少ないのよねぇ(?)

INFPと孤独

INFPは一人でいる時間をとても楽しむことができる。

しかし、一人でいる時間が多すぎると飽き始める。

自分の好きなものに囲まれている限り、2〜3日一人でいることは苦にならない。

その後に、自分と親密な人と話したくなることがある。

とてもわかる。

休日に人と会うと消耗してしまうので、休日は極力人に合わないようにしている。

今日もいつもいくカフェでコーヒーを飲みながらパソコン開いてる。

INFPの人は一人が好きだが、

自分と親密な関係にある人といるのも好きである。

自分の愛する人と静寂を共有し、

平和で静かな場所にいるのがINFPにとって一番安らぐ。

はやくこうなりたい(棒読み)

INFPと読書

彼らの人生の大部分を占めるほど、読書を好む。

フィクションを好むことが多いが、面白いと思ったものはいろんな分野の本でも読む。

特に生物学や心理学などを好む。

大学の頃は生物学(人間限定)と心理学を勉強してたんだよなぁ。

INFPの好きなこと

自分の心を刺激するものや、心をより豊かにするものを好む

想像力を掻き立てるものや新しい分野に飛ぶこむチャンスを楽しむ

空想を楽しむ

余談

空想で思い出した。

中学生〜高校生の頃は絵を書いたりゲームを作ったり小説を書いていたりした。全部黒歴史

最悪なことにこの間データを発見してしまった。

よく「タイムマシンがあったらなあ」とか言う人いるけど、

実はそんなもんはそこらじゅうにあります。

昔のUSBは全部タイムマシンです。意外と身近にあるもんだね。

ファイルを開いてタイムスリップして悶絶するまでがセットなのですが、

昔の自分は案外賢かったらしく、「黒歴史の核心」データだけ削除されてたりします。

闇が深い。

中途半端に覚えているもんだから、「黒歴史の核心」データがないことにもやもやします。

10年先輩になった私をじわじわ苦しめてくれる。

やるじゃん。中学時代の自分。

ピザ◯ラから100枚のピザが届くまで 〜 CSRF対策とは(その1)

CSRF対策とは

自分の中で曖昧になっている部分があったので、整理してみました。

これから3回に分けて解説しようと思います。

  • その1「CSRF攻撃」について

  • その2「CSRF対策」について

  • その3「RailsにおけるCSRF対策」について

CSRF攻撃とは

CSRF攻撃は正確に言うと、

「クロスなんちゃらかんたらフォーなんたら」と言います。

難しいので簡単に言うと、

  • 悪い人が使うwebサイト攻撃方法
  • これをされるとすごく困る
  • 具体的には「ピザ◯ラから100枚のピザが届いたり」する

そこで今回は、どうやったら「ピザ◯ラから100枚のピザが届いたり」するのかをシミュレーションしてみました。

正常な処理

ログイン前

f:id:karoten512:20171013192916j:plain

Aさんがブラウザを用いて、サーバとやり取りをしています。

ログイン前はCSRF攻撃は行われません。

ログイン後、購入ボタンを押すまで

f:id:karoten512:20171013193238j:plain

ログイン後、サーバから「正しいサイト」が帰ってきました。

f:id:karoten512:20171013193351j:plain

たくさんのピザから1枚を選んで購入ボタンをクリックします。

f:id:karoten512:20171013193435j:plain

サーバに向かって、「cookie」「data(正確にはリクエストbody)」が送られます。

dataには「ピザ1枚」という情報が入っています。

サーバ側でユーザ特定を行い、購入処理を行う

f:id:karoten512:20171013193628j:plain

cookieからユーザAであることを特定し、

サーバは購入処理を行います。

無事1枚のピザの注文が完了しました。

CSRFによる攻撃

ログイン後、Aさんが偽サイトにアクセスするよう第三者が誘導する

f:id:karoten512:20171013194046j:plain

Aさんがログイン後、

知らないアドレスからメールが送られてきました。

メールにあった怪しいリンクをクリックすると、

いつも使っているピザ◯ラのサイト(実際は違う。よく似せて作っている偽サイト)が出てきました。

f:id:karoten512:20171013194339j:plain

偽サイトにあった「お得!クリックしてね」ボタンをクリックします。

f:id:karoten512:20171013194517j:plain

偽サイトには、「ピザ100枚」という情報をdataとして送るように指定してありました。

恐ろしいですね。

でもきっとサーバなら「こいつは嘘サイトだな」と判別してくれるはずです。

サーバ側でユーザ特定を行い、購入処理を行う

f:id:karoten512:20171013194631j:plain

サーバはおもったよりもアホでした。

cookieデータは正しいので、cookieからユーザAであることを特定し、

サーバは購入処理を行ってしまいました。

Aさんの家には無事、ピザ100枚が届きましたとさ。

何が問題か

リクエストが正しいサイトから送られてきているのか

をサーバが判別することが出来ていないのが問題です。

逆にそれさえ解決してやれば、CSRF攻撃を防ぐことができそうです。

ではどうやって防ぐのか。

次回に続きます。。。