إنشاء نظام تسجيل دخول باستخدام Ruby

إن بناء نظام تسجيل دخول ليس مجرد خطوة تقنية عابرة داخل أي تطبيق، بل هو أحد أهم الأجزاء التي تحدد مدى ثقة المستخدم في مشروعك من أول لحظة. عندما يدخل المستخدم إلى موقعك أو تطبيقك، فهو لا يريد فقط أن يرى واجهة جميلة أو صفحات مرتبة، بل يريد أن يشعر أن بياناته في مكان آمن، وأن عملية الدخول والخروج واضحة وسلسة، وأن التعامل مع كلمة المرور يتم باحترام واحترافية. لهذا السبب، فإن إنشاء نظام تسجيل دخول باستخدام Ruby يحتاج إلى فهم جيد للأساسيات قبل كتابة أي سطر كود، لأنك لا تبني فقط شاشة تسجيل دخول، بل تبني بوابة كاملة تتحكم في من يدخل، ومتى يدخل، وكيف تتم حماية بياناته.

Ruby لغة محبوبة لأنها تجمع بين البساطة والقوة، وهذا ما يجعلها خيارًا رائعًا لبناء الأنظمة الخلفية التي تعتمد على الأمان وتنظيم البيانات. وفي هذا المقال سنبني تصورًا عمليًا لنظام تسجيل دخول كامل باستخدام Ruby، وسنمشي خطوة خطوة من الفكرة العامة إلى التطبيق، مع أمثلة برمجية واضحة، وتفسير منطقي لكل جزء، حتى تكون الصورة كاملة أمامك. لن نكتفي بنموذج صغير يطبع “Welcome” للمستخدم، بل سنفهم كيف يتم تسجيل المستخدم، كيف تُحفظ كلمة المرور بشكل آمن، كيف تتم المصادقة، كيف تُنشأ الجلسة، كيف يتم تسجيل الخروج، وكيف يمكن لاحقًا تطوير النظام ليشمل استرجاع كلمة المرور والتحكم في الصلاحيات.

لماذا نحتاج إلى نظام تسجيل دخول أصلًا؟

تخيل أن لديك تطبيقًا بسيطًا لإدارة المهام أو متجرًا إلكترونيًا أو منصة تعليمية. من دون نظام تسجيل دخول، لن تستطيع التمييز بين مستخدم وآخر، ولن تستطيع حفظ بيانات كل مستخدم بشكل شخصي، ولن تستطيع أن تمنح صلاحيات مختلفة بحسب الدور أو المستوى. تسجيل الدخول هو الذي يحوّل الزائر العابر إلى مستخدم معروف داخل النظام. ومن هنا تبدأ كل الوظائف المهمة: عرض بياناته الخاصة، حفظ إعداداته، تتبع نشاطه، حماية معلوماته، وتخصيص التجربة بما يناسبه.

النظام الجيد لا يجب أن يكون معقدًا بلا داعٍ، لكنه في الوقت نفسه لا يجب أن يكون ساذجًا. كثيرون يرتكبون خطأ شائعًا عندما يحفظون كلمة المرور كما هي داخل قاعدة البيانات، أو يرسلونها ضمن الطلبات بطريقة غير مناسبة، أو يكتفون بواجهة جميلة دون حماية حقيقية. بينما الواقع يقول إن أي نظام تسجيل دخول محترم يجب أن يقوم على مبدأين أساسيين: التحقق من هوية المستخدم و حماية بياناته. وإذا لم يتحقق هذان المبدآن، فإن المشروع كله يصبح هشًا مهما بدا جميلًا من الخارج.

اختيار النهج المناسب في Ruby

