Tweet
Tweet

Slide 1

Slide 1 text

SPA開発時にぶちあたった壁　3選

Slide 2

Slide 2 text

３選    1.  状態が管理しきれない（flux）      2.  ローカルサーバとAPIサーバで通信できない 問題（セキュリティ）      3.  画面で共通の処理を入れたい問題（mixin）  

Slide 3

Slide 3 text

 1.  状態が管理しきれない

Slide 4

Slide 4 text

よくある画面

Slide 5

Slide 5 text

よくある画面

Slide 6

Slide 6 text

よくある画面 ① ② ③

Slide 7

Slide 7 text

よくある画面 •  同じデータを数カ所で参照している   •  １箇所変更すると数箇所に変更が跳ねる  

Slide 8

Slide 8 text

まだいい

Slide 9

Slide 9 text

もう死ぬ

Slide 10

Slide 10 text

よくある画面 •  データを参照するコンポーネントが増えた時、   依存関係の管理で死ぬ   （一度死んだ事がある）   •  双方向依存になったりして   管理しづらい  

Slide 11

Slide 11 text

そこでstoreパターン •  参照するデータを１箇所にまとめる   •  データが変更された時、   各コンポーネントに通知する

Slide 12

Slide 12 text

データは   ここにあつめる

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

各コンポーネントに 値が通知される

Slide 16

Slide 16 text

特徴 •  データが一つにまとまっているので   わかりやすい   •  処理の方向が１方通行でわかりやすい   （依存方向も１方通行）  

Slide 17

Slide 17 text

これをもっと推し進めたのがflux 今回はvuexというライブラリを使っています

Slide 18

Slide 18 text

考えてみると •  このパターンは目新しくはない  

Slide 19

Slide 19 text

考えてみると ・通信は一方通行     ・データは一箇所に      まとまっている  

Slide 20

Slide 20 text

戒め •  新しい技術がでてきたときに、   背景を考え、   汎用性の高い知識を抽出していきたい  

Slide 21

Slide 21 text

ローカルサーバと開発サーバが   通信できない

Slide 22

Slide 22 text

こんなエラーをよく見る

Slide 23

Slide 23 text

原因 •  「Same-­‐Origin  Policy」に違反しているため

Slide 24

Slide 24 text

Same-­‐Origin  Policyとは •  あるオリジンから取得したリソースからは、   同じオリジンのリソースだけアクセスできる   という制限

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Originとは •  リソースの配信元   •  出身地的なもの  

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

OK OK OK

Slide 29

Slide 29 text

実は •  Same-­‐Origin  Policyに制限される場合と、   されない場合がある  

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

OK NG

Slide 32

Slide 32 text

Same-­‐Origin  Policyに制限されない •  script   •  img,  video,  audio   •  object,  embed,  applet   •  frame,  iframe   •  link,  CSS  

Slide 33

Slide 33 text

Same-­‐Origin  Policyに制限される •  XMLHOpRequest（Ajax）   •  Canvas   •  Web  Strage   •  X-­‐Frame-­‐OpTons  

Slide 34

Slide 34 text

どうして制限される必要があるのか •  ユーザの機密データが超ぬすまれやすくなる   •  もしxhrが制限されなかったら…  

Slide 35

Slide 35 text

機密情報GET

Slide 36

Slide 36 text

例えばこんなことが •  ログイン中サービスの個人情報を転送   •  ユーザが入力したデータをdomから取得して 自分のサーバに転送   •  わりとやりたい放題  

Slide 37

Slide 37 text

つまり、Same-­‐Origin  Policyは   •  攻撃手法を減らすためにブラウザが標準で 設けている制限

Slide 38

Slide 38 text

ただし、 •  xhrでCross-­‐Originのリソースを取得したい時 はよくある   •  例   APIサーバとのオリジンをまたいだ通信

Slide 39

Slide 39 text

対応方法 •  その１   – CORSを使う     •  その２   – プロキシを使う

Slide 40

Slide 40 text

その１ •  CORSを使う   – Cross-­‐Origin  Resource  Sharing（そのまんま）   – レスポンスにヘッダを追加して送り返す   – そのヘッダに指定してあるoriginとは   リソース共有を許可する

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

その１ •  ヘッダ追加方法    

Slide 43

Slide 43 text

その２ •  プロキシを使う   – 間にSame-­‐Originのサーバを１つ挟む   – サーバにはSame-­‐Origin  Policyが適用されないこ とを利用する

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

今回の対策 •  プロキシサーバを使用することにしました   – APIサーバの設定を書き換えるのはセキュリティ に的に怖い   – Webpack-­‐dev-­‐serverにproxy機能があったため   実現できそう

Slide 46

Slide 46 text

今回の対策 •  config/index.jsの設定

Slide 47

Slide 47 text

まとめ •  ブラウザにはセキュリティ上、Same-­‐Origin   Policyという制約がかかっている     •  それを回避する方法がいくつかある   •  今回はプロキシを使用した  

Slide 48

Slide 48 text

画面で共通の処理を入れたい問題

Slide 49

Slide 49 text

画面に共通処理を入れたい •  その画面で必ず呼び出さなければ   ならない処理がある   •  アカウント取得/メニュー取得   – 常に最新の情報を取得するため  

Slide 50

Slide 50 text

画面に共通処理を入れたい •  ただし、すべての画面で必要なわけではない   – 例えばログイン画面や、   ログイン必要ない画面では必要のない処理  

Slide 51

Slide 51 text

画面に共通処理を入れたい •  よく使われる処理で、でもすべての画面で使う必 要のない処理   •  一般的なmoduleに似ている   –  継承の場合、   継承しているクラス全てで処理を呼び出せてしまうが、   moduleならincludeしているクラスだけ処理を使える  

Slide 52

Slide 52 text

画面に共通処理を入れたい •  Vueではmixinを使う  

Slide 53

Slide 53 text

画面に共通処理を入れたい

Slide 54

Slide 54 text

戒め •  フレームワーク自体は新しくても、   概念自体は使い古されているものが多い   （使い古されているからこそ安定している）   •  そこに気づきたい（願望）  

Slide 55

Slide 55 text

今後も開発がんばります