JSONとJSONP〜その2〜

 

JSONPマダマダツヅキマスヨ。

 

前回、XSS攻撃を避けるためにも、クライアント側でパースしよう書きましたが、まだまだ謎が多いので書きます。

 

参考:ここここ

 

Content-type

jsonの場合、

application/jsonです。text/javascriptではない!

 

jsonpの場合、

実体はcallback関数でJSONを包んだJavaScriptなので、MIMEタイプはJavaScriptと同じでapplication/javascript

text/javascript → application/javascript (2006年4月RFC4329)

text/htmlとかtext/javascriptとかにしてるとhtmlと解釈してしまい、悪意あるスクリプトが仕込まれている場合、実行されていまします。→XSSの攻撃を受ける

content-typeを正しく記述することは重要!!

しかし、IE6だと、application/jsonとしていてもhtmlとして解釈してしまうようです。

 

callback関数

jsonpの仕組みって、コールバック関数を使ってサーバから受け取るデータにscriptとしての役割を持たす。

callback関数と同じ名前の関数の引数にJSONが入ったスクリプトを返すようクロスドメインのサーバーにリクエストし、
動的にそのスクリプトを読み込んだ瞬間にcallback関数が引数にJSONをつっこんだ状態で呼び出される。

 

 

ジェイソン違い、JSONPとJSONについて

 

ajax(つまりはXMLHttpRequest)って便利ですよね。

異なるドメインにアクセスはできない=クロスドメイン制約

を除いては・・・・。

 

しかし、JSONPを使うと、なぜ異なるドメインのデータを取得できるのでしょうか?

そんな疑問からのJSONとJSONPの違いを調べました。

参考:ここ

 

JSON        =    JavaScript  Object Notation

JSONP     =    JSON with Padding (Padding=不要なもん)

→つまりJSONPはJSONではない!!!

 

JSONPの仕組み

<script src=”https://google.com/test.js”></script>

//変数data に “グーグルからのメッセージ”;が挿入されるとする。

<script>

alert(data);  //「グーグルからのメッセージ」がアラートされる。

</script>

 

 

スタイルシートやjQueryライブラリーを呼ぶのもクロスドメインじゃん!そうじゃん!と気付いた次第です。

クロスドメイン制約って簡単に回避できるやーんって、楽勝って感じですよね!

 

しかし

 

これって、データ取得先(上記例で言うとgoogle.com)に

自サイトでの実行権を与えっちゃってるんです!

もしも、dataと言う変数に無限アラートが仕込まれてたらどうしょうか?自分は何も実装していないのに、観覧者に不快な思いをさせてしまう可能性があるのです。

 

こういったXXS攻撃を避けるために、

1.JSON.parse()をしましょう!

JSON.parse()

※JSON,JSONPはオブジェクトのためJSON.stringfy()で文字列にしたのち、JSON.parseしましょうね!

 

2.JSONP使うのやめましょう!

じゃあ何使えばいいんや!教えてください。

 

viewportについて

 

viewport

ってスマホ対応の時使うレスポンシブル対応のやつだな、

っということしかわからなかっための勉強します!

 

 

参考:http://ichimaruni-design.com/2015/01/viewport/

 

 

結論

・スマホサイトがある場合

<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0">

 

width=device-width : 幅をデバイスごとにサイズを切り替えてくれる!

 

initial-scale:初期のズーム倍率

 

※device-width  ⇄ 初期のズーム倍率が 1 になる。(initial-scale=1.0)

 

minimum-scale=1.0とすることで最小倍率を指定しているが、初期ズーム倍率と等しいため、縮小できない状態。

なぜ、縮小できなくするのか謎・・・。

Yahoo!の天気サイトもしてた・・。これ↓

<meta name=”viewport” content=”width=device-width,initial-scale=1.0,maximum-scale=1.0,minimum-scale=1.0,user-scalable=no”>

user-scalable=noってしてるのに、拡大できるやん?なんで?

 

と、思ったらいろんなサイト比較してるとこ発見!

 

 

しかし、よくわからない。

maximum-scale=1.0,minimum-scale=1.0,user-scalable=no