عندما نتحدث عن Ruby، هناك أكثر من طريقة لبناء نظام تسجيل دخول. يمكنك أن تبني النظام باستخدام Ruby الخام مع إطار مثل Sinatra أو Rack، أو أن تستخدم Ruby on Rails الذي يوفر أدوات جاهزة كثيرة تجعل العمل أسرع وأكثر تنظيمًا. في هذا المقال سنعتمد نهجًا قريبًا من Rails لأنه الأكثر واقعية في المشاريع الإنتاجية، لكن الأفكار نفسها تنطبق على أي مشروع Ruby تقريبًا. حتى لو كنت تعمل على مشروع بسيط، ستجد أن نفس المبادئ تُستخدم: نموذج للمستخدم، تشفير لكلمة المرور، جلسات Session، معالجات Controller، ونقاط تحقق أمنية.

الميزة الكبرى في Rails أنه يمنحك بنية واضحة، وهذا مهم جدًا في أنظمة تسجيل الدخول. فبدل أن تكتب كل شيء يدويًا بشكل فوضوي، تستطيع الاعتماد على تقسيم منطقي للمكونات: User كموديل، SessionsController للدخول والخروج، وRegistrationsController لإنشاء الحسابات، مع استخدام BCrypt لتشفير كلمات المرور، وsession أو cookies لحفظ حالة المستخدم بعد تسجيل الدخول. هذه البنية ليست فقط منظمة، بل تجعل الصيانة المستقبلية أسهل بكثير.

الفكرة العامة للنظام

قبل الدخول إلى الكود، من المفيد أن نرسم في ذهننا ما الذي يحدث فعليًا عندما يسجل المستخدم دخوله. العملية عادة تمر بهذه الخطوات:

1. يكتب المستخدم بريده الإلكتروني أو اسم المستخدم وكلمة المرور.

2. يرسل النموذج البيانات إلى الخادم.

3. يبحث الخادم عن المستخدم في قاعدة البيانات.

4. يتحقق من أن كلمة المرور المدخلة تطابق كلمة المرور المخزنة بعد التشفير.

5. إذا كانت البيانات صحيحة، ينشئ الخادم جلسة session أو يضع معرف المستخدم في cookie آمنة.

6. يوجه المستخدم إلى الصفحة المطلوبة.

7. في حال تسجيل الخروج، يتم حذف الجلسة أو إبطالها.

هذه الفكرة تبدو بسيطة، لكنها تحتوي على تفاصيل كثيرة جدًا من ناحية الأمان. فمثلًا، لا يجب أن تقارن كلمات المرور المقروءة مباشرة، ولا يجب أن تخزنها كنص صريح، ولا يجب أن تعيد رسائل خطأ تكشف ما إذا كان البريد الإلكتروني موجودًا أم لا بطريقة تسهّل الهجمات. ولهذا سنحاول أن نكتب النظام بعقلية عملية، لا بعقلية تجريبية فقط.

تهيئة المشروع

إذا كنت تعمل على Ruby on Rails، فغالبًا ستبدأ بمشروع جديد ثم تنشئ نموذج المستخدم. أما إذا كنت تستخدم Ruby مع إطار أخف مثل Sinatra، فستظل بحاجة إلى نفس المكونات الأساسية تقريبًا. في المثال التالي سنفترض وجود مشروع Rails بسيط.

أولًا، نضيف مكتبة BCrypt التي تساعدنا على تشفير كلمات المرور بشكل آمن:

# Gemfile
gem 'bcrypt', '~> 3.1.7'

ثم نثبتها:

bundle install

بعد ذلك ننشئ نموذج المستخدم:

rails generate model User name:string email:string password_digest:string
rails db:migrate

العمود password_digest مهم جدًا، لأنه ليس كلمة المرور نفسها، بل القيمة المشفرة الناتجة عن BCrypt. هذا فرق أساسي، ويجب أن يظل حاضرًا دائمًا في ذهنك. نحن لا نخزن كلمة المرور، نحن نخزن نسخة غير قابلة للقراءة المباشرة منها.

إعداد نموذج User

الخطوة التالية هي تعريف سلوك المستخدم داخل الموديل. في Rails، يمكننا الاستفادة من has_secure_password التي توفر وظائف جاهزة للتحقق من كلمة المرور بشكل آمن.

