gem `Sorcery` +αメモず 【Rails】

# はじめに

メモ群なので、気になった見出しをご覧ください！
# メモず
## sorceryの言語（？）思想
[Sorcery](https://github.com/Sorcery/sorcery)の思想のうち、特にお気に入りのポイント
- Less is more：少ないほど良い
- Simple & short configuration as possible：可能な限りシンプルで短い
- Keep MVC cleanly separated - DB is for models, sessions are for controllers. Models stay unaware of sessions：MVCを混ぜない。分離させたまま
### Configuration over Confusion
ぱっと見、Railsの言語思想「CoC」に見えるが、
Railsは「Convention over Configuration（設定より慣例）」
Sorceryは「Configuration over Confusion（混乱より設定）」
と、Railsをもじった別物。
糖衣構文（簡潔化されたメソッド名）で「なにやってるかわからない！」となるより、
「短くてシンプルな設定を書いて制御しようね！」ってことらしい。


> 「Configuration over Confusion」の原則に従ったコードの例を示すと、Sorceryの設定は一つの設定ファイルに集約され、可能な限りシンプルかつ短いものになっています。これは、煩雑な構文や複雑な設定よりも、明瞭で簡潔な設定を好むアプローチを反映しています。
> 
> 具体的には、Sorceryの設定は例えば `config/initializers/sorcery.rb` という一つのファイルで行われ、この中で各種の認証オプションを設定します。このファイル内で、必要なオプションのみを明示的に設定することで、アプリケーション全体の認証メカニズムを管理します。
> 
> 例:
> ```ruby
> # config/initializers/sorcery.rb
> Sorcery.configure do |config|
>   # ここに認証に関する基本的な設定を記述
>   config.user_class = "User"
>   config.user_email_attribute_name = :email
>   # その他の必要な設定...
> end
> ```
> 
> この例では、ユーザークラスやメール属性など、基本的な認証に関する設定が行われています。Sorceryはこのように、簡潔で集中的な設定を通じて、複雑さを避け、開発者の混乱を減らすことを目指しています。


### Magic yes, Voodoo no
**複雑さを隠すが理解可能な「マジック」は使っても良いが、不明瞭な「ブードゥー」は避けるべきであることを意味する。**

>プログラミングにおいて「マジック」とは、複雑なタスクを隠蔽しながら処理を行うコードのことで、通常はシンプルなインターフェースを提供します。
>この表現は、コードの実際の動作がすぐには明らかではないことを示唆しており、しばしば悪い意味合いを持ちますが、愛着を込めて使われることもあります。
>一方、「ブードゥー（Voodoo）」は、論理ではなく迷信や推測に基づいてコーディングすることを指し、通常は好ましくないプラクティスとされます。したがって、「Magic yes, Voodoo no」は、複雑さを隠すが理解可能な「マジック」は使っても良いが、不明瞭な「ブードゥー」は避けるべきであることを意味しています。

## `salt`って何？
[sorcery wiki](https://github.com/Sorcery/sorcery/wiki/Simple-Password-Authentication)の
>To get some views and controllers fast, we'll run rails scaffold generator, and skip the files we already created (we'll need to delete the new migration manually though):
>
>`rails g scaffold_controller user email:string crypted_password:string salt:string`
>
>We don't want users to edit/view their crypted password or **salt**, so we'll remove these from all templates in app/views/users/.

の部分です。
「パラメータとして`salt`と`crypted_password`を持つコントローラを生成」しているのですが
・・・`salt`とは？
### `salt`：塩をひとつまみ

「ブルートフォース攻撃」や「レインボーテーブル攻撃」に対して有効なセキュリティの仕組み。
「塩をひとつまみ加える」イメージで、「パスワードにひとつまみ加える」
#### 具体的なステップ
> 1. **パスワードの作成**: ユーザーが`pass_abc`というパスワードを作成します。
> 
> 2. **ソルトの追加**: システムはランダムに生成されたソルト（例えば`e8v`）をパスワードに追加します。これにより、パスワードは`pass_abce8v`になります。
> 
> 3. **ハッシュ化**: `pass_abce8v`という組み合わせをハッシュ関数にかけ、ハッシュ化されたパスワード（`crypted_password`）を生成します。
> 
> 4. **データベースへの保存**: データベースには`user_name`（ユーザー名）、`salt`（この例では`e8v`）、そして`crypted_password`（ハッシュ化されたパスワード）が保存されます。
> 
> このプロセスにより、同じパスワードを使用している異なるユーザーでも、各ユーザーにユニークなソルトが割り当てられるため、データベースに保存されるハッシュ値は異なるものになります。これは、パスワードのセキュリティを高め、特にレインボーテーブル攻撃などの一部の攻撃方法を効果的に防ぐのに役立ちます。さらに、ソルトを使用することで、攻撃者がデータベースからハッシュ値を盗み出したとしても、元のパスワードを推測することが格段に難しくなります。

#### 補足：ブルートフォース攻撃
総当たりでパスワードを試す。
1. ログイン画面で、パスワードの試行を繰り返す
2. クラックされたパスワード（ハッシュ値）と一致するパスワードを、推測されたハッシュ関数を用いて試行を繰り返す。

の2パターンがある。
`salt`は前者には無力だが、後者に効果がある。
#### 補足：レインボーテーブル攻撃
事前計算された、ハッシュと平文のペアから逆引きする。
`salt`により、計算コストをあげることができる。

## `if current_user`
ログインしているかどうかがわかる
```erb
# app/views/layouts/application.html.erb
    <% if current_user %>
      <%= link_to "Edit Profile", edit_user_path(current_user.id) %>
      <%= link_to "Logout", :logout, method: :post %>
    <% else %>
      <%= link_to "Register", new_user_path %> |
      <%= link_to "Login", :login %>
    <% end %>
```
## `require_login`：ログインされているときのみ
ログインされていない場合は、`not_authenticated`が呼ばれる
```rb
class UsersController < ApplicationController
  before_action :require_login, except:[:new, :create]
  # code
  private
	  def not_authenticated
	      redirect_to login_path, alert: "Please login first"
	  end
 end
```