Chatterbox Client

Chatterboxクライアント印刷はPrecos時のTwitter印刷と似ていますが、Twitter印刷はDOMがメインなのでクライアントでのみインタラクティブに行えます.今回のChatterbox sprintでは,クライアントがサーバにデータを要求し,応答を受信してこれらのデータ(クライアントとサーバ間のインタラクション)を表示する必要がある.つまり、今回のリリースの核心は「APIを使ってUIを作成する」ということです.
アプリケーションプログラミングインターフェース(API):プログラミングアプリケーションと通信可能なメディア
ユーザーインタフェース:ユーザーとコミュニケーション可能なメディア
インタフェース:物事間または物事と人とのコミュニケーションの媒介を作成する
Webアーキテクチャは主にクライアント、サーバ、DBから構成されています.クライアントは、ブラウザから返されるアプリケーションであり、ユーザーとのインタラクションを担当します.サーバ・アプリケーションは、クライアント・リクエストを受信したときにデータベースからデータを取得し、応答するリクエストと応答処理を担当します.
画像ソース:codestates urclass
クライアントがHttpというプロトコルを使用してサーバAPIに要求を発行すると、サーバは要求と応答を処理し、クライアントに転送する.その後、クライアントはブラウザ上でJavaScriptを駆動して表示部分を変更します.
画像ソース:codestates urclass

Web構造の基本要素

1.ブラウザ

ブラウザの役割は、バイナリ数字しか聞き取れないコンピュータにHTML、CSS、JSで書かれたコードを見ることができるようにすることです.すなわち、HTML、CSS、JSでコードを記述すると、ブラウザ内部エンジンV 8は、そのコードを復号してコンピュータにデータを転送し、コンピュータがデータを処理した結果をブラウザに表示する.ネットの普及はどうして失敗したのですか.
画像ソース:codestates urclass

2.サーバ（サーバ）

リソースを提供する主体.サーバーはスターバックスにたとえられる.つまり、お客様がコーヒー豆を飲料として飲みたい場合は、データベースからコーヒー豆を取り出し、飲料を製造するサーバとして使用する必要があります.サーバは、クライアントリクエストを受信すると、リソースに基づいて応答します.
画像ソース:codestates urclass

3. API(Application Programming Interface)

サーバは、データベース内の要素をよりよく利用するために、クライアントにインタフェースを提供する必要があります.すなわち,APIはサーバリソースをうまく利用できるインタフェースである.スターバックスに例えると、APIはスターバックスのメニューと言える.メニュー(API)があれば、サーバーは元豆をベースに飲み物(リソース)を作ることができます.
画像ソース:codestates urclass

4. HTTP(HyperText Transfer Protocol)

クライアントがサーバと通信する際に何らかのプロトコルを遵守することをHTTPと呼ぶ.
1)常に要求と応答で構成される.
2)クライアントがメッセージの送信を要求すると、サーバはメッセージを送信します(ない場合、サーバは「いいえ」と答え、要求を無視するとエラーが発生します).
3)HTTPリクエストはHeaderとBodyからなる.Headerには、どこから送信されたリクエスト(原点)、コンテンツタイプ(コンテンツタイプ)、どのクライアントを使用して送信されたかに関する情報(user-agent)が含まれており、Bodyは異なる方法で提供できない場合がありますが、サーバへのデータ送信のスペースとして使用できます.
4)応答は要求と同じ構造である.
5)HTTPの各リクエストは独立している(Stateless).すなわち、クライアントとサーバの間に1回のリクエストと応答がある場合、次のリクエストは前のリクエストとは異なるため、前のリクエストのコンテキストが不連続である.そのため、それを補うためには認証という手段を通らなければならない.
6)一度の要求に一度の応答(接続なし)を行う.すなわち,応答後に接続が切断されるため,再応答できず,再要求が必要となる.
7)HTTPの代表的なGET,POST,PUT,DELETE方式.GETがサーバにリソースを要求する場合、POSTはサーバにリソースを生成する場合(サーバにデータを送信するため)、PUTはサーバリソースを変更する場合(ex.profile update)、DELETEはサーバリソースを削除するために使用される.

5. Ajax(Asynchronous Javascript and XML)

以前、formタグを使用してページ切替と要求の応答を受信すると、必要な部分だけでなく、ページ全体をロードするという面倒な問題があった.これを補うために,サーバと自由に通信できるXMLhttpRequest(XHR)が出現し,ページシンチレーションを必要とせずにシームレスに動作するJavaScriptとDOMが用いられ,両者の結合がAjax(Asynchronous Javascript and XML)である.
Fetch APIは、XMLHttpRequestやjQuery方式を使用してサーバと通信する際に使いやすい標準APIです.しかしfetchはすべて良いわけではなく、XMLHttpRequestも依然として大量に使用されている.

fetch('http://52.78.213.9:3000/messages') //GET요청
.then(function(response) {
  return response.json(); //JSON형태의 데이터를 JS Object형태로 변경
})
.then(function(json) {
  // json 형태로 전달받은 서버로부터의 응답
  // JS, DOM을 조작하여 필요한 페이지만 수정
});

ブラウザのセキュリティ

1.XSS、CSRF攻撃

ブラウザが脅かされている根本的な原因は、ブラウザがJavaScriptを駆動することです.ブラウザのセキュリティに脅威を与える典型的な攻撃はXSSとCSRFである.
XSS:クライアントはサーバから受信したデータが正常であることを信頼しているため、問題が発生しています.ブラウザの更新に伴い、基本的なXSS攻撃がブロックされる.
CSRF:サーバがクライアントを信頼することによる問題.サーバはブラウザの認証情報を取得する際にそのユーザであると認識するため,ユーザが認証情報を取得しながらハッカーのリンクをクリックすると,ハッカーは認証情報をブロックしてサーバに要求を送信する.

2.クロスソース共有、クロスソース共有

MDNの定義によれば、CORSは、あるソース上で実行されるWebアプリケーションを使用して、別のソースの選択されたリソースへのアクセスをブラウザに許可する追加のHTTPヘッダを使用するメカニズムである.Webアプリケーションは、リソースがソース(ドメイン、プロトコル、ポート)と異なる場合に、クロスソースのHTTP要求を実行します.
セキュリティ上、ブラウザはスクリプトから始まるクロスソースHTTPリクエストを制限します.これは、ブラウザがブラウザアプリケーションを使用するユーザーをアクティブに保護するためのセキュリティ対策と理解できる.

2.1アクセス制御シナリオの例

1.簡単な要求:GET/HEAD/POST方法の一つを使用する.
2.事前送信要求(Preflight Request):単純な要求とは異なり、「preflighted」要求はまずOPTIONS方法によってHTTP要求を他のドメインのリソースに送信し、実際の要求が安全かどうかを検証する.Cross-siteリクエストは、ユーザデータに影響を与えるため、事前に送信される(prefired).
3.認証情報を含む要求:HTTPクッキーとHTTP認証情報を識別する.
**コンテンツソース:MDNコンテンツの整理