# app/models/user.rb
class User < ApplicationRecord
  has_secure_password

  before_save :downcase_email

  validates :name, presence: true, length: { minimum: 2, maximum: 50 }
  validates :email, presence: true, uniqueness: true, format: { with: URI::MailTo::EMAIL_REGEXP }
  validates :password, presence: true, length: { minimum: 6 }, on: :create

  private

  def downcase_email
    self.email = email.downcase
  end
end

هذا الموديل يقوم بعدة أشياء في غاية الأهمية. أولًا، has_secure_password يضيف لك أساليب مثل authenticate، وهي الأسلوب الذي سنستخدمه لاحقًا للتحقق من كلمة المرور. ثانيًا، validates تضمن أن البيانات المدخلة معقولة قبل حفظها. ثالثًا، before_save يجعل البريد الإلكتروني يُخزن بالحروف الصغيرة، حتى لا نواجه مشكلة اختلاف الأحرف الكبيرة والصغيرة عند البحث.

تخيل المستخدم يكتب Ahmed@Email.com مرة وahmed@email.com مرة أخرى. من دون توحيد الكتابة، قد يظن النظام أن هناك مستخدمين مختلفين. هذا النوع من التفاصيل الصغيرة يصنع فرقًا كبيرًا في تجربة الاستخدام.

إنشاء نموذج التسجيل

الآن نحتاج إلى نموذج يتيح للمستخدم إنشاء حساب جديد. في واجهة الويب عادة يكون هناك صفحة تحتوي على اسم، بريد إلكتروني، كلمة مرور، وتأكيد كلمة المرور. في Rails، يمكن أن يكون لدينا Controller مخصص للتسجيل.

# app/controllers/registrations_controller.rb
class RegistrationsController < ApplicationController
  def new
    @user = User.new
  end

  def create
    @user = User.new(user_params)

    if @user.save
      session[:user_id] = @user.id
      redirect_to root_path, notice: "تم إنشاء الحساب بنجاح"
    else
      render :new
    end
  end

  private

  def user_params
    params.require(:user).permit(:name, :email, :password, :password_confirmation)
  end
end

هذه القطعة البرمجية بسيطة ظاهريًا، لكنها تحتوي على قلب النظام. عند نجاح الحفظ، نضع user_id داخل الجلسة، وبذلك يعرف التطبيق أن هذا المستخدم أصبح مسجلًا بالفعل. عند فشل الحفظ، نعيد نفس الصفحة مع الأخطاء حتى يصحح المستخدم مدخلاته. بهذه الطريقة لا نجبره على إعادة إدخال كل شيء من الصفر، وهذا بحد ذاته تفصيل مهم جدًا.

وفي صفحة العرض الخاصة بالتسجيل، قد يكون النموذج بهذا الشكل:

<!-- app/views/registrations/new.html.erb -->
<h2>إنشاء حساب جديد</h2>

<%= form_with model: @user, url: registrations_path do |form| %>
  <div>
    <%= form.label :name, "الاسم الكامل" %>
    <%= form.text_field :name %>
  </div>

  <div>
    <%= form.label :email, "البريد الإلكتروني" %>
    <%= form.email_field :email %>
  </div>

  <div>
    <%= form.label :password, "كلمة المرور" %>
    <%= form.password_field :password %>
  </div>

  <div>
    <%= form.label :password_confirmation, "تأكيد كلمة المرور" %>
    <%= form.password_field :password_confirmation %>
  </div>

  <%= form.submit "إنشاء الحساب" %>
<% end %>

من الجميل أن تتذكر أن النموذج ليس مجرد عناصر HTML، بل هو الحوار الأول بين المستخدم والنظام. لهذا السبب يجب أن يكون واضحًا، هادئًا، ويعطي رسائل أخطاء مفهومة. المستخدم لا يحب أن يشعر أنه ارتكب جريمة تقنية عندما أخطأ في حرف واحد.

