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

はじめに

メモ群なので、気になった見出しをご覧ください！

メモず

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 という一つのファイルで行われ、この中で各種の認証オプションを設定します。このファイル内で、必要なオプションのみを明示的に設定することで、アプリケーション全体の認証メカニズムを管理します。

例:

# 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の

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

ログインしているかどうかがわかる

# 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が呼ばれる

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