Nginxの設定ファイルの項目の意味
Nginxの設定ファイルは /etc/nginx/nginx.conf
{} とinclude行はディレクティブと呼ばれている。 {}の中に書いた行をコンテキストと呼んでいて、{}の中でだけ有効になる。 各ディレクティブ、例えばhttpディレクティブにはhttpコンテキストを書く事と決まっている。 どの{}にも囲われていない部分はmainコンテキストとして扱われる。
upstream { server #アプリケーションサーバーのsocketを指定する } server { listen #ポート番号を指定する server_name #localhost など root #このserverブロックで使うルートをどこにするか決める try_files #ここに記述したファイルが存在するか探す。複数記述でき、 複数記述した場合、左から順に探していく。 location { } }
クッキーとセッション2
session[:user_id] = user.id
sessionはセッションオブジェクトを返すメソッド。 sessionオブジェクトはどこからでも参照でき、sessionオブジェクトに値がセットされていることがログインしていることの証明になる。
<body> <header> <h1>title-title</h1> <% if login? %> <%= link_to 'ログアウト', sessions_destroy_path, method: :delete %> <% else %> <%= link_to '新規登録', new_user_path %> <%= link_to 'ログイン', sessions_new_path %> <% end %> </header>
module SessionsHelper def login(user) if user session[:user_id] = user.id else redirect_to root_path end end def login? session[:user_id] end def logout session[:user_id] = nil end end
サーバー内にセッション情報を管理した領域を持つ(どこにあるのかわからないがセッションを持っている領域がある)。 セッションはハッシュのような構造をしているそうで、キーをセッションIDと呼び、値はさっき書いたuser.idになる。
Set-Cookieで、キーをブラウザに渡す。 ブラウザからCookieで送られてくるセッションID(キー)からセッション情報を検索し、一連のリクエストで共有するデータを取得する。
railsのセッションは複数のリクエストにまたいで維持される、ハッシュのような構造です。 セッションは生のcookieと違って、任意のオブジェクトを保持でききる。 サーバーにデータを格納する方法は、まず32桁の16進数のキーを作成する。このキーをセッションIDとよんでいる。 RailsはこのセッションIDをユーザーのブラウザにcookieとして保存する。以降アプリはリクエストを受け取った時、 このセッションIDを復元する。次にRailsは、セッションデータをセッションIDをインデックスとしてサーバー上に永続的に保存する。 Railsはリクエストを受けと取ると、セッションIDをっ使って、データストアを探し結果をコントローラのセッション属性に格納する。
セッションとクッキーは別物。 session[:user_id] と cookies[:remember_token] は別物。 ログインの実装だけなら、cookies[~]は不要で、session[:user_id]を使って実現できる。 次回ログインする時に、名前とパスワードの入力をパスしてログインさせたい時にcookies[:remember_token]を使って実現する。 ログインを実装するときに必ずcookies[~]を使うのだろうと思っていたが、違った。
https://teratail.com/questions/33522
クッキーとセッション1
クッキー
セッションストア
- RailsのデフォルトはCookieStore
セッション
- セッションはクッキーに保存される。つまりブラウザに保存される。
ruby on rails - セッションを保存するとき、なぜ、Cookieではなくmemcachedやredisを使用するのでしょうか? - スタック・オーバーフロー
参考
Ruby入門のメモ
クラスをあまりわかっていないのでメモしとく。
クラスの概念
initialize
オブジェクトを作成する時に必ず実行したい事をメソッドを呼び出さずにここで実行する。
アクセスメソッド
クラスの中で使われているインスタンス変数はクラスの外からは、アクセスできない。変数を弄りたい時は、インスタンスメソッドを使って操作する。なので、クラスの中にそのやりたい事をメソッドして書いて置かなければならない。というか、そうする。
ただ単に、変数の値を読みだす、書き換えるだけの為に、アクセスメソッドが用意されている。 attr_accessor: 変数名
定数
クラス内で定義された定数は、以下の様に書くとクラス外で参照できる。 クラス名::定数名
クラス変数
クラス変数は、そのクラスから作られた全てのオブジェクトで値を共有できる仕組み。
クラスの継承
クラスを継承する
Class クラス名 < 継承するクラス名
メソッドのオーバーライド
継承を使った場合、スーパークラスとサブクラスで同名のメソッドを新しく定義する事が出来る。その事をオーバーライドすると言う。 オーバーライドしなかった場合は、スーパークラスのメソッドがそのまま使われる。
スーパークラスのメソッドを呼び出す。
サブクラスでメソッドをオーバーライドけど、スーパークラスのメソッドを使いたい場合は、superを使う。superの部分にスーパークラスのメソッドの戻り値が入る。
アクセス制御
クラスに書いたメソッドのうち、インスタンスからアクセスしない、メソッドが使うだけのメソッドには キーワード private を付ける。 private :メソッド名 initializeメソッドは常にprivateになる。
アクセス制御をまとめて設定する
privateと書いてその下にメソッドを書くと、それ以降は全て private になる。
モジュール
モジュールの定義
定義の仕方: module モジュール名 end
モジュールは、インスタンスを作れない。 モジュールは他のクラスにincludeして使う。 モジュールは多分、サブルーチンの事。
モジュールを関数のように使う
モジュール内に module_function :メソッド名 と書いて外から モジュール名.メソッド名 と呼んで使う。 includeした場合は、メソッド名だけで呼べる。
ホワイの(感動的)Rubyガイド :: 3. (漫画のキツネと学ぶ)短時間の(そして願わくは辛くない)Rubyコース
変数 → ニックネーム float → 小数 シンボル → 文字列を使いたいが画面に表示する必要がない場合に使う。 ブロック → ブロックを使って1組の命令をまとめてグループにして、それをプログラムの中で受け渡すことが出来る。 ハッシュ → 辞書のようなもの << → 末尾に追加する
HTTPの基本
HTTPのリクエストヘッダー
一行目をリクエストラインと呼び、二行目以降をリクエストヘッダと呼ぶ。
GET / HTTP/1.1 Accept: image/gif, image/jpeg, */* Accept-Language: ja Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (Compatible; MSIE 6.0; Windows NT 5.1;) Host: www.xxx.zzz Connection: Keep-Alive
それぞれのヘッダの意味
GET / HTTP/1.1
- GET通信でHTTP1.1を使う
Accept: image/gif, image/jpeg, /
- ブラウザが解釈できるコンテンツタイプをMIMEタイプで伝える。/ の記号はどんな形式のデータも受信可能のであることをサーバーに伝える。MIMEタイプとは、スラッシュで区切った形で書く標準化された書き方。 https://developer.mozilla.org/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types
Accept-Language: ja
- ブラウザが解釈する言語をサーバーに伝える。
Accept-Encoding: gzip, deflate 圧縮されたデータをブラウザが解釈できる方法を示す。クライアントとサーバーが共通の圧縮アルゴリズムをサポートしている必要がある。サーバーが圧縮したコンテンツを送っても、ブラウザが解凍できないと意味がない。
HTTPリクエストヘッダ Accept-Encoding とは? | WEB ARCH LABO
User-Agent: Mozilla/4.0 (Compatible; MSIE 6.0; Windows NT 5.1;)
- ブラウザ自身の情報
Host: www.xxx.zzz
- サーバー名を送信する。
Connection: Keep-Alive
- Keep-Aliveで接続をし続けるメッセージになる。次回のコネクションのコストを減らせる。接続を辞める時は、closeを送信する。
HTTPレスポンス
HTTP/1.1 200 OK Date: Sun, 11 Jan 2004 16:06:23 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) Last-Modified: Sun, 07 Dec 2003 12:34:18 GMT ETag: "1dba6-131b-3fd31e4a" Accept-Ranges: bytes Content-Length: 4891 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html <!DOCTYPE html> <html> : </html>
それぞれのヘッダー
HTTP/1.1 200 OK
- HTTP1.1 の通信でステータスコードが200
Date: Sun, 11 Jan 2004 16:06:23 GMT
- レスポンスを返した時の日時の情報
Server: Apache/1.3.22 (Unix) (Red-Hat/Linux)
- レスポンスを返したサーバーの名前
Last-Modified: Sun, 07 Dec 2003 12:34:18 GMT
- 最後にリソースに対する変更があった日時。リソースとはHTMLや画像の事。
ETag: "1dba6-131b-3fd31e4a"
- リソースが更新されたら変化する値
Accept-Ranges: bytes
Content-Length: 4891
- ボディの大きさを単位バイトで示す。
Keep-Alive: timeout=15, max=100
- timeout: 1回あたりのコネクション確立時間。 max: timeoutする前にこの接続でリクエストできる最大数
HTTPのkeepaliveの仕様を勘違い | thiroyoshi.blog
Connection: Keep-Alive Content-Type: text/html
鍵とSSL
### 公開鍵と秘密鍵をそれぞれどちらに置くか
# scpする時の鍵の作成
ログインする側に秘密鍵をを置く
ログインされる側に公開鍵を置く
なので、クライアントで鍵を作って、scpでサーバーに公開鍵をコピーして、
コピーしたらクライアントの公開鍵をrmで消す。
### 鍵について
# 秘密鍵とは
この世に1つしかない鍵。鍵を作った者しか持っていない。
# 公開鍵とは
秘密鍵を復号できる鍵。公開鍵は複数存在しても構わない。
# 共通鍵とは
共通鍵暗号を使うには、誰にも知られていない同じ鍵をクライアントとサーバーが持ってないといけない。公開鍵で共通鍵を暗号化して秘密鍵を持っている者に送る。
# 公開鍵暗号化方式とは
秘密鍵で暗号化したデータは公開鍵でしか復号できない
公開鍵で暗号化したデータは秘密鍵でしか復号できない
つまりセットの関係になっている。
# サーバー証明書とは
サーバー証明書は、認証局と呼ばれる組織に申請して発行してもらう。
証明書には公開鍵の情報が書き込まれている。
# SSL
SSLは、送信するデータを暗号化する事と通信相手が信頼できる相手かどうかを確かめる機能を持っている。クライアントがサーバーからサーバー証明書を受け取り、その証明書を検証する事で通信相手のサーバーが信頼できるかどうかを判断する。SSLをベースにした技術がTLS。SSLとTLSはほぼ同じ機能だそうだ。
http://tech.nikkeibp.co.jp/it/article/COLUMN/20071002/283518/
Let's Encript