إنشاء نموذج تسجيل الدخول

بعد إنشاء الحساب، نأتي إلى خطوة تسجيل الدخول. هنا سيكتب المستخدم البريد الإلكتروني وكلمة المرور، وسنبحث عن المستخدم ثم نتحقق من صحّة كلمة المرور. من الأفضل دائمًا أن نجعل منطق المصادقة واضحًا ومختصرًا.

# app/controllers/sessions_controller.rb
class SessionsController < ApplicationController
  def new
  end

  def create
    user = User.find_by(email: params[:email]&.downcase)

    if user && user.authenticate(params[:password])
      session[:user_id] = user.id
      redirect_to root_path, notice: "مرحبًا بك مرة أخرى"
    else
      flash.now[:alert] = "البريد الإلكتروني أو كلمة المرور غير صحيحة"
      render :new
    end
  end

  def destroy
    session.delete(:user_id)
    redirect_to root_path, notice: "تم تسجيل الخروج بنجاح"
  end
end

لاحظ أننا لم نكتب أي مقارنة مباشرة لكلمة المرور. نحن استخدمنا authenticate، وهذه ميزة آمنة جدًا لأن BCrypt يتولى المقارنة داخليًا بطريقة مناسبة. هذا أفضل بكثير من أن تكتب شيئًا مثل:

if user.password == params[:password]

هذا الأسلوب خاطئ وخطر، لأنه يعني أنك تحتفظ بكلمة المرور كنص عادي، وهذا لا ينبغي أن يحدث أبدًا.

واجهة تسجيل الدخول بدورها قد تكون هكذا:

<!-- app/views/sessions/new.html.erb -->
<h2>تسجيل الدخول</h2>

<%= form_with url: sessions_path do |form| %>
  <div>
    <%= form.label :email, "البريد الإلكتروني" %>
    <%= form.email_field :email %>
  </div>

  <div>
    <%= form.label :password, "كلمة المرور" %>
    <%= form.password_field :password %>
  </div>

  <%= form.submit "دخول" %>
<% end %>

بذلك نكون قد أنشأنا مسارًا كاملًا من التسجيل إلى الدخول. لكن هذا ليس كل شيء. النظام الجيد يحتاج أيضًا إلى حماية الصفحات الداخلية حتى لا يتمكن أي شخص غير مسجل من الوصول إليها.

حماية الصفحات باستخدام before_action

في كثير من التطبيقات، تريد أن تمنع الزائر غير المسجل من الوصول إلى صفحات معيّنة مثل لوحة التحكم أو صفحة الحساب. هنا نستخدم عادة دالة مثل current_user وrequire_login.

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  helper_method :current_user, :logged_in?

  def current_user
    @current_user ||= User.find_by(id: session[:user_id])
  end

  def logged_in?
    current_user.present?
  end

  def require_login
    redirect_to login_path, alert: "يجب تسجيل الدخول أولًا" unless logged_in?
  end
end

ثم نستخدمها داخل أي Controller يحتاج إلى حماية:

class DashboardController < ApplicationController
  before_action :require_login

  def index
  end
end

هذا الأسلوب أنيق جدًا لأنه يختصر عملية التحقق ويجعلها قابلة لإعادة الاستخدام. بدل أن تكرر شرط التحقق في كل دالة، تضع منطقًا مركزيًا واضحًا. وهذا يساعدك أيضًا عندما يكبر المشروع ويصبح فيه عشرات الصفحات المحمية.

تسجيل الخروج بشكل صحيح

تسجيل الخروج يجب أن يكون واضحًا وآمنًا. عندما ينقر المستخدم على زر الخروج، يجب أن يتم حذف الجلسة أو إبطالها فورًا. في مثالنا السابق استخدمنا:

session.delete(:user_id)

لكن أحيانًا تحتاج إلى أكثر من ذلك، خاصة إذا كنت تستخدم cookies آمنة أو tokens. المهم أن تتأكد من إلغاء كل شيء مرتبط بجلسة المستخدم الحالية. ولا تنسَ أن تسجيل الخروج ليس مجرد إخفاء اسم المستخدم من الواجهة، بل هو إنهاء فعلي لحالة الدخول.

يمكنك أيضًا إضافة زر خروج في الواجهة:

<% if logged_in? %>
  <%= button_to "تسجيل الخروج", logout_path, method: :delete %>
<% else %>
  <%= link_to "تسجيل الدخول", login_path %>
<% end %>

هذا يعطي تجربة لطيفة وواضحة للمستخدم، ويجعل الواجهة تتغير حسب الحالة.

تخزين كلمة المرور بطريقة آمنة

هذه من أهم النقاط في المقال كله، وربما أهم نقطة في أي نظام تسجيل دخول. لا تخزن كلمة المرور كما هي. لا ترسلها للواجهة مرة أخرى. لا تسجلها في logs. لا تكتبها في رسائل الخطأ. لا تضعها في أي مكان يمكن أن يراه أحد.

BCrypt في Ruby تقوم بإنشاء hash آمن لكلمة المرور، وعند المصادقة تقوم بالمقارنة مع القيمة المشفرة دون كشف النص الأصلي. مثال صغير يوضح الفكرة:

require 'bcrypt'

password = BCrypt::Password.create("my_secret_password")
puts password

الناتج سيكون شيئًا مشفّرًا مثل:

$2a$12$...

وعند التحقق:

hashed = BCrypt::Password.new(password)
puts hashed == "my_secret_password" # true

هذه هي الفكرة الأساسية. نحن لا نحتاج إلى معرفة كلمة المرور الأصلية بعد حفظها، بل نحتاج فقط إلى القدرة على التأكد من صحتها. وهذا بحد ذاته إنجاز أمني مهم.

التعامل مع رسائل الخطأ

الرسائل التي تظهر للمستخدم عند الفشل مهمة جدًا، لكنها يجب أن تكون ذكية. لا نريد أن نكشف الكثير. فمثلًا، قد يكون من الأفضل أن نقول: “البريد الإلكتروني أو كلمة المرور غير صحيحة” بدلًا من أن نقول: “البريد الإلكتروني موجود لكن كلمة المرور خاطئة”. لماذا؟ لأن الرسالة الثانية تساعد المهاجم على معرفة إن كان البريد الإلكتروني موجودًا في النظام أم لا، وهذا غير مرغوب فيه.

في المقابل، عند إنشاء الحساب، من المفيد أن نعرض أخطاء واضحة مثل:

<% if @user.errors.any? %>
  <div class="errors">
    <ul>
      <% @user.errors.full_messages.each do |message| %>
        <li><%= message %></li>
      <% end %>
    </ul>
  </div>
<% end %>

هكذا سيفهم المستخدم أن هناك مشكلة في اسم الحقل أو طول كلمة المرور أو صيغة البريد الإلكتروني. الوضوح هنا جزء من الأمان أيضًا، لأنه يقلل المحاولات العشوائية ويجعل الواجهة أكثر إنسانية.

إضافة تذكّرني Remember Me

في بعض التطبيقات، لا يريد المستخدم أن يسجل الدخول في كل مرة يغلق فيها المتصفح. هنا يمكن إضافة خيار “تذكرني” بحيث تبقى الجلسة لفترة أطول. لكن يجب التعامل مع هذه الميزة بحذر لأنها تزيد سطح المخاطر إذا لم تُطبّق جيدًا.

يمكن فعل ذلك باستخدام cookies آمنة أو tokens مخصصة. مثلًا:

if params[:remember_me] == "1"
  cookies.permanent.encrypted[:user_id] = user.id
else
  session[:user_id] = user.id
end

ومع ذلك، في التطبيقات الاحترافية يفضَّل استخدام token عشوائي قابل للإبطال بدل الاعتماد على معرف المستخدم فقط. لأن مجرد user_id في cookie، حتى لو كان مشفرًا، ليس دائمًا أفضل حل من ناحية الأمان. الفكرة هنا أن “تذكرني” ميزة مفيدة، لكنها تحتاج تصميمًا حذرًا جدًا.

استرجاع كلمة المرور

من أكثر الحالات شيوعًا أن ينسى المستخدم كلمة المرور. وبدل أن تضيع التجربة كلها، يجب أن توفر له مسارًا واضحًا لإعادة تعيينها. هذا المسار عادة يتكون من خطوات: يطلب المستخدم رابط إعادة التعيين، يرسل النظام رابطًا يحتوي على token آمن، يفتح المستخدم الرابط، يعيّن كلمة مرور جديدة، ثم يتم إبطال الرابط القديم.

يمكنك تخزين رمز إعادة التعيين ووقت انتهاء صلاحيته:

# migration
add_column :users, :reset_password_token, :string
add_column :users, :reset_password_sent_at, :datetime

ثم إنشاء token:

class User < ApplicationRecord
  def generate_reset_token
    update(
      reset_password_token: SecureRandom.hex(32),
      reset_password_sent_at: Time.current
    )
  end

  def reset_token_valid?
    reset_password_sent_at > 2.hours.ago
  end
end

وعند التحقق من الرابط:

user = User.find_by(reset_password_token: params[:token])

if user && user.reset_token_valid?
  # عرض النموذج الجديد
else
  redirect_to forgot_password_path, alert: "الرابط غير صالح أو منتهي الصلاحية"
end

من المهم ألا تجعل الرابط مفتوحًا إلى الأبد، لأن token غير المنتهي يصبح بابًا خطيرًا. كما ينبغي إبطال الرمز بعد نجاح إعادة التعيين مباشرة.

الصلاحيات Authorization بعد تسجيل الدخول

تسجيل الدخول يعني أنك تعرف من هو المستخدم. لكن هذا لا يعني أنه يملك كل شيء. هنا يأتي مفهوم الصلاحيات. مثلًا، هناك مستخدم عادي، وهناك مدير، وهناك مشرف. كل دور لديه صلاحيات مختلفة. من الأخطاء الشائعة أن تخلط بين authentication وauthorization. الأول يجيب عن سؤال: “من أنت؟” والثاني يجيب عن سؤال: “ماذا يسمح لك أن تفعل؟”

يمكنك إضافة حقل role إلى المستخدم:

add_column :users, :role, :string, default: "user"

ثم في الموديل:

class User < ApplicationRecord
  def admin?
    role == "admin"
  end
end

وفي الـ controller:

before_action :require_admin

def require_admin
  redirect_to root_path, alert: "ليس لديك صلاحية للوصول إلى هذه الصفحة" unless current_user&.admin?
end

هذه الطبقة الإضافية تجعل النظام أكثر نضجًا. كثير من التطبيقات تبدأ بتسجيل دخول بسيط ثم تكتشف لاحقًا أنها بحاجة إلى أدوار وصلاحيات، لذلك من الأفضل أن تفكر في هذا مبكرًا حتى لو لم تطبقه بالكامل من البداية.

تحسينات أمنية مهمة

إذا كنت تريد نظامًا جديرًا بالثقة، فهناك عدة أمور لا ينبغي أن تتجاهلها. أولًا، استخدم HTTPS دائمًا حتى لا تنتقل بيانات تسجيل الدخول بشكل مكشوف. ثانيًا، فعّل حماية CSRF في Rails. ثالثًا، لا تحتفظ بالجلسات لفترة أطول من اللازم. رابعًا، استخدم rate limiting أو حماية ضد المحاولات المتكررة إذا كان التطبيق حساسًا. خامسًا، لا تعرض تفاصيل داخلية في رسائل الأخطاء.

يمكنك أيضًا التفكير في دعم المصادقة الثنائية 2FA في التطبيقات الحساسة. هذا يضيف طبقة ثانية من الحماية حتى لو تسربت كلمة المرور. كما أن استخدام cookies مع httponly وsecure وsame_site يعد من الممارسات المهمة جدًا.

في إعدادات الجلسات، قد يكون من المفيد مثلًا:

# config/initializers/session_store.rb
Rails.application.config.session_store :cookie_store,
  key: '_my_app_session',
  secure: Rails.env.production?,
  same_site: :lax,
  httponly: true

هذه الإعدادات تساعد على تقليل بعض المخاطر المرتبطة بالجلسات والكوكيز. نعم، قد تبدو التفاصيل كثيرة، لكن كل تفصيلة هنا لها أثر حقيقي في الأمان.

اختبار نظام تسجيل الدخول

لا يكفي أن ينجح النظام في العمل يدويًا أثناء التطوير، بل يجب أن تختبره. الاختبار يمنحك ثقة ويكشف المشاكل قبل أن يصل التطبيق إلى المستخدمين. يمكنك كتابة اختبارات نموذج المستخدم واختبارات المصادقة.

مثال على اختبار موديل:

# test/models/user_test.rb
require "test_helper"

class UserTest < ActiveSupport::TestCase
  test "should be valid with valid attributes" do
    user = User.new(
      name: "Ali",
      email: "ali@example.com",
      password: "password123",
      password_confirmation: "password123"
    )

    assert user.valid?
  end

  test "should not be valid without email" do
    user = User.new(name: "Ali", password: "password123")
    assert_not user.valid?
  end
end

واختبار تسجيل الدخول:

# test/controllers/sessions_controller_test.rb
require "test_helper"

class SessionsControllerTest < ActionDispatch::IntegrationTest
  test "should log in with valid credentials" do
    user = User.create!(
      name: "Ali",
      email: "ali@example.com",
      password: "password123",
      password_confirmation: "password123"
    )

    post sessions_path, params: {
      email: "ali@example.com",
      password: "password123"
    }

    assert_redirected_to root_path
    assert_equal user.id, session[:user_id]
  end
end

الاختبارات ليست رفاهية. هي جزء من احترامك للمشروع وللمستقبل. لأن تسجيل الدخول جزء حساس، وأي خطأ فيه قد يسبب مشاكل حقيقية للمستخدمين.

بناء تجربة مستخدم جيدة حول تسجيل الدخول

في النهاية، النظام الأمني لا يجب أن يكون جافًا أو مخيفًا. المستخدم لا يريد أن يشعر أنه يتعامل مع آلة باردة. لذلك من المهم أن تراعي اللغة المستخدمة في الرسائل، وسلاسة التنقل، وبساطة النماذج، ووضوح الأزرار. على سبيل المثال، بدل “أدخل البيانات” استخدم “مرحبًا بك، سجّل دخولك للمتابعة”. وبدل “خطأ” فقط، استخدم رسالة توضح كيف يصلح المشكلة.

كما أن التصميم البصري يلعب دورًا مهمًا. الحقول يجب أن تكون واضحة، والمسافات مناسبة، وزر الإرسال بارزًا، ورسائل الخطأ سهلة القراءة. نظام تسجيل الدخول الناجح ليس فقط آمنًا، بل مريح أيضًا. أحيانًا يظن المطور أن الأمان يعني التعقيد، لكن الحقيقة أن أفضل الأنظمة هي التي تجمع بين الأمان والسهولة. وهذه معادلة جميلة جدًا إذا أحسنت تنفيذها.

مثال متكامل مبسط

لنجمع بعض الأجزاء معًا في صورة مبسطة جدًا حتى تتضح الفكرة الكاملة:

# app/models/user.rb
class User < ApplicationRecord
  has_secure_password

  validates :name, presence: true
  validates :email, presence: true, uniqueness: true
end

# app/controllers/registrations_controller.rb
class RegistrationsController < ApplicationController
  def new
    @user = User.new
  end

  def create
    @user = User.new(user_params)

    if @user.save
      session[:user_id] = @user.id
      redirect_to root_path, notice: "تم إنشاء الحساب"
    else
      render :new
    end
  end

  private

  def user_params
    params.require(:user).permit(:name, :email, :password, :password_confirmation)
  end
end

# app/controllers/sessions_controller.rb
class SessionsController < ApplicationController
  def new
  end

  def create
    user = User.find_by(email: params[:email])

    if user&.authenticate(params[:password])
      session[:user_id] = user.id
      redirect_to root_path, notice: "تم تسجيل الدخول"
    else
      flash.now[:alert] = "بيانات الدخول غير صحيحة"
      render :new
    end
  end

  def destroy
    session.delete(:user_id)
    redirect_to root_path, notice: "تم تسجيل الخروج"
  end
end

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  helper_method :current_user, :logged_in?

  def current_user
    @current_user ||= User.find_by(id: session[:user_id])
  end

  def logged_in?
    current_user.present?
  end
end

بهذا الهيكل الصغير لديك بالفعل أساس نظام تسجيل دخول عملي. ومن هنا يمكنك التوسع بإضافة الحماية، الأدوار، استرجاع كلمة المرور، وميزات أخرى بحسب طبيعة تطبيقك.

أخطاء شائعة يجب تجنبها

هناك أخطاء تتكرر كثيرًا عند بناء أنظمة تسجيل الدخول. من أبرزها تخزين كلمة المرور كنص، إهمال التحقق من البريد الإلكتروني، عدم توحيد صيغة البريد إلى lowercase، عرض رسائل خطأ تكشف معلومات حساسة، نسيان إلغاء الجلسة عند تسجيل الخروج، وعدم اختبار النظام بشكل كافٍ. وهناك خطأ آخر لا يقل أهمية: بناء نظام “يعمل” لكنه غير قابل للصيانة. قد ينجح اليوم، لكنه ينهار بعد أشهر عندما تبدأ في إضافة ميزات جديدة.

لذلك حاول دائمًا أن تكتب كودًا نظيفًا ومفهومًا. استخدم أسماء واضحة. افصل المنطق في أماكنه الصحيحة. لا تضع كل شيء في Controller واحد. ولا تتردد في استخدام المساعدات Helpers عندما تحتاجها. نظام تسجيل الدخول، أكثر من غيره، يحتاج إلى وضوح، لأن الخطأ فيه غالبًا لا يظهر إلا عندما يكون مؤلمًا.

الخلاصة

إنشاء نظام تسجيل دخول باستخدام Ruby ليس مجرد تمرين برمجي، بل هو درس كامل في بناء الثقة بين المستخدم والتطبيق. أنت هنا لا تكتب سطورًا متفرقة فقط، بل تؤسس نقطة دخول آمنة ومنظمة يمكن أن يعتمد عليها المشروع كله. عندما تفهم كيف تُخزن كلمات المرور بشكل صحيح، كيف تُنشأ الجلسات، كيف تُحمى الصفحات، كيف تُدار الصلاحيات، وكيف تُصمم تجربة مستخدم لطيفة، فأنت لا تصبح فقط مطورًا ينسخ الأكواد، بل مطورًا يفكر بمنهجية ويبني بحس احترافي.

وربما أجمل ما في Ruby أنها تساعدك على ذلك بأسلوب هادئ ومريح. اللغة لا تجعلك تغرق في التعقيد مبكرًا، بل تمنحك مساحة لتفهم ما يحدث فعلًا. وهذا مهم جدًا في موضوع مثل تسجيل الدخول، حيث تكون التفاصيل الصغيرة هي التي تصنع الفرق الكبير. ابدأ ببنية بسيطة، ثم أضف الأمان، ثم اختبر، ثم حسّن. ومع الوقت ستجد أن ما كان يبدو معقدًا في البداية أصبح مألوفًا وواضحًا.