Webサーバー
Webサーバー
Webサーバーは、ユーザー(クライアント)からのリクエストを受けて、処理を行い、結果を返します。
結果としては、HTML,CSS,JSなどのファイルが返されてます。
ブラウザからインターネット上のWebページにアクセスした場合、Webページがファイルを返します。
その返ってきたファイルをブラウザで表示することで画面に表示されています。
ユーザーからのリクエストでは、どのファイルが欲しいかを指定します。
するとWebサーバーはそのファイルを返します。
また、スクリプトを実行し、その結果を返すようにすることもできます。
サーバーサイドで処理が必要な場合は、このようなスクリプトを利用することになります。
終わり
RailsでCORSを設定
CORS
CORSは、別のオリジンからのリクエストを許可するかどうかを決める仕組みです。
RailsでCORSを設定する
RailsでCORSの設定をします。 RailsでAPIサーバーを構築したときに、別のオリジンからのリソースアクセスを許可するように設定します。
RailsでCORSの設定をするには、rack-corsを利用します。
インストールはGemでできるので、Gemfileに書いて、bundle install
でインストールできます。
gem 'rack-cors'
設定は、config/initializers/cors.rb
ファイルに書いていきます。
Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: [:get, :post, :patch, :put] end end
ここで、どのオリジンからのアクセスを許可するか、どのリソースのアクセスを許可するかを設定します。
origins
で、どのオリジンからのアクセスを許可するかを設定します。
上の例では、ワイルドカード(*
)となっているので、すべてのオリジンからのアクセスを許可します。
resource
で、どのリソースのアクセスを許可するかを設定します。
上の例では、ワイルドカード(*
)となっているので、すべてのリソースのアクセスを許可します。
メソッドとして、[:get, :post, :patch, :put]
が設定されているので、GETメソッド、POST
POSTメソッド、PATCHメソッド、PUTメソッドを許可します。
終わり
Origin (オリジン)
Origin (オリジン)
Origin (オリジン)は、URLのスキーム、ホスト、ポートの組み合わせで決まります。
これら(スキーム、ホスト、ポート)がすべて同じときのみ、同じオリジンであるといえます。
スキームとは、httpやhttpsなどプロトコルのことです。
http://example.com/api1
とhttp://example.com/api2
は、スキーム(http)、ホスト(example.com)、ポート(80)がすべて同じなので、同一オリジンです。
つまり、ディレクトリ以下はオリジンとは無関係ということです。
http://example.com
とhttps://example.com
は、スキームが異なるため、同一オリジンではありません。
http://example.com
とhttp://www.example.com
は、ホストが異なるため、同一オリジンではありません。
http://example.com
とhttp://example.com:8080
は、ポートが異なるため、同一オリジンではありません。
同一生成元ポリシー
同一生成元ポリシー (同一オリジンポリシー)は、同一オリジンではない場合に、制限を設けています。
例えば、次のようなものが一例として挙げられます。
- XMLHttpRequestによる取得の禁止
- スクリプトによる別のoriginであるiframeやwindowに対する操作の制限(iframe.contentWindow、window.parent、window.open、window.openerなど)
- Canvasへの一部の操作の制限
要は、異なるオリジン間でのリソースのアクセスを制限・禁止します。
これらの制限によって、攻撃の脅威を減らすことができます。
CORS
しかし、Web開発を行うにあたり、異なるオリジン間のリソースアクセスをしたいときもあります。
そのような場合に、CORSを設定します。
CORSは、Cross-Origin Resource Sharingの略で、オリジン間リソース共有ともいいます。
CORSは、別のオリジンからのリクエストを許可するかどうかを決める仕組みです。
CORSを正しく設定することで、異なるオリジン間でもリソースのアクセスが可能になります。
終わり
webpack-dev-server
Hot Module Replacement (HMR)
Hot Module Replacement (HMR) は、ファイルの更新を自動でブラウザに反映する仕組みです。
HMRでは、ページ全体を更新することなく、変更したモジュールのみを置き換えることで画面を更新します。
HMRにより、ファイルの変更を自動で、ブラウザに反映してくれるため、開発の手助けとなります。
また、差分だけの変更をすることで、変更を素早く反映することができます。
webpack-dev-server
webpackでHMRを利用するには、webpack-dev-serverを利用します。
webpack-dev-serverでは、JavaScriptの変更を検知し、自動でブラウザに反映します。
開発時には、webpack-dev-serverを利用し、HMRを活用しながら開発を行います。
一方で、デプロイ時には、webpackでバンドルし、バンドルされたファイルをデプロイすることになります。
終わり
Webpack
webpackとは
webpackとは、JavaScriptのモジュールバンドラです。
モジュールバンドラは、複数のモジュールをまとめるものになります。
webpackでは、JavaScriptを主に、HTMLやCSS、画像などもバンドルできるようです。
「webpackはなぜ必要?」
webpackを利用することで、複数のモジュールの依存関係や読み込み順序を自動で解決してくれます。
人の手で行う場合、モジュールの数が増えると複雑度が増し、ミスも増えてしまいます。
また、ファイルを一つにまとめることでリクエスト数を減らすこともできます。
各モジュールのJSファイルを一つずつリクエストする場合、リクエスト数が増えてしまいます。
「webpackとBabelの違いは?」
webpackはモジュールバンドラで、Babelはトランスパイラです。
つまり、webpackとBabelでは役割が異なります。
webpackは複数のモジュールをまとめるツールです。
一方で、Babelは新しいバージョンで書かれたJavaScriptプログラムを種々のブラウザで動作するように古いバージョンのJavaScriptプログラムに変換するツールです。
終わり
DNS tips
dig コマンド と nslookup コマンド
digコマンドもnslookupコマンドも、DNS問い合わせを行うコマンドです。
digコマンドとnslookupコマンドで、google.comをDNS解決してみます。
dig コマンド
$ dig google.com ; <<>> DiG 9.16.1-Ubuntu <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44872 ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 0 IN A 142.250.206.238 ;; Query time: 50 msec ;; SERVER: 192.168.112.1#53(192.168.112.1) ;; WHEN: Mon Aug 30 13:08:58 JST 2021 ;; MSG SIZE rcvd: 54
nslookupコマンド
$ nslookup google.com Server: 192.168.112.1 Address: 192.168.112.1#53 Non-authoritative answer: Name: google.com Address: 142.250.206.238 Name: google.com Address: 2404:6800:400a:804::200e
表示の形式はことなりますが、それぞれ名前解決されています。
IPv4で142.250.206.238
というアドレスが、両方に表示されているのが確認できます。
127.0.0.1 localhost
127.0.0.1はループバックアドレスといって、自分自身を指し示すために使われる特別なIPアドレスです。
ドメイン名localhost
は、名前解決すると127.0.0.1を指すようになっていて、自分自身となります。
/etc/hosts
Linuxには、/etc/hosts
というファイルが存在します。
これは名前解決に利用されるドメイン名とIPアドレスの組が記載されたファイルとなります。
例えば、localhost
が127.0.0.1となるのも、/etc/hosts
に記されています。
この/etc/hosts
ファイルは、DNS普及前に利用されていたようです。
DNSによる名前解決ではなく、このファイルによる名前解決が一般的だったようです。
終わり
Domain Name System (DNS)
Domain Name System (DNS)
Domain Name System (DNS) は、ドメイン名を管理するための仕組みです。
インターネット上で、ほかのマシンにアクセスするとき、宛先は「IPアドレス」によって指定します。
しかし、数字の列挙であるIPアドレスは、人々にとって読みにくいし、覚えにくいものです。
そこで、example.comやgoogle.comなどのようなドメイン名を使って宛先を指定できるようするシステムがDNSです。
DNSは、example.comやgoogle.comなどのようなドメイン名とIPアドレスの対応付けを行います。
DNSサーバーに問い合わせすることで、ドメイン名→IPアドレスの変換ができるわけです。
DNSサーバーに問い合わせして、そのドメイン名に対応づいているIPアドレスを教えてもらうことで、目的のマシンにアクセスできるようになります。
問い合わせ先のDNSサーバーが、そのドメイン名のIPアドレスを知っていた場合、そのIPアドレスを教えてもらえます。
しかし、問い合わせ先のDNSサーバーが、そのドメイン名を知らなかった場合は、さらに別のDNSサーバーに問い合わせします。
問い合わせはドメイン名の後ろから、順々に行われます。
どのDNSサーバーを利用するかは、ルーターで設定できます。
そこで、Googleが運営する「Google Public DNS」などを利用することもできます。
Google Public DNSのIPアドレスは8.8.8.8です。
終わり