ってどうなれば正しい挙動なの?

 

・PCサイトしかなく、SPで最適化したい場合

<meta name="viewport" content="width=960(コンテンツの大きさ)">

これすれば、横の余白がなくなる。

 

シーケンスの初期化

 

シーケンスって便利ですよね。

SQLでもできるし、phppgadminを使えばGUIでも操作できる!

 

しかし、シーケンス設定っていまいちよくわからないのでまとめます。

 

  • phppgadminでのシーケンスの作成

phppgadminでシーケンスを作成しようとするとこんな画面がでます。

名前:シーケンスの名前をつけます。

よく見るのは「 テーブル名_カラム名_seq」ですね。

増加数:直前の数値からいくつ増加するか。

最小値:デフォルトは1。

最大値:MAX値

開始値:デフォルトは最小値と同じ。

キャッシュ値:メモリに格納しておくシーケンス番号の量を指定します。

これによりアクセスを高速にすることができます。

最小値は1(デフォルト)

Can cycle?:番号が最大値を超えた場合に最小値に戻るかどうか。

「いいえ」(デフォルト)が指定された場合、シーケンスの限界値に達した後の

       nextval呼び出しは全てエラーになる。

ログカウント:わからん!誰か教えてください。

Will increment last value before returning next value (is_called)?:

訳)次の値を返す前に最終値を増加しますか?

 

 

例えば、

増加数:1

最小値:1

開始値:1

Will increment last value before returning next value (is_called)?:いいえ

このシーケンスは1から始まり、2,3,4,….と1ずつ増加します。

 

 

 

  • phppgadminでのシーケンスの初期化

1.「リセット」をクリック。//最終値が1となる

2.「Restart」をクリック。//Will increment last value before returning next value (is_called)?が「いいえ」となる

 

 

  • SQLでのシーケンスの初期化

SELECT setval (‘シーケンス名’,  1,  false);

第2引数:最終値

第3引数:値を返す前に増加させるか<</Will increment last value before returning next value (is_called)?>>  true(増加する)/false(増加させない)

よく使うGitコマンド

 

Git DIFF

ブランチ間の差分を表示

$ git diff master[取り込むほう] develop[取り込まれるほう]

 

ブランチ間の差分があるファイル一覧を表示

$ git diff master[取り込むほう] develop[取り込まれるほう] --name-status

 

ブランチ間の差分があるファイル数を表示

$ git diff master[取り込むほう] develop[取り込まれるほう] --name-status | wc -l

 

 

HTML5ではaタグ内にdivといったブロック要素と呼ばれていたものをネストできるようになった

 

タイトル通りです!

ネストのルールって難しいです。

 

 

ulにネストしていいのはliだけなのに、liの中はなんでもネストしていいとか・・・。

HTML5以前では、ブロック要素やインライン要素を使ってのルールがありました。

が、

HTML5からブロック要素インライン要素といった分類がなくなりました。

 

そのかわり(?)としてコンテンツモデル

という概念ができました。

 

コンテンツモデル:各要素が内包できるコンテンツ

 

HTML要素は、0個以上の以下カテゴリーに属しています。

  • フローコンテンツ
  • メタデータコンテンツ
  • セクショニングコンテンツ
  • ヘッディングコンテンツ
  • フレージングコンテンツ
  • エンベッディッドコンテンツ
  • インタラクティブコンテンツ

 

これにより

今まで「インライン要素」と呼んでいた要素が

フレージングコンテンツとなったようです。

 

 

本題に戻ると・・・

a(アンカー)要素の仕様を見ると、

コンテンツモデル…..transparent(透過)

↑親要素のコンテンツモデルがそのまま継承されるという意味

 

 

 

例えば、

<p>

  <a href=”#”>リンク</a>

</p>

・a要素の親はp要素である。

・p要素のコンテンツモデルはフレージングコンテンツである。

→a要素にネストできる要素は

<span>,<a>,<img>といった、フレージングコンテンツとなる。

 

 

また、

<div>

  <a href=”#”>リンク</a>

</div>

・a要素の親はdiv要素である。

・div要素のコンテンツモデルはフローコンテンツである。

→a要素にネストできる要素は

メタデータコンテンツの一部を除いたほぼすべての要素となる。

 

 

git stashってadd(インデックス)してないと意味ないんだ!

 

タイトルの通りです。

 

Gitが苦手なもので、とりあえず、stashしちゃうんです。

んで、必要な時にstash popしてます。便利ですよね〜\(^^)/

 

超便利と感じつつ、stashをどんどん貯めていくのですが、

結局、使わず、溜まってくばかりなのですが。

 

そんな GIT stash に関して
私は大きな勘違いをしていることに昨日気がつかされました!

 

git stashってインデックスにあるもの(git addしたやつ)をstashします。

作業ツリーのものはstashしてないのです!

 

 

「だからたまに、"stashしたはずなのに、あのファイルがない!"とかなってたんだ・・・。」

 

 

作業ツリーからインデックス(git add)にあがることにより、

追跡(tracking)が開始されるのです。

よって、git addしなければ、バージョン管理外なのです!

 

##まとめ##

作業ツリーがダーティ(クリーンではない状態)の時は、

stashしたいものをaddして追跡を開始させたのちに、

git stashを実行すること!

 

 

 

 

 

 

 

HTTPステータスコード

 

参考:ここここ

Webに携わってもう直ぐ1年。

Webサイトをいじる中、スペルミスや設定ミスでエラーをよく見てきたのですが、

ヘッダーのstatus codeを見て、404の場合はパスが間違ってんのかな〜、

500番台に場合はPHPのコードスペルミスでのしたのかな〜とか確認してます。

しかし、このくらいしか分かりません。

 

 

この前、406エラーがでて、なにこれ!?ってなったので覚書します。

406 Not Acceptable 受理不可

Webサーバからクライアントへのレスポンスに、クライアントが受理できないデータが含まれている場合に発生する。

だそうです。

例)サーバはapplication/jsonを送信したかったが、リクエストのAccept:ヘッダにapplication/jsonが含まれていなかった。

 

 

まとめ

 

  • 100番台 ・・・ Information

リクエストは受け入れられ、処理は継続

  • 200番台 ・・・ Success

リクエストは正常に受け取られ、受理された。

  • 300番台 ・・・ Redirection

リクエストを完了するためには、他のURL等を参照する必要がある。

  • 400番台 ・・・ Client Error

クライアント側のエラー

  • 500番台 ・・・ Server Error

サーバー側のエラー

DRYの原則

参考:ここ

DRY

=Don’t Repeat Yourself

直訳すると「繰り返すな。」という意味です。

 

同じような内容のコードが重複していると、

変更際、重複の数だけ変更しなければなりません。

また、いざそのコードを使う時に、どれを使えば良いのかわからなくなります。

 

同じようなコードは一箇所にまとめとけ!同じようなコードは何度も書くな!

→再利用性の高いコードを書く必要がある。

 

この原則を守ると、シンプルで保守しやすいコードが書きやすくなるとのことです。

「シンプルなコードを書きたい!!」

 

関連している原則:

・Once and Only Once(OAOO)一度、ただ一度

OCP 開放閉鎖の原則

SRP 単一責務の原則

 

 

 

ISP(The Interface Segregation Principle) – SOLID

ISP(The Interface Segregation Principle)
– クライアントに対して利用しないインタフェースへの依存を強制してはならない。

参考:ここここ

 

・インターフェイスはクライアント(使う側)の都合により変更される

→インターフェイスはそれを使うクライアントごとに分離されるべき

 

 

・インターフェイスが分離されていないと、

クライアントにサーバが依存すべきところが、

サーバにクライアントが依存してしまい、

変更のたびに全体へ影響を与えてしまう。

→依存関係の逆転が成り立たず、脆弱となる。

 

 

・太った(いろんな役割を持つ=便利な)インターフェイスにしない。

→SRP(単一責務の原則)にする

 

・依存をできる限り減らす。

→クラス間の結合度(Coupling)を減らす

 

オブジェクト指向って難しい・・・。