عرض مصدر Rails/action controller overview

<noinclude>{{DISPLAYTITLE:نظرة خاطفة على وحدة التحكم في ريلز}}</noinclude>
[[تصنيف:Rails]]
[[تصنيف:Rails Controllers]]
ستتعرف في هذا الدليل على كيفية عمل وحدات التحكم (Controller) وكيفية ملاءمتها مع دورة الطلب (request cycle) في التطبيق الخاص بك.

بعد قراءة هذا الدليل، ستتعلم:
* كيفية اتباع تدفق الطلب من خلال وحدة تحكم.
* كيفية تقييد المعاملات التي مُرّرت إلى وحدة التحكم الخاصة بك.
* كيف ولماذا تخزَّن البيانات في الجلسة (session) أو ملفات تعريف الارتباط (cookies).
* كيفية العمل مع المرشحات (filters) لتنفيذ التعليمات البرمجية أثناء معالجة الطلب.
* كيفية استخدام استيثاق HTTP المضمن في وحدة التحكم.
* كيفية تدفق البيانات مباشرة إلى متصفح المستخدم.
* كيفية ترشيح المعاملات الحساسة بحيث لا تظهر في سجل التطبيق.
* كيفية التعامل مع الاستثناءات التي قد تنشأ أثناء معالجة الطلب.

== ما الذي تفعله وحدة التحكم؟ ==
وحدة التحكم Action Controller هي الحرف C في نمط التصميم MVC (اختصار للعبارة Model View Controller). بعد أن يحدِّد [[Rails/routing|جهاز التوجيه]] (router) أي وحدة تحكم تُستخدَم لطلب ما، تكون وحدة التحكم مسؤولة عن فهم الطلب وإنتاج الناتج المناسب.

لحسن الحظ، تقوم وحدة التحكم Action Controller بمعظم المهام الأساسية الخاصة بك ويستخدم المواثيق الذكية (smart conventions) لجعل هذا الأمر بسيطًا قدر الإمكان.

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

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

لمزيد من التفاصيل حول عملية التوجيه، راجع صفحة [[Rails/routing|التوجيه من الخارج إلى الداخل]].

== اتفاقية التسمية في وحدة التحكم ==
تفضل اتفاقية التسمية لوحدات التحكم في ريلز صيغة الجمع  للكلمة الأخيرة في اسم وحدة التحكم، على الرغم من أنه ليس مطلوبًا تمامًا (مثل <code>ApplicationController</code>).

على سبيل المثال، <code>ClientsController</code> أفضل من <code>ClientController</code> و <code>SiteAdminsController</code> أفضل من <code>SiteAdminController</code> أو <code>SitesAdminsController</code>، وهكذا دواليك.

تسمح لك اتباع هذه الاتفاقية باستخدام مولدات المسارات الافتراضية (مثل <code>resources</code> ...إلخ.) دون الحاجة إلى تأهيل كل من المسار <code>‎:path</code> أو وحدة التحكم <code>‎:controller</code>، وسيبقى استخدام العنوان URL ودوال المسار المساعدة مترابطًا في جميع أنحاء التطبيق الخاص بك.

راجع دليل [[Rails/layouts and rendering|التخطيطات والتصيير]] لمزيد من التفاصيل.

'''ملاحظة''': تختلف اتفاقية تسمية وحدة التحكم من اتفاقية تسمية النماذج، والتي من المتوقع أن تُسمّى بصيغة المفرد.

== التوابع والإجراءات ==
وحدة التحكم هي صنف من [[Ruby#.D8.A7.D9.84.D8.A3.D8.B5.D9.86.D8.A7.D9.81 .D9.88.D8.A7.D9.84.D9.88.D8.AD.D8.AF.D8.A7.D8.AA|أًصناف روبي]] ترث من <code>ApplicationController</code> ولها توابع مثل أي صنف آخر. عندما يتلقى تطبيقك طلبًا، سيحدد التوجيه وحدة التحكم والإجراء المطلوب تشغيله، ثم تنشئ ريلز نسخةً لوحدة التحكم هذه ويشغل التابع الذي يحمل نفس اسم الإجراء.<syntaxhighlight lang="rails">
class ClientsController < ApplicationController
  def new
  end
end
</syntaxhighlight>على سبيل المثال، إذا انتقل المستخدم إلى ‎/clients/new في تطبيقك، لإضافة عميل جديد، ستنشئ ريلز نسخةً من <code>ClientsController</code> وسيستدعي تابعًا جديدًا. لاحظ أن التابع الفارغ من المثال أعلاه سيعمل على ما يرام لأن ريلز افتراضيًا تقدم واجهة new.html.erb ما لم ينص الإجراء على خلاف ذلك. يمكن أن يتيح التابع الجديد واجهة متغير نسخة <code>client@</code> عن طريق إنشاء عميل جديد:<syntaxhighlight lang="rails">
def new
  @client = Client.new
end
</syntaxhighlight>يوضح دليل [[Rails/layouts and rendering|التخطيطات والتصيير]] هذا الأمر بمزيد من التفصيل.

يرث <code>ApplicationController</code> من <code>ActionController::Base</code>، الذي يحدد عددًا من التوابع المفيدة. سيغطي هذا الدليل بعضًا من هذه الأمور، ولكن إذا كنت مهتمًا برؤية ما هناك، فيمكنك الاطلاع عليها جميعًا في توثيق واجهة برمجة التطبيقات عبر [http://api.rubyonrails.org/v5.2.2/classes/ActionController.html هذا] الرابط.

فقط التوابع العامة هي قابلة للاستدعاء كإجراء. من أفضل الممارسات تقليل رؤية التوابع (مع الخصوصية أو الحماية) التي لا يُقصَد بها أن تكون إجراءات، مثل التوابع المساعدة أو المرشحات.

== المعاملات ==
ربما تريد الوصول إلى البيانات المرسلة بواسطة المستخدم أو المعاملات الأخرى في وحدة التحكم الخاصة بك. هناك نوعان من المعاملات الممكنة في تطبيق الويب: الأولى هي المعاملات التي ترسل كجزء من عنوان URL، وتسمى معاملات سلسلة الاستعلام. سلسلة الاستعلام هي كل شيء بعد الرمز "?" في عنوان URL. عادة ما يشار إلى النوع الثاني من المعاملات ببيانات POST.

عادةً ما تأتي هذه المعلومات من نموذج HTML ملئ بواسطة المستخدم. يطلق عليها بيانات POST لأنه لا يمكن إرسالها إلا كجزء من طلب HTTP POST. لا تميز ريلز بين معاملات سلسلة الاستعلام ومعاملات POST، وكلاهما متاح في <code>params</code> التي من النوع <code>[[Ruby/Hash|Hash]]</code> في وحدة التحكم الخاصة بك:<syntaxhighlight lang="rails">

class ClientsController < ApplicationController
  # HTTP GET يستخدم هذا الإجراء معاملات سلسلة الاستعلام لأنه يشغل بواسطة طلب 
  # ولكن هذا لا يحدث أي فرق في الطريقة التي يصل بها إلى المعاملات. سيبدو 
  # لهذا الإجراء على هذا النحو من أجل قائمة العملاء المفعلة URL عنوان
  # /clients?status=activated
  def index
    if params[:status] == "activated"
      @clients = Client.activated
    else
      @clients = Client.inactivated
    end
  end
 
  # HTML هي على الأغلب قادمة من نموذج .POST يستخدم هذا الإجراء معاملات
  # "/clients" هو RESTful لطلب URL الذي أرسله المستخدم. سيكون عنوان 
  # الطلب (body) وترسل البيانات كجزء من نص 

  def create
    @client = Client.new(params[:client])
    if @client.save
      redirect_to @client
    else
      # يستبدل هذا السطر سلوك التصيير الافتراضي، والذي كان من شأنه 
      # "create" تصيير الواجهة
      render "new"
    end
  end
end
</syntaxhighlight>

=== المعاملات ذات النوع <code>[[Ruby/Array|Array]]</code> و <code>[[Ruby/Hash|Hash]]</code> ===
لا تقتصر المعاملات <code>params</code> ذات النوع <code>[[Ruby/Hash|Hash]]</code> على مفاتيح وقيم أحادية البعد. يمكن أن تحتوي على مصفوفات وجداول <code>[[Ruby/Hash|Hash]]</code> متداخلة. لإرسال مجموعة من القيم، ألحق زوجًا فارغًا من الأقواس المعقوفة "<code>[]</code>" باسم المفتاح:<syntaxhighlight lang="http">
GET /clients?ids[]=1&ids[]=2&ids[]=3
</syntaxhighlight>'''ملاحظة''': يشفر عنوان URL الفعلي في هذا المثال على أنه<code>"‎/clients?ids%5b%5d=1&ids%5b%5d=2&ids%5b%5d=3"</code> لأن المحرف "[" و "]" غير مسموح به في عناوين URL. في معظم الأوقات، لا داعي للقلق حيال ذلك لأنَّ المتصفح يرمزها لك، وتفك ريلز ترميزها تلقائيًا؛ ولكن، إذا وجدت نفسك مضطرًّا لإرسال تلك الطلبات إلى الخادم يدويًا، يجب أن تضع ذلك بالحسبان.

ستكون قيمة <code>[params[:ids</code> الآن <code>["1" ، "2" ، "3"]</code>. لاحظ أن قيم المعاملات هي دائما سلاسل نصيّة؛ لا تحاول ريلز تخمين أو  تحويل النوع.

'''ملاحظة''': تستبدل القيم مثل <code>[nil]</code> أو <code>[nil, nil, ...‎]</code> في <code>params</code> بالقوسين المعقوفين <code>[]</code> لأسباب أمنية بشكل افتراضي. انظر دليل [[Rails/security|الأمن]] لمزيد من المعلومات.

لإرسال قيمة من النوع hash، عليك تضمين اسم المفتاح داخل الأقواس:<syntaxhighlight lang="html">
<form accept-charset="UTF-8" action="/clients" method="post">
  <input type="text" name="client[name]" value="Acme" />
  <input type="text" name="client[phone]" value="12345" />
  <input type="text" name="client[address][postcode]" value="12345" />
  <input type="text" name="client[address][city]" value="Carrot City" />
</form>
</syntaxhighlight>عند إرسال هذا النموذج، ستكون قيمة المعاملات <code>[‎:client]</code> هي:<syntaxhighlight lang="text">
{ "name" => "Acme", "phone" => "12345", "address" => { "postcode" => "12345", "city" => "Carrot City"‎ } }
</syntaxhighlight>لاحظ التجزئة المتداخلة في المعاملات <code>[‎:client][:address]</code>.

يعمل الكائن <code>params</code> مثل <code>Hash</code> ، ولكن يتيح لك استخدام الرموز والسلاسل النصية بالتبادل كمفاتيح.

=== معاملات JSON ===
إذا كنت تكتب تطبيقًا لخدمة ويب، فقد تجد نفسك أكثر راحة في قبول المعاملات بتنسيق JSON. إذا تعين ترويسة الطلب "Content-Type" من طلبك إلى "application/json"، تحمّل ريلز تلقائيًا المعاملات في <code>params</code> من النوع <code>[[Ruby/Hash|Hash]]</code>، والتي يمكنك الوصول إليها كما تفعل عادةً.

على سبيل المثال، إذا كنت ترسل محتوى JSON التالي:<syntaxhighlight lang="json">
{ "company": { "name": "acme", "address": "123 Carrot Street" } }
</syntaxhighlight>ستتلقى وحدة التحكم الخاصة بك <code>[params[:company</code> بالشكل <code>{ "name" => "acme", "address" => "123 Carrot Street"‎}</code>.

أيضًا، إذا شغلت <code>config.wrap_parameters</code> في مُهيئك (initializer) أو استدعيت <code>wrap_parameters</code> في وحدة التحكم الخاصة بك، فيمكنك بأمان حذف العنصر الجذر (‎(root <code>element</code> في المعامل <code>JSON</code>. في هذه الحالة، ستستنسخ المعاملات وتغلف بمفتاح يحدد استنادًا إلى اسم وحدة التحكم الخاصة بك. لذلك يمكن كتابة طلب JSON أعلاه على النحو التالي:<syntaxhighlight lang="json">
{ "name": "acme", "address": "123 Carrot Street" }
</syntaxhighlight>وبافتراض أنك ترسل البيانات إلى <code>CorporateController</code>، فستغلف في المفتاح ‎:<code>company</code> كما يلي:<syntaxhighlight lang="json">
{ name: "acme", address: "123 Carrot Street", company: { name: "acme", address: "123 Carrot Street" } }
</syntaxhighlight>يمكنك تخصيص اسم المفتاح أو معاملات معينة تريد تغليفها عن طريق الاطلاع على [http://api.rubyonrails.org/v5.2.2/classes/ActionController/ParamsWrapper.html توثيق الواجهة البرمجية].

'''ملاحظة''': استُخرِج دعم تحليل معاملات XML في جوهرة (gem) تسمى <code>actionpack-xml_parser</code>.

=== معاملات التوجيه ===
تحتوي المعاملات <code>params</code> التي من النوع <code>[[Ruby/Hash|Hash]]</code> دومًا على مفاتيح وحدة التحكم ‎:<code>controller</code> والإجراء <code>‎:action</code>، ولكن يجب استخدام التابعين <code>control_name</code> و <code>action_name</code> بدلًا من ذلك للوصول إلى هذه القيم. أي معاملات أخرى يحددها التوجيه، مثل <code>‎:id</code> ستكون متوفرة أيضًا. على سبيل المثال، ضع في اعتبارك قائمة العملاء حيث يمكن أن تعرض القائمة عملاء نشطين أو غير نشطين. يمكننا إضافة مسار يلتقط معامل الحالة <code>‎:status</code> في عنوان ‎‎"pretty" URL:<syntaxhighlight lang="rails">
get '/clients/:status' => 'clients#index', foo: 'bar'
</syntaxhighlight>في هذه الحالة، عندما يفتح المستخدم العنوان URL/clients/active، سيتم تعيين المعاملات <code>[‎:status]</code> إلى "نشط" (active). عند استخدام هذا المسار، سيعين أيضًا المعاملات <code>[‎:foo]</code> إلى "bar"، كما لو مررت في سلسلة الاستعلام. ستتلقى وحدة التحكم أيضًا <code>[params[:action</code> بالشكل "index" و <code>[params[:controller</code> بالشكل "clients".

=== التابع <code>default_url_options</code> ===
يمكنك تعيين المعاملات الافتراضية العامة لإنشاء عنوان URL من خلال تحديد تابع يسمى <code>default_url_options</code> في وحدة التحكم الخاصة بك. يجب أن يعيد هذا التابع [[Ruby/Hash|جدول hash]] مع الإعدادات الافتراضية المطلوبة، والتي يجب أن تكون مفاتيحها رموزًا بالشكل التالي:<syntaxhighlight lang="rails">
class ApplicationController < ActionController::Base
  def default_url_options
    { locale: I18n.locale }
  end
end
</syntaxhighlight>تستخدم هذه الخيارات كنقطة بداية عند إنشاء عناوين URL، لذلك من الممكن أن تتجاوز من خلال الخيارات التي مُرِّرت إلى <code>url_for</code> للمكالمات.

إذا قمت بتعريف <code>default_url_options</code> في <code>ApplicationController</code>، كما هو موضح في المثال أعلاه، فستُستخدَم هذه الإعدادات الافتراضية لجميع عمليات إنشاء عناوين URL. يمكن تعريف الطريقة أيضًا في وحدة تحكم معينة، وفي هذه الحالة لا تؤثر سوى على عناوين URL التي أنشئت هناك.

في طلب معين معطى، لا يُستدعَى التابع فعليًا لكل عنوان URL أُنشِئ؛ لأسباب الأداء، يخزَّن [[Ruby/Hash|الجدول hash]] المعاد في ذاكرة التخزين المؤقتة الداخلية، إذ يوجد استدعاء واحد على الأكثر لكل طلب.

=== المعاملات القوية ===
مع استخدام المعاملات القوية (strong parameters)، يُحظَر استخدام معاملات وحدة التحكم في التعيينات الشاملة للنموذج النشط حتى تدرج في القائمة البيضاء. وهذا يعني أنه سيتعين عليك اتخاذ قرار واعي بشأن الخاصيات (attributes) التي تسمح بإجراء التحديث الشامل. هذه ممارسة أمان أفضل للمساعدة في منع المستخدمين عن طريق الخطأ من تحديث سمات الطرازات الحساسة.

بالإضافة إلى ذلك، يمكن وضع علامة على المعاملات على النحو المطلوب، وستتدفق من خلال تدفق اطلاق/إنقاذ (raise/rescue) محدَّد مسبقًا، مما يؤدي إلى إعادة الخطأ 400 للطلب إذا لم تمرر جميع المعاملات المطلوبة.<syntaxhighlight lang="rails">
class PeopleController < ActionController::Base
  # ActiveModel::ForbiddenAttributesError سيؤدي هذا إلى اطلاق الاستثناء  
  # نظرًا لأنه يستخدم تعيينًا شامًلا بدون خطوة تصريح صريحة.
  def create
    Person.create(params[:person])
  end
 
  # person طالما هناك المفتاح (flying colors) سوف يمر هذا مع الألوان الطائرة 
  # ActionController::ParameterMissing في المعاملات، وإلا فإنه سيطلق الاستثناء 
  # ويحول إلى الخطأ 400 في ActionController::Base، والذي سيقبض عليه من قبل
  # .الطلب
  def update
    person = current_account.people.find(params[:id])
    person.update!(person_params)
    redirect_to person
  end
 
  private
    # لتغليف المعاملات المسموح بها هو مجرد نموذج private إن استخدام التابع
    # جيد حيث ستتمكن من إعادة استخدام نفس قائمة التصاريح بين الإنشاء
    # والتحديث. يمكنك تخصيص هذه الطريقة مع التحقق من كل مستخدم للخاصيات
    # .المسموح بها
    def person_params
      params.require(:person).permit(:name, :age)
    end
end
</syntaxhighlight>

==== القيم العددية المسموح بها ====
إن اعطاء<syntaxhighlight lang="rails">
params.permit(:id)
</syntaxhighlight>المفتاح <code>‎:id</code> سيمرر القائمة البيضاء إذا ظهرت في المعاملات وكان لها قيمة قياسية مسموح بها. خلاف ذلك، سيرشح المفتاح، لذلك لا يمكن حقن المصفوفات أو القيم hash أو أي كائنات أخرى.

الأنواع القياسية المسموح بها هي <code>[[Ruby/String|String]]</code> و <code>[[Ruby/Symbol|Symbol]]</code> و <code>[[Ruby/NilClass|NilClass]]</code> و <code>[[Ruby/Numeric|Numeric]]</code> و <code>[[Ruby/TrueClass|TrueClass]]</code> و <code>[[Ruby/FalseClass|FalseClass]]</code> و <code>Date</code> و <code>[[Ruby/Time|Time]]</code> و <code>DateTime</code> و <code>StringIO</code> و <code>[[Ruby/IO|IO]]</code> و <code>ActionDispatch::Http::UploadedFile</code> و <code>Rack::Test::UploadedFile</code>.

لتوضيح أن القيمة في <code>params</code> يجب أن تكون مصفوفة من القيم العددية المسموح بها، قم بتعيين المفتاح إلى مصفوفة فارغة:<syntaxhighlight lang="rails">
params.permit(id: [])
</syntaxhighlight>في بعض الأحيان، لا يكون من الممكن أو الملائم الإعلان عن المفاتيح الصالحة لمعامل hash أو هيكلها الداخلي. ما عليك سوى التعيين إلى جدول hash فارغ:<syntaxhighlight lang="rails">
params.permit(preferences: {})
</syntaxhighlight>لكن كن حذرًا لأن هذا يفتح الباب أمام الإدخال التعسفي. في هذه الحالة، يضمن التصريح أن القيم في البنية المعادة مسموح بها كإصلاحات ومرشحات من أي شيء آخر.

لإدراج كل محتوى جدول hash من المعاملات إلى القائمة البيضاء، يمكن استخدام التابع <code>permit!</code>‎ على النحو التالي:<syntaxhighlight lang="rails">
params.require(:log_entry).permit!

</syntaxhighlight>تدل <code>‎:log_entry</code> على معاملات hash وأية hash فرعية لها كما هو مسموح به ولا يتحقق من القياسات (scalars) المسموح بها، إذ يقبل أي شيء. يجب توخي الحذر الشديد عند استخدام <code>permit!‎</code>، حيث أنه سيسمح بتعيين شامل لجميع خصائص النموذج الحالية والمستقبلية.

==== المعاملات المتداخلة ====
يمكنك أيضًا استخدام التابع <code>permit</code> على المعاملات المتداخلة، مثل:<syntaxhighlight lang="rails">
params.permit(:name, { emails: [] },
              friends: [ :name,
                         { family: [ :name ], hobbies: [] }])
</syntaxhighlight>يضيف هذا الإعلان إلى القائمة خاصيات الاسم (name) والبريد الإلكتروني (emails) والأصدقاء (friends) ...إلخ. من المتوقع أن تكون عناوين البريد الإلكتروني عبارة عن مصفوفة من القيم العددية المسموح بها، وأن يكون الأصدقاء مصفوفة من الموارد ذات خاصيات (attributes) محددة، إذ يجب أن يكون لها الخاصية <code>name</code> (أية قيم قياسية مسموح بها)، والخاصية <code>hobbies</code> كمصفوفة من القيم العددية المسموح بها، والخاصية <code>family</code> التي تقتصر على وجود اسم (أي القيم العددية المسموح بها يمكن استعمالها هنا أيضًا).

==== مزيد من الأمثلة ====
قد ترغب أيضًا في استخدام الخاصيات المسموح بها في الإجراء الجديد. هذا يثير المشكلة التي لا يمكنك استخدام <code>require</code> على مفتاح الجذر لأنه، عادةً، لا وجود لها عند استدعاء <code>new</code>:<syntaxhighlight lang="rails">
# يمكنك توفير قيمة افتراضية واستخدام معاملات ،`fetch` باستخدام
# واجهة برمجية قوية من هناك
params.fetch(:blog, {}).permit(:title, :author)


</syntaxhighlight>يسمح لك تابع صنف النموذج <code>accepts_nested_attributes_for</code> بتحديث السجلات المرتبطة وتدميرها. يعتمد هذا على المعاملات <code>id</code> و ‎_destroy:<syntaxhighlight lang="rails">
# permit :id and :_destroy
params.require(:author).permit(:name, books_attributes: [:title, :id, :_destroy])
</syntaxhighlight>تُعامَل الكائنات <code>[[Ruby/Hash|Hash]]</code> التي مفاتيحها هي أعداد صحيحة بشكل مختلف، ويمكنك الإعلان عن الخاصيات كما لو كانت أبناءً مباشرين. يمكنك الحصول على هذه الأنواع من المعاملات عند استخدامك <code>accepts_nested_attributes_for</code> بالاقتران مع <code>has_many</code> المقابل:<syntaxhighlight lang="rails">
# :لإضافة البيانات التالية إلى القائمة البيضاء
# {"book" => {"title" => "Some Book",
#             "chapters_attributes" => { "1" => {"title" => "First Chapter"},
#                                        "2" => {"title" => "Second Chapter"}}}}
 
params.require(:book).permit(:title, chapters_attributes: [:title])
</syntaxhighlight>

==== خارج نطاق المعاملات القوية ====
صُمِّمت واجهة برمجة التطبيقات (API) للمعامل القوي مع أخذ حالات الاستخدام الأكثر شيوعًا في الحسبان. لا يقصد به العصا السحرية التي تعالج جميع مشاكل القائمة البيضاء. ومع ذلك، يمكنك بسهولة خلط الواجهة البرمجية مع التعليمات البرمجية الخاصة بك للتكيف مع الموقف الخاص بك.

تخيل السيناريو التالي: لديك معاملات تمثل اسم منتج و<nowiki/>[[Ruby/Hash|جدول hash]] من البيانات التعسفية المرتبطة بهذا المنتج، وتريد إدراج خاصية اسم المنتج في القائمة البيضاء وكذلك تجزئة البيانات بالكامل. لا تسمح لك واجهة برمجة التطبيقات للمعاملات القوية بإدراج كل التجزئة المتداخلة في القائمة البيضاء بأية مفاتيح مباشرة، ولكن يمكنك استخدام مفاتيح التجزئة المتشعبة (nested hash) لتوضيح ما ترغب في إضافته إلى القائمة البيضاء:<syntaxhighlight lang="rails">
def product_params
  params.require(:product).permit(:name, data: params[:product][:data].try(:keys))
end
</syntaxhighlight>

== الجلسة ==
يحتوي تطبيقك على جلسة (Session) لكل مستخدم حيث يمكنك تخزين كميات صغيرة من البيانات التي ستستمر بين الطلبات. لا تتوفر الجلسة إلا في وحدة التحكم والملف الشخصي ويمكن استخدام إحدى آليات التخزين المختلفة التالية:
* <code>ActionDispatch::Session::CookieStore</code> - يخزن كل شيء عند العميل.
* <code>ActionDispatch::Session::CacheStore</code> - تخزن البيانات في ذاكرة ريلز للتخزين المؤقت.
* <code>ActionDispatch::Session::ActiveRecordStore</code> - تخزن البيانات في قاعدة بيانات باستخدام [[Rails/active record|Active Record]]. هذا يتطلب الجوهرة <code>activerecord-session_store</code>.
* <code>ActionDispatch::Session::MemCacheStore</code> - تخزن البيانات في كتلة <code>memcached</code> (هذا تنفيذ قديم؛ يجب مراعاة استخدام <code>CacheStore</code> بدلًا من ذلك).
تستخدم جميع مخازن جلسات العمل ملف تعريف الارتباط (cookie) لتخزين معرف فريد لكل جلسة (يجب عليك استخدام ملف تعريف الارتباط، ولن تسمح لك ريلز بتمرير معرف الجلسة في عنوان URL لأن هذا أقل أمانًا).

بالنسبة إلى معظم المخازن، يُستخدَم هذا المعرّف ID  للبحث عن بيانات الجلسة على الخادم، على سبيل المثال، في جدول قاعدة البيانات. يوجد استثناء واحد، وهو مخزن الجلسة الافتراضي والموصى به - مخزن ملفات تعريف الارتباط <code>CookieStore</code> - الذي يخزن كافة بيانات جلسة العمل في ملف تعريف الارتباط نفسه (لا يزال المعرف ID متاحًا لك إذا كنت بحاجة إليه). هذا يتميز بكونه خفيف الحجم للغاية ويتطلب إعدادًا صفريًّا (zero setup) في تطبيق جديد من أجل استخدام الجلسة. توقَّع بيانات ملفات تعريف الارتباط لجعلها غير قابلة للتلاعب. كما  تشفر بحيث لا يستطيع أي شخص لديه حق الوصول إليها لقراءة محتوياتها. (لن تقبلها ريلز إذا عُدِّلَت).

يمكن باستعمال الآلية <code>CookieStore</code> تخزين حوالي 4 كيلوبايت من البيانات - أقل بكثير من البيانات الأخرى - ولكن هذا عادةً ما يكون كافيًا. لا تخزن كميات كبيرة من البيانات في الجلسة بغض النظر عن آلية تخزين الجلسة التي يستخدمها تطبيقك. يجب تجنب تخزين الكائنات المعقدة (أي شيء آخر غير كائنات [[Ruby|روبي]] الأساسية، إذ يعدُّ المثال الأكثر شيوعًا هو النماذج) في الجلسة، حيث قد يتعذر على الخادم إعادة تجميعها بين الطلبات، مما يؤدي إلى حدوث خطأ.

إذا لم تخزن جلسات المستخدم الخاصة بك البيانات المهمة أو لا تحتاج إلى أن تكون موجودة لفترات طويلة (على سبيل المثال إذا كنت تستخدم الفلاش [flash] فقط للمراسلة)، فيمكنك استخدام <code>ActionDispatch::Session::CacheStore</code>. سيخزن ذلك الجلسات باستخدام تطبيق ذاكرة التخزين المؤقت الذي قمت بتكوينه للتطبيق الخاص بك. وتتمثل ميزة ذلك في أنه يمكنك استخدام البنية الأساسية المؤقتة الموجودة لديك لتخزين الجلسات دون الحاجة إلى أي إعداد إضافي أو إدارة إضافية. الجانب السلبي، بالطبع، هو أن الجلسات ستكون سريعة الزوال ويمكن أن تختفي في أي وقت.

اقرأ المزيد حول تخزين الجلسة في [[Rails/security|دليل الأمان]].

إذا كنت بحاجة إلى آلية تخزين جلسة عمل مختلفة، فيمكنك تغييرها في المُهيئ (initializer):<syntaxhighlight lang="rails">
# استخدم قاعدة البيانات للجلسات بدلًا من الإعداد الافتراضي الذي يعتمد على 
# ملف تعريف الارتباط، والذي لا ينبغي استخدامه لتخزين معلومات سرية للغاية
# ("rails g active_record: session_migration" أنشئ جدول الجلسة باستخدام)
Rails.application.config.session_store :active_record_store


</syntaxhighlight>تقوم ريلز بإعداد مفتاح الجلسة (اسم ملف تعريف الارتباط) عند توقيع بيانات الجلسة. يمكن أيضًا تغيير هذه في المُهيئ:<syntaxhighlight lang="rails">
# تأكد من إعادة تشغيل الخادم الخاص بك عند تعديل هذا الملف.
Rails.application.config.session_store: cookie_store، key: '_your_app_session'


</syntaxhighlight>يمكنك أيضًا تمرير المفتاح <code>domain:</code> وتحديد اسم النطاق لملف تعريف الارتباط:<syntaxhighlight lang="rails">
# تأكد من إعادة تشغيل الخادم الخاص بك عند تعديل هذا الملف.
Rails.application.config.session_store :cookie_store, key: '_your_app_session', domain: ".example.com"

</syntaxhighlight>إعداد ريلز (من أجل <code>CookieStore</code>) وهو مفتاح سري يستخدم لتوقيع بيانات الجلسة في ‎config/credentials.yml.enc. هذا يمكن تغييره مع <code>bin/rails credentials:edit</code>.<syntaxhighlight lang="rails">
# aws:
#   access_key_id: 123
#   secret_access_key: 345

# في ريلز، بما في ذلك الواحد الذي MessageVerifiers يستخدم كأساس لجميع   
# يحمي ملفات تعريف الارتباط
secret_key_base: 492f...
</syntaxhighlight>'''ملاحظة''': سيؤدي تغيير <code>secret_key_base</code> عند استخدام <code>CookieStore</code> إلى إبطال جميع جلسات العمل الموجودة.

=== الوصول إلى الجلسة ===
في وحدة التحكم الخاصة بك، يمكنك الوصول إلى الجلسة من خلال نسخة التابع <code>session</code>.

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

تخزن قيم الجلسة باستخدام الأزواج مفتاح/قيمة مثل جدول hash:<syntaxhighlight lang="rails">
class ApplicationController < ActionController::Base
 
  private

  # :current_user_id المخزن في الجلسة مع المفتاح ID البحث عن المستخدم بالمعرف  
  # هذه طريقة شائعة للتعامل مع تسجيل دخول المستخدم في تطبيق ريلز؛ تسجيل 
  # الدخول يحدد قيمة الجلسة وتسجيل الخروج يزيلها
  def current_user
    @_current_user ||= session[:current_user_id] &&
      User.find_by(id: session[:current_user_id])
  end
end


</syntaxhighlight>لتخزين شيء ما في الجلسة، ما عليك سوى تعيينه إلى المفتاح مثل جدول hash:<syntaxhighlight lang="rails">
class LoginsController < ApplicationController

  # هو تسجيل الدخول والذي يعرف بتسجيل دخول المستخدم "Create" إن
  def create
    if user = User.authenticate(params[:username], params[:password])
     # احفظ مُعرِّف المستخدم في الجلسة حتى يمكن استخدامه في الطلبات اللاحقة
     session[:current_user_id] = user.id
     redirect_to root_url
   end
 end
end
</syntaxhighlight>لإزالة شيء ما من الجلسة، عيّن هذا المفتاح ليكون <code>nil</code>:<syntaxhighlight lang="rails">
class LoginsController < ApplicationController
 # هو حذف تسجيل الدخول والذي يعرف بتسجيل خروج المستخدم "Delete" إن
 def destroy
   # قم بإزالة معرِّف المستخدم من الجلسة
   @_current_user = session[:current_user_id] = nil
   redirect_to root_url
 end
end
</syntaxhighlight>لإعادة تعيين الجلسة بالكامل، استخدم <code>reset_session</code>.

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

يتم الوصول إليه بنفس الطريقة مثل الجلسة، مثل hash (إنه نسخة من <code>[http://api.rubyonrails.org/v5.2.2/classes/ActionDispatch/Flash/FlashHash.html FlashHash]</code>).

لنستخدم فعل تسجيل الخروج كمثال. تستطيع وحدة التحكم إرسال رسالة تعرض على المستخدم عند الطلب التالي:<syntaxhighlight lang="rails">
class LoginsController < ApplicationController
  def destroy
    session[:current_user_id] = nil
    flash[:notice] = "You have successfully logged out."
    redirect_to root_url
  end
end
</syntaxhighlight>لاحظ أنه من الممكن أيضًا تعيين رسالة flash كجزء من إعادة التوجيه. يمكنك تعيين <code>‎:notice</code>، أو <code>‎:alert</code> أو <code>‎:flash</code> ذي الغرض العام:<syntaxhighlight lang="rails">
redirect_to root_url, notice: "You have successfully logged out."
redirect_to root_url, alert: "You're stuck here!"
redirect_to root_url, flash: { referral_code: 1234 }
</syntaxhighlight>يعيد الإجراء <code>destroy</code> التوجيه إلى <code>root_url</code> للتطبيق، حيث تعرض الرسالة. لاحظ أن الأمر متروك تمامًا للإجراء التالي لتحديد، إذا كان هناك أي شيء، ما إذا كان سينفَّذ الإجراء السابق في flash. من المعتاد عرض أي تنبيهات خطأ أو إشعارات من flash في تخطيط التطبيق:<syntaxhighlight lang="html">
<html>
  <!-- <head/> -->
  <body>
    <% flash.each do |name, msg| -%>
      <%= content_tag :div, msg, class: name %>
    <% end -%>
 
    <!-- more content -->
  </body>
</html>
</syntaxhighlight>بهذه الطريقة، إذا قام أحد الإجراءات بإعداد إشعار أو رسالة تنبيه، فسيعرضه المخطط تلقائيًا.

يمكنك تمرير أي شيء يمكن أن تخزنه الجلسة؛ لا تقتصر على الإشعارات والتنبيهات:<syntaxhighlight lang="rails">
<% if flash[:just_signed_up] %>
  <p class="welcome">Welcome to our site!</p>
<% end %>
</syntaxhighlight>إذا كنت تريد نقل قيمة flash إلى طلب آخر، فاستخدم طريقة الاحتفاظ:<syntaxhighlight lang="rails">
class MainController < ApplicationController

  # ولكنك ترغب في إعادة توجيه جميع root_url لنفترض أن هذا الإجراء يتوافق مع 
  # flash إذا قام أحد الإجراءات بتعيين .UsersController#index الطلبات هنا إلى
  # وإعادة التوجيه هنا، فستُفقَد القيم عادة عند حدوث عملية إعادة توجيه أخرى
  # لجعلها تستمر لطلب آخر "keep" ولكن يمكنك استخدام
  def index
    # flash سوف تستمر كل قيم .
    flash.keep

    # يمكنك أيضًا استخدام مفتاح للاحتفاظ بنوع معين من القيمة فقط
    # flash.keep(:notice)
    redirect_to users_url
  end
end


</syntaxhighlight>

==== <code>Flash.now</code> ====
بشكل افتراضي، ستؤدي إضافة قيم إلى Flash إلى جعلها متاحة للطلب التالي، ولكن في بعض الأحيان قد ترغب في الوصول إلى هذه القيم في نفس الطلب. على سبيل المثال، إذا فشل إجراء الإنشاء <code>create</code> في حفظ المصدر وقمت بعرض القالب الجديد <code>new</code> مباشرةً، فلن يؤدي ذلك إلى طلب جديد، ولكن قد لا تزال ترغب في عرض الرسالة باستخدام flash. للقيام بذلك، يمكنك استخدام <code>flash.now</code> بنفس طريقة استخدام flash العادي:<syntaxhighlight lang="rails">
class ClientsController < ApplicationController
  def create
    @client = Client.new(params[:client])
    if @client.save
      # ...
    else
      flash.now[:error] = "Could not save client"
      render action: "new"
    end
  end
end
</syntaxhighlight>

== ملفات تعريف الارتباط (Cookies) ==
يمكن للتطبيق تخزين كميات صغيرة من البيانات على متصفح العميل - تسمى ملفات تعريف الارتباط cookies (أو الكعكات)- والتي ستستمر عبر الطلبات وحتى الجلسات. توفر ريلز وصولًا سهلًا إلى ملفات تعريف الارتباط عبر التابع <code>cookies</code>، والذي - تمامًا مثل الجلسة (session) - يعمل مثل الجدول hash:<syntaxhighlight lang="rails">

class CommentsController < ApplicationController
  def new
    # الملء التلقائي لاسم المعلق إذا كان قد تم تخزينه في ملف تعريف ارتباط
    @comment = Comment.new(author: cookies[:commenter_name])
  end
 
  def create
    @comment = Comment.new(params[:comment])
    if @comment.save
      flash[:notice] = "Thanks for your comment!"
      if params[:remember_name]
        # تذكر اسم صاحب التعليق
        cookies[:commenter_name] = @comment.author
      else
        # حذف ملف تعريف الارتباط لملف تعريف الارتباط الخاص بصاحب التعليق ، إن وجد.
        cookies.delete(:commenter_name)
      end
      redirect_to @comment.article
    else
      render action: "new"
    end
  end
end


</syntaxhighlight>لاحظ حينما تقوم بتعيين المفتاح إلى القيمة <code>nil</code> لقيم الجلسة، يجب عليك لحذف قيمة ملف تعريف ارتباط استخدام <code>(cookies.delete(:key</code>.

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

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

يمكنك تحديد برنامج التسلسل الذي يجب استخدامه:<syntaxhighlight lang="rails">
Rails.application.config.action_dispatch.cookies_serializer = :json
</syntaxhighlight>التسلسل الافتراضي للتطبيقات الجديدة هو <code>‎:json</code>. للتوافق مع التطبيقات القديمة مع ملفات تعريف الارتباط الموجودة، يُستخدَم <code>‎:marshal</code> عند عدم تحديد خيار التسلسل.

يمكنك أيضًا تعيين هذا الخيار إلى <code>‎:hybrid</code>، في هذه الحالة تعمل ريلز على إلغاء تسلسل ملفات تعريف الارتباط الموجودة (Marshal-serialized) بشفافية عند القراءة وإعادة كتابتها بتنسيق JSON. وهذا مفيد لترحيل التطبيقات الحالية إلى مُسلسِل (json (serializer:.

من الممكن أيضًا تمرير مُسلسِل (serializer) مخصص يستجيب للتحميل (load) والتفريغ (dump):<syntaxhighlight lang="rails">
Rails.application.config.action_dispatch.cookies_serializer = MyCustomSerializer
</syntaxhighlight>عند استخدام مسلسل <code>‎:json</code> أو <code>‎:hybrid</code>، يجب الحذر من أنه لا يمكن إجراء تسلسل لكافة كائنات روبي بالصيغة JSON. على سبيل المثال، سيُسَلسَل الكائنين <code>Data</code> و <code>[[Ruby/Time|Time]]</code> كسلسلة نصية (strings)، وقيم <code>[[Ruby/Hash|Hash]]</code> سوف يكون مفاتيحها سلسلة نصية بصيغة JSON (تدعى stringified).<syntaxhighlight lang="rails">
class CookiesController < ApplicationController
  def set_cookie
    cookies.encrypted[:expiration_date] = Date.tomorrow # => Thu, 20 Mar 2014
    redirect_to action: 'read_cookie'
  end
 
  def read_cookie
    cookies.encrypted[:expiration_date] # => "2014-03-20"
  end
end
</syntaxhighlight>من المستحسن تخزين البيانات البسيطة (السلاسل النصية والأعداد) في ملفات تعريف الارتباط. إذا كان عليك تخزين كائنات معقدة، فستحتاج إلى معالجة التحويل يدويًا عند قراءة القيم في الطلبات اللاحقة.

إذا كنت تستخدم مخزن جلسة ملفات تعريف الارتباط، فسيطبق ذلك على التجزئة <code>session</code> و <code>flash</code> أيضًا.

== تصيير بيانات XML و JSON ==
يجعل <code>ActionController</code> من السهل للغاية تقديم بيانات XML أو JSON. إذا كنت قد أنشأت وحدة تحكم باستخدام <code>scaffolding</code>، فسيبدو الأمر كالتالي:<syntaxhighlight lang="rails">
class UsersController < ApplicationController
  def index
    @users = User.all
    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render xml: @users }
      format.json { render json: @users }
    end
  end
end
</syntaxhighlight>قد تلاحظ في الكود السابق أننا استخدمنا <code>render xml: @users</code> وليس <code>render xml: @users.to_xml</code>. إذا لم يكن الكائن عبارة عن سلسلة نصية، فستستدعي ريلز تلقائيًا <code>to_xml</code> من أجلنا.

== المرشحات ==
المرشحات (Filters) هي التوابع التي تُشغِّل إجراءات وحدة التحكم "before"، أو "after" أو "around".

المرشحات موروثة، لذلك إذا قمت بتعيين مرشح على <code>ApplicationController</code>، سيشغل على كل وحدة التحكم في التطبيق الخاص بك.

قد تؤدي مرشحات "before" إلى إيقاف دورة الطلب. المرشح "before" الشائع هو الذي يتطلب تسجيل دخول المستخدم لإجراء ما. يمكنك تحديد طريقة الترشيح بهذه الطريقة:<syntaxhighlight lang="rails">
class ApplicationController < ActionController::Base
  before_action :require_login
 
  private
 
  def require_login
    unless logged_in?
      flash[:error] = "You must be logged in to access this section"
      redirect_to new_login_url # halts request cycle
    end
  end
end
</syntaxhighlight>يقوم التابع ببساطة بتخزين رسالة خطأ في الفلاش (flash) ويعيد التوجيه إلى نموذج تسجيل الدخول إذا لم يقم المستخدم بتسجيل الدخول.في حالة عرض أو أعاد المرشح "before" التوجيه، فلن تنفذ الإجراء. إذا كانت هناك مرشحات إضافية مجدولة للتشغيل بعد ذلك المرشح، فستُلغَى أيضًا.

في هذا المثال، يضاف المرشح إلى <code>ApplicationController</code> وبالتالي جميع وحدات التحكم في التطبيق ترثه. هذا سيجعل كل شيء في التطبيق يتطلب من المستخدم أن يقوم بتسجيل الدخول من أجل استخدامه. لأسباب واضحة (لن يتمكن المستخدم من تسجيل الدخول في المقام الأول!)، لا ينبغي أن تتطلب كل عناصر التحكم أو الإجراءات ذلك. يمكنك منع تشغيل هذا المرشح قبل تنفيذ إجراءات معينة باستخدام <code>skip_before_action</code>:<syntaxhighlight lang="rails">
class LoginsController < ApplicationController
  skip_before_action :require_login, only: [:new, :create]
end
</syntaxhighlight>الآن، سيعمل الإجراءين <code>new</code> و <code>create</code> الذين يخصان <code>LoginsController</code> كما من قبل دون الحاجة إلى تسجيل المستخدم. الخيار <code>‎:only</code> يُستخدَم فقط لتخطي هذا المرشح لهذه الإجراءات، وهناك أيضًا الخيار <code>‎:except</code> الذي يعمل بطريقة اخرى. يمكن استخدام هذه الخيارات عند إضافة المرشحات أيضًا، بحيث يمكنك إضافة مرشح لا يعمل إلا للإجراءات المحددة في المقام الأول.

'''ملاحظة''': لن يعمل استدعاء المرشح نفسه عدة مرات بخيارات مختلفة، نظرًا لأن آخر تعريف للمرشح سيحل محل المرشح السابق.

=== مرشحات After ومرشحات Around ===
بالإضافة إلى المرشحات "before"، يمكنك أيضًا تشغيل مرشحات بعد تنفيذ إجراء ما، أو قبل وبعد التنفيذ كليهما.

المرشحات "after" تشبه المرشحات "before"، ولكن نظرًا لأنَّ الإجراء قد شُغِّل بالفعل، فسيكون بإمكانهم الوصول إلى بيانات الاستجابة التي على وشك إرسالها إلى العميل. من الواضح أن المرشحات "after" لا يمكنها إيقاف الإجراء من التشغيل. يرجى ملاحظة أن المرشحات "after" تُنفَّذ فقط بعد إجراء ناجح، ولكن ليس عندما يرفع استثناء في دورة الطلب.

المرشحات "around" مسؤولة عن إدارة الإجراءات المرتبطة بها من خلال العائد (yielding)، على غرار الطريقة التي تعمل بها برمجيات Rack الوسيطة.

على سبيل المثال، في أحد مواقع الويب التي تحتوي على تغييرات في سير عمل الموافقة، يمكن للمسؤول معاينتها بسهولة، إذ ما عليك سوى تطبيقها في transaction:<syntaxhighlight lang="rails">
class ChangesController < ApplicationController
  around_action :wrap_in_transaction, only: :show
 
  private
 
  def wrap_in_transaction
    ActiveRecord::Base.transaction do
      begin
        yield
      ensure
        raise ActiveRecord::Rollback
      end
    end
  end
end
</syntaxhighlight>لاحظ أنَّ المرشح "around" يلتف أيضًا على العرض. على وجه الخصوص، إذا كان المثال أعلاه مذكورًا في قاعدة البيانات (على سبيل المثال عبر نطاق)، فسيجري ذلك داخل المعاملة وبالتالي تقديم البيانات للمعاينة.

يمكنك عدم اختيار العائد (yield) وبناء الاستجابة بنفسك، وفي هذه الحالة لن ينفذ الإجراء.

=== طرق أخرى لاستخدام المرشحات ===
في حين أنَّ الطريقة الأكثر استخدامًا لاستخدام المرشحات هي عن طريق إنشاء توابع خاصة واستخدام <code>action_*</code> لإضافتها، فهناك نوعان من طرق أخرى للقيام بنفس الشيء.

الأول هو استخدام كتلة مباشرة مع التوابع  <code>action_*</code>. تتلقى الكتلة وحدة التحكم كوسيطة. يمكن إعادة كتابة المرشح <code>require_login</code> من الأعلى لاستخدام الكتلة.<syntaxhighlight lang="rails">
class ApplicationController < ActionController::Base
  before_action do |controller|
    unless controller.send(:logged_in?)
      flash[:error] = "You must be logged in to access this section"
      redirect_to new_login_url
    end
  end
end
</syntaxhighlight>لاحظ أنَّ المرشح في هذه الحالة يستخدم الإرسال <code>send</code> لأنَّ <code>login_in?‎</code> تابع خاص ولا يشغل المرشح في نطاق وحدة التحكم. هذه ليست الطريقة الموصى بها لتطبيق هذا المرشح المحدد، ولكن في حالات أكثر بساطة قد يكون ذلك مفيدًا.

والطريقة الثانية هي استخدام صنف (في الواقع، أي كائن يستجيب للتوابع الصحيحة يمكن استخدامه) للتعامل مع المرشح. يفيد ذلك في الحالات الأكثر تعقيدًا ولا يمكن تنفيذها بطريقة مقروءة وقابلة لإعادة الاستخدام باستخدام التابعيين الأخريين. على سبيل المثال، يمكنك إعادة كتابة مرشح تسجيل الدخول مرة أخرى لاستخدام صنف:<syntaxhighlight lang="rails">
class ApplicationController < ActionController::Base
  before_action LoginFilter
end
 
class LoginFilter
  def self.before(controller)
    unless controller.send(:logged_in?)
      controller.flash[:error] = "You must be logged in to access this section"
      controller.redirect_to controller.new_login_url
    end
  end
end
</syntaxhighlight>مرة أخرى، هذا ليس مثالًا مثاليًا لهذا المرشح، لأنه لا يعمل في نطاق وحدة التحكم ولكنه يحصل على وحدة التحكم التي تمرر كوسيط. يجب أن يطبق صنف المرشح التابع مع الاسم نفسه كمرشح، لذلك، يجب على الفئة أن تقوم بتطبيق التابع <code>before</code> لمرشح <code>before_action</code>، وهكذا يجب على التابع <code>around</code> أن يعيد عبر <code>yield</code> لتنفيذ هذا الإجراء.

== طلب حماية التزوير ==
التزوير في الطلب عبر الموقع (Cross-site request forgery) هو نوع من الهجوم حيث يخدع الموقع مستخدمًا في تقديم طلبات على موقع آخر، وربما إضافة أو تعديل أو حذف البيانات على هذا الموقع دون معرفة المستخدم أو إذنه.

الخطوة الأولى لتجنب هذا هو التأكد من أنه لا يمكن الوصول إلى جميع الإجراءات "المدمرة" (إنشاء وتحديث وتدمير) إلا بطلبات non-GET. إذا كنت تتبع اصطلاحات RESTful التي تفعلها بالفعل. ومع ذلك، لا يزال بإمكان الموقع الخبيث إرسال طلب non-GET إلى موقعك بسهولة تامة، وهنا يأتي طلب حماية التزوير. كما يشير الاسم، فإنه يحمي من الطلبات المزورة.

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

إذا قمت بإنشاء نموذج مثل هذا:<syntaxhighlight lang="rails">
<%= form_with model: @user, local: true do |form| %>
  <%= form.text_field :username %>
  <%= form.text_field :password %>
<% end %>
</syntaxhighlight>سترى كيف يضاف الرمز المميز كحقل مخفي:<syntaxhighlight lang="html">
<form accept-charset="UTF-8" action="/users/1" method="post">
<input type="hidden"
       value="67250ab105eb5ad10851c00a5621854a23af5489"
       name="authenticity_token"/>
<!-- fields -->
</form>
</syntaxhighlight>تضيف ريلز هذا الرمز المميز إلى كل نموذج يُنشَأ باستخدام [[Rails/form helpers|مساعدي النموذج]] (form helpers)، لذلك معظم الوقت لا داعي للقلق بشأنه. إذا كنت تكتب نموذجًا يدويًا أو تحتاج إلى إضافة الرمز المميز لسبب آخر، فسيكون متاحًا من خلال التابع <code>form_authenticity_token</code>:

ينشئ <code>form_authenticity_token</code> رمز استيثاق صالح. وهذا مفيد في الأماكن التي لا تضيفها ريلز تلقائيًا، كما هو الحال في استدعاءات Ajax المخصصة.

يحتوي [[Rails/security|دليل الأمان]] على مزيد من المعلومات حول هذا الأمر والعديد من المشكلات الأخرى المتعلقة بالأمان والتي يجب أن تكون على دراية بها عند تطوير تطبيق ويب.

== كائنات الطلب والاستجابة ==
يوجد في كل وحدة تحكم تابعين ملحقين يشيران إلى كائنات الطلب و الاستجابة المرتبطة بدورة الطلب قيد التنفيذ حاليًا. يحتوي تابع الطلب <code>request</code> على نسخة من <code>ActionDispatch::Request</code> ويقوم تابع الاستجابة <code>response</code> بإرجاع كائن استجابة يمثل ما الذي سيرسل مرة أخرى إلى العميل.

=== كائن الطلب ===
يحتوي الكائن <code>request</code> على الكثير من المعلومات المفيدة حول الطلب القادم من العميل. للحصول على قائمة كاملة بالتوابع المتاحة مع هذا الكائن، راجع توثيق [http://api.rubyonrails.org/v5.2.2/classes/ActionDispatch/Request.html Rails API] و[http://www.rubydoc.info/github/rack/rack/Rack/Request توثيق Rack]. من بين الخاصيات التي يمكنك الوصول إليها على هذا الكائن:
{| class="wikitable"
!خاصية الكائن <code>request</code>
!الغرض
|-
|<code>host</code>
|اسم المضيف المُستخدَم لهذا الطلب.
|-
|<code>domain(n=2)‎</code>
|الأجزاء n الأولى من اسم المضيف، تبدأ من اليمين (TLD).
|-
|<code>format</code>
|نوع المحتوى المطلوب من قبل العميل.
|-
|<code>method</code>
|توابع HTTP المستخدمة للطلب.
|-
|<code>get?, post?, patch?, put?, delete?, head?</code>
|تعيد القيمة true إذا كانت طريقة HTTP هي GET / POST / PATCH / PUT / DELETE / HEAD.
|-
|<code>headers</code>
|تعيد التجزئة hash التي تحتوي على العناوين المرتبطة بالطلب.
|-
|<code>port</code>
|رقم المنفذ (عدد صحيح) المستخدم في الطلب.
|-
|<code>protocol</code>
|إرجاع سلسلة تحتوي على البروتوكول المستخدم بالإضافة إلى "‎://‎"، مثل "<nowiki>http://‎</nowiki>".
|-
|<code>query_string</code>
|جزء سلسلة الاستعلام من URL، أي كل شيء بعد الرمز "?".
|-
|<code>remote_ip</code>
|عنوان IP للعميل.
|-
|<code>url</code>
|عنوان URL بأكمله المُستخدَم في الطلب.
|}

==== معاملات المسار والاستعلام والطلب ====
تجمع ريلز كافة المعاملات المرسلة مع الطلب في التجزئة <code>params</code>، سواء أُرسلَت كجزء من سلسلة الاستعلام أو نص في post. يحتوي الكائن <code>request</code> على ثلاثة أدوات وصول تمنحك الوصول إلى هذه المعاملات اعتمادًا على مصدرها. تحتوي التجزئة <code>query_parameters</code> على معاملات أُرسلت كجزء من سلسلة الاستعلام بينما تحتوي التجزئة <code>request_parameters</code> على معاملات أُرسلت كجزء من جسم الطلبية post. بينما تحتوي التجزئة <code>path_parameters</code> على معاملات جرى التعرف عليها عليها بواسطة التوجيه باعتبارها جزءًا من المسار المؤدي إلى وحدة التحكم هذه والإجراء المحدد.

=== كائن الإستجابة ===
لا يُستخدَم الكائن <code>response</code> عادةً بشكل مباشر، ولكنه يُنشَأ أثناء تنفيذ الإجراء وعرض البيانات التي ترسل إلى المستخدم، ولكن أحيانًا - كما هو الحال في المرشح after - قد يكون من المفيد الوصول إلى الاستجابة مباشرةً. بعض من هذه التوابع ملحق بها أيضا ضابطات (setters)، مما يتيح لك ضبط وتغيير قيمها. للحصول على قائمة كاملة بالتوابع المتاحة، راجع [http://api.rubyonrails.org/v5.2.2/classes/ActionDispatch/Response.html توثيق Rails API] و[http://www.rubydoc.info/github/rack/rack/Rack/Response توثيق Rack].
{| class="wikitable"
!خاصية الكائن <code>response</code>
!الغرض
|-
|<code>body</code>
|هذه هي سلسلة البيانات التي يتم إرسالها مرة أخرى إلى العميل. هذا هو في الغالب HTML.
|-
|<code>status</code>
|رمز حالة HTTP للاستجابة، مثل 200 لطلب ناجح أو 404 لطلب لم يتم العثور عليه.
|-
|<code>location</code>
|عنوان URL الذي تتم إعادة توجيه العميل إليه، إن وجد.
|-
|<code>content_type</code>
|نوع محتوى الاستجابة.
|-
|<code>charset</code>
|ترميز المحارف المستخدمة للاستجابة. الترميز الافتراضي هو "utf-8".
|-
|<code>headers</code>
|العناوين التي تستخدم للاستجابة.
|}

==== ضبط عناوين مخصصة ====
إذا كنت ترغب في تعيين عناويين مخصصة للاستجابة، فإن <code>response.headers</code> هو المكان المناسب للقيام بذلك. تعتبر الخاصية <code>headers</code> عبارة عن جدول hash تعين أسماء العناوين إلى قيمها، وسوف تعين ريلز بعضها تلقائيًا. إذا كنت ترغب في إضافة عنوان أو تغييره، ما عليك سوى تعيينه عبر <code>response.headers</code> على هذا النحو:<syntaxhighlight lang="rails">
response.headers["Content-Type"] = "application/pdf"
</syntaxhighlight>'''ملاحظة''': في الحالة المذكورة أعلاه، قد يكون من الأفضل استخدام الضابط <code>content_type</code> مباشرةً.

== HTTP استيثاق ==
تأتي ريلز مع آليتي استيثاق HTTP مدمجتين:  
* استيثاق أساسي (Basic Authentication).
* استيثاق عبر قيم hash مختصرة (Digest Authentication).

=== استيثاق HTTP الأساسي ===
استيثاق HTTP الأساسي هو نظام استيثاق تدعمه غالبية المتصفحات وعملاء HTTP الآخرين. على سبيل المثال، ضع في الاعتبار قسم الإدارة الذي سيكون متاحًا فقط عن طريق إدخال اسم مستخدم وكلمة مرور في نافذة حوار HTTP الأساسية للمتصفح. يعد استخدام الاستيثاق المدمج سهلًا تمامًا ولا يتطلب منك سوى استخدام تابع واحد مثل <code>http_basic_authenticate_with</code>.<syntaxhighlight lang="rails">
class AdminsController < ApplicationController
  http_basic_authenticate_with name: "humbaba", password: "5baa61e4"
end
</syntaxhighlight>مع هذا، يمكنك إنشاء وحدات تحكم ضمن مجال أسماء (namespaced controllers) ترث من <code>AdminsController</code>. وبالتالي، سيُشغَّل المرشح لجميع الإجراءات في وحدات التحكم هذه، مع حمايتها باستخدام استيثاق HTTP الأساسي.

=== استيثاق طلبية HTTP عبر قيم hash مختصرة ===
يتفوق استيثاق طلبية HTTP عبر قيم hash مختصرة (HTTP digest authentication) على الاستيثاق الأساسي لأنه لا يتطلب من العميل إرسال كلمة مرور غير مشفرة عبر الشبكة (على الرغم من أن استيثاق HTTP الأساسي آمن عبر HTTPS). يعد استخدام استيثاق HTTP Digest مع ريلز أمرًا سهلاً للغاية ولا يتطلب سوى استخدام تابع واحد وهو <code>Authenticate_or_request_with_http_digest</code>.<syntaxhighlight lang="rails">
class AdminsController < ApplicationController
  USERS = { "lifo" => "world" }
 
  before_action :authenticate
 
  private
 
    def authenticate
      authenticate_or_request_with_http_digest do |username|
        USERS[username]
      end
    end
end
</syntaxhighlight>كما هو موضح في المثال أعلاه، تأخذ كتلة <code>authenticate_or_request_with_http_digest</code> وسيطًا واحدًا فقط وهو اسم المستخدم. وتعيد الكتلة كلمة المرور. سيؤدي إعادة القيمة <code>false</code> أو لا شيء من <code>authenticate_or_request_with_http_digest</code> إلى حدوث فشل في الاستيثاق.

== التدفق وتحميل الملفات ==
في بعض الأحيان قد ترغب في إرسال ملف إلى المستخدم بدلًا من عرض صفحة HTML. جميع وحدات التحكم في ريلز لها التابع <code>send_data</code> و <code>send_file</code>، وكلاهما سوف ترسل البيانات إلى العميل عبر مجرى (stream). إن <code>send_file</code> هو تابع ملائم يسمح لك بتوفير اسم الملف على لتنزيله إلى حاسوب العميل وسوف تتدفق محتويات هذا الملف لتنزيله. لبدء تدفق البيانات إلى العميل، استخدم <code>send_data</code>:<syntaxhighlight lang="rails">
require "prawn"
class ClientsController < ApplicationController
  # مع معلومات عن العميل وإعادته PDF توليد ملف  
  # PDF سيحصل المستخدم على الملف لتنزيله كملف
  def download_pdf
    client = Client.find(params[:id])
    send_data generate_pdf(client),
              filename: "#{client.name}.pdf",
              type: "application/pdf"
  end
 
  private
 
    def generate_pdf(client)
      Prawn::Document.new do
        text client.name, align: :center
        text "Address: #{client.address}"
        text "Email: #{client.email}"
      end.render
    end
end
</syntaxhighlight>سيقوم الإجراء <code>download_pdf</code> في المثال أعلاه باستدعاء تابع خاص يقوم بالفعل بإنشاء مستند PDF وإعادتها كسلسلة. بعد ذلك ستبدأ هذه السلسلة إلى العميل بالتدفق لتنزيل الملف وسيُقترَح اسم الملف للمستخدم. في بعض الأحيان، عند تدفق الملفات إلى المستخدم، قد لا ترغب في تنزيل الملف. التقط صورًا، على سبيل المثال، لتضمينها في صفحات HTML. لإخبار المتصفح أنه ليس من المفترض تنزيل أحد الملفات، يمكنك تعيين الخيار <code>‎:disposition</code> إلى القيمة <code>"inline"</code>. القيمة المقابلة والافتراضية لهذا الخيار هي <code>"attachment"</code>.

=== إرسال الملفات ===
إذا كنت ترغب في إرسال ملف موجود بالفعل على القرص، فاستخدم التابع <code>send_file</code>.<syntaxhighlight lang="rails">
class ClientsController < ApplicationController
  # إرسال الملف الذي جرى توليده مسبقًا لتخزينه على جهاز العميل
  def download_pdf
    client = Client.find(params[:id])
    send_file("#{Rails.root}/files/clients/#{client.id}.pdf",
              filename: "#{client.name}.pdf",
              type: "application/pdf")
  end
end
</syntaxhighlight>سيؤدي ذلك إلى قراءة الملف وتسجيله بسرعة 4 كيلوبايت في ذلك الوقت، مع تجنب تحميل الملف بأكمله إلى الذاكرة مرة واحدة. يمكنك إيقاف تشغيل التدفق باستخدام الخيار <code>‎:stream</code> أو ضبط حجم الكتلة باستخدام الخيار <code>‎:buffer_size</code>.

إذا لم يحدَّد الخيار <code>‎:type</code>، فسيُخمَّن من امتداد الملف المحدد في <code>‎:filename</code>. إذا كان نوع المحتوى غير مسجل للإمتداد، فسيُستخدَم application/octet-stream.

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

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

=== تنزيلات RESTful ===
لمَّا كان <code>send_data</code> يعمل على ما يرام، فإنَّه إذا كنت تقوم بإنشاء تطبيق RESTful مع وجود إجراءات منفصلة لتنزيل الملفات، فعادةً ما تكون غير ضرورية. في مصطلح REST، يمكن اعتبار ملف بصيغة PDF من المثال أعلاه مجرد تمثيل آخر لمورد العميل. توفر ريلز طريقةً سهلةً وميسرةً للغاية للقيام "بتنزيلات RESTful". في ما يلي كيفية إعادة كتابة المثال بحيث يكون تنزيل ملف PDF جزءًا من الإجراء <code>show</code>، دون أي تدفق (streaming):<syntaxhighlight lang="rails">
class ClientsController < ApplicationController
  # HTML يمكن أن يرسل المستخدم طلبًا لاستقبال هذا المورد بهيئة صفحة
  # PDF أو ملف
  def show
    @client = Client.find(params[:id])
 
    respond_to do |format|
      format.html
      format.pdf { render pdf: generate_pdf(@client) }
    end
  end
end
</syntaxhighlight>لكي يعمل هذا المثال، يجب عليك إضافة نوع PDF MIME إلى ريلز. يمكن القيام بذلك عن طريق إضافة السطر التالي إلى ملف config/initializers/mime_types.rb:<syntaxhighlight lang="rails">
Mime::Type.register "application/pdf", :pdf
</syntaxhighlight>لا يعاد تحميل ملفات التهيئة على كل طلب، لذا يجب عليك إعادة تشغيل الخادم حتى تُفعَّل التغييرات التي أُجريت.

الآن يمكن للمستخدم طلب الحصول على نسخة PDF من عميل فقط عن طريق إضافة "‎.pdf" إلى عنوان URL:<syntaxhighlight lang="rails">
GET /clients/1.pdf
</syntaxhighlight>

=== تدفق مباشر للبيانات الإعتباطية ===
تسمح لك ريلز بتدفق أكثر من مجرد ملفات. في الواقع، يمكنك بث أي شيء تريده في الكائن <code>response</code>. تسمح لك الوحدة <code>ActionController::Live</code> بإنشاء اتصال دائم مع المتصفح. باستخدام هذه الوحدة، ستتمكن من إرسال بيانات اعتباطية إلى المتصفح في أوقات محددة.

==== دمج التدفق المباشر ====
تضمين <code>ActionController::Live</code> داخل صنف وحدة التحكم الخاصة بك سيوفر كافة الإجراءات داخل وحدة التحكم للقدرة على تدفق البيانات. يمكنك الخلط في الوحدة بالشكل التالي:<syntaxhighlight lang="rails">
class MyController < ActionController::Base
  include ActionController::Live
 
  def stream
    response.headers['Content-Type'] = 'text/event-stream'
    100.times {
      response.stream.write "hello world\n"
      sleep 1
    }
  ensure
    response.stream.close
  end
end
</syntaxhighlight>ستحافظ التعليمة البرمجية المذكورة أعلاه على اتصال مستمر مع المتصفح و إرسال 100 رسالة من "hello world \ n"، كل ثانية واحدة منفصلة.

هناك أمران يجب ملاحظتهما في المثال أعلاه. نحن بحاجة للتأكد من إغلاق تدفق الاستجابة. نسيان إغلاق التدفق سيترك المقبس مفتوحًا للأبد. يتعين علينا أيضًا تعيين نوع المحتوى على text/event-stream قبل أن نكتب إلى تدفق الاستجابة. هذا لأن العناوين لا يمكن كتابتها بعد أن نُفِّذَت الاستجابة (عندما تعيد <code>?response.committed</code> قيمة صحيحة)، والتي تحدث عند كتابة أو تنفيذ تدفق الاستجابة عبر <code>write</code> أو <code>commit</code>.

==== مثال عملي ====
لنفترض أنك كنت تصنع آلة كاريوكي (Karaoke machine) ويريد المستخدم الحصول على كلمات أغنية معينة. كل أغنية لها عدد معين من الخطوط وكل سطر يستغرق وقتًا <code>num_beats</code> لإنهاء الغناء.

إذا أردنا إرجاع كلمات أغنية الكاريوكي (إرسال الخط فقط عندما ينتهي المغني من الخط السابق)، فيمكننا استخدام <code>ActionController::Live</code> على النحو التالي:<syntaxhighlight lang="rails">
class LyricsController < ActionController::Base
  include ActionController::Live
 
  def show
    response.headers['Content-Type'] = 'text/event-stream'
    song = Song.find(params[:id])
 
    song.each do |line|
      response.stream.write line.lyrics
      sleep line.num_beats
    end
  ensure
    response.stream.close
  end
end
</syntaxhighlight>ترسل الشيفرة السابقة السطر التالي فقط بعد اكمال المغني للخط السابق.

==== اعتبارات التدفق ====
يعد بث البيانات الاعتباطية أداة قوية للغاية. كما هو موضح في الأمثلة السابقة، يمكنك اختيار متى وماذا يجب إرساله عبر تدفق الاستجابة. ومع ذلك، يجب عليك أيضًا ملاحظة الأشياء التالية:
* ينشئ كل تدفق استجابة مؤشر ترابط جديد وينسخ عبر متغيرات مؤشر الترابط المحلي من مؤشر الترابط الأصلي. وجود العديد من المتغيرات المحلية لمؤشر الترابط يمكن أن يؤثر سلبًا على الأداء. وبالمثل، فإن عددًا كبيرًا من سلاسل الرسائل يمكن أن يعوق الأداء أيضًا.
* سيؤدي الفشل في إغلاق مسار الاستجابة إلى إغلاق المقبس المطابق للأبد. تأكد من إغلاق الاتصال عندما تستخدم تدفق استجابة.
* خوادم WEBrick تخزِّن جميع الردود، وهكذا لن تعمل <code>ActionController::Live</code>. يجب عليك استخدام خادم ويب لا يقوم تلقائيًا بتخزين الاستجابات.

== ترشيح السجل ==
تحتفظ ريلز بملف سجل (log) لكل بيئة في مجلد السجل. هذا مفيد للغاية عند تصحيح ما يحدث بالفعل في التطبيق الخاص بك، ولكن في تطبيق مباشر قد لا ترغب في تخزين كل جزء من المعلومات في ملف السجل.

=== ترشيح المعاملات ===
يمكنك ترشيح معاملات الطلب الحساسة من ملفات السجل الخاصة بك عن طريق إلحاقها بـ <code>config.filter_parameters</code> في ضبط التطبيق. ستوضع علامة على هذه المعاملات بالشكل <code>[FILTERED]</code> في السجل.<syntaxhighlight lang="rails">
config.filter_parameters << :password
</syntaxhighlight>'''ملاحظة''': ستُرشَح المعاملات المقدمة بواسطة التعبير النمطي المتطابق جزئيًّا. تضيف ريلز الخيار <code>‎:password</code> افتراضيًّا في المهيئ (initializer) المناسب (initializers/filter_parameter_logging.rb) وتهتم بمعاملات التطبيق النموذجية <code>password</code> و <code>password_confirmation</code>.

=== ترشيح إعادة التوجيه ===
من المستحسن أحيانًا ترشيح بعض ملفات المواقع الحساسة التي يعيد تطبيقك التوجيه إليها من ملفات السجل. يمكنك القيام بذلك عن طريق استخدام خيار الضبط <code>config.filter_redirect</code>:<syntaxhighlight lang="rails">
config.filter_redirect << 's3.amazonaws.com'
</syntaxhighlight>يمكنك تعيينه إلى سلسلة نصية، أو تعبير نمطي، أو مصفوفة على حد سواء.<syntaxhighlight lang="rails">
config.filter_redirect.concat ['s3.amazonaws.com', /private_path/]
</syntaxhighlight>عناوين URL المتطابقة يشار إليها بالعلامة <code>"[FILTERED]"</code>.

== معالجة الاستثناءات ==
على الأرجح سيحتوي التطبيق الخاص بك على أخطاء بطريقة أو بأخرى وسيُطلق استثناءات تحتاج إلى معالجة. على سبيل المثال، إذا اتبع المستخدم رابطًا لمورد لم يعد موجودًا في قاعدة البيانات، فسيلقي [[Rails/active record|Active Record]] الاستثناء <code>ActiveRecord::RecordNotFound</code>.

يعرض معالج الاستثناء الافتراضي في ريلز الرسالة "500 Server" لكافة الاستثناءات. إذا أنشئ الطلب محليًا، فسيعرض تتبع جيد وبعض المعلومات المضافة حتى تتمكن من معرفة الخطأ الذي حدث والتعامل معه. أمَّا إذا كان الطلب عن بُعد، فستعرض ريلز الرسالة "500 Server Error" البسيطة للمستخدم، أو الرسالة "404 Not Found" إذا كان هناك خطأ في التوجيه أو تعذر العثور على سجل ما. في بعض الأحيان قد ترغب في تخصيص كيفية اكتشاف هذه الأخطاء وكيفية عرضها للمستخدم. توجد عدة مستويات من معالجة الاستثناءات التي توفرها ريلز.

=== قوالب الخطأ 500 والخطأ 404 الافتراضية ===
بشكل افتراضي، سيعرض تطبيق الإنتاج رسالة الخطأ 404 أو 500، في بيئة التطوير تطلق كافة الاستثناءات غير المعالجة. تضمن هذه الرسائل في ملفات [[HTML]] الثابتة في المجلد العام ، في الملف ‎404.html و ‎500.html على التوالي. يمكنك تخصيص هذه الملفات لإضافة بعض المعلومات والتنسيقات الإضافية، ولكن تذكر أنها ملفات HTML ثابت؛ بمعنى أنه لا يمكنك استخدام ERB أو SCSS أو CoffeeScript أو مخططات معها.

=== الموجه <code>Rescue_from</code> ===
إذا كنت تريد القيام بشيء أكثر تفصيلًا عند اكتشاف الأخطاء، فيمكنك استخدام <code>rescue_from</code>، الذي يعالج استثناءات من نوع معين (أو أنواع متعددة) في وحدة تحكم كاملة والفئات الفرعية الخاصة بها.

عند حدوث استثناء اكتُشِف بواسطة الموجه <code>rescue_from</code>، يمرر كائن الاستثناء إلى المعالج. يمكن أن يكون المعالج تابع أو كائن <code>[[Ruby/Proc|Proc]]</code> مرر الى الخيار <code>‎:with</code>. يمكنك أيضًا استخدام الحظر مباشرةً بدلًا من الكائن <code>[[Ruby/Proc|Proc]]</code> الصريح.

إليك كيف يمكنك استخدام <code>rescue_from</code> لاعتراض جميع الأخطاء <code>ActiveRecord::RecordNotFound</code> وفعل شيء ما معهم.<syntaxhighlight lang="rails">
class ApplicationController < ActionController::Base
  rescue_from ActiveRecord::RecordNotFound, with: :record_not_found
 
  private
 
    def record_not_found
      render plain: "404 Not Found", status: 404
    end
end
</syntaxhighlight>بالطبع، هذا المثال هو أي شيء سوى أن يكون أكثر تفصيلًا إذ لا يحسن التعامل مع الاستثناءات الافتراضية على الإطلاق، ولكن بمجرد أن تتمكن من التقاط كل هذه الاستثناءات، فأنت حر في أن تفعل ما تريده معهم. على سبيل المثال، يمكنك إنشاء فئات استثناء مخصصة ستطلق عندما لا يكون لدى المستخدم حق الوصول إلى قسم معين من التطبيق الخاص بك:<syntaxhighlight lang="rails">
class ApplicationController < ActionController::Base
  rescue_from User::NotAuthorized, with: :user_not_authorized
 
  private
 
    def user_not_authorized
      flash[:error] = "You don't have access to this section."
      redirect_back(fallback_location: root_path)
    end
end
 
class ClientsController < ApplicationController
  # (clients) تحقق أنَّ المستخدم لديه الصلاحيات المناسبة للوصول إلى العملاء
  before_action :check_authorization
 
  # لا تهتم بأي شيء متعلق بالصلاحيات والرخص (actions) انتبه إلى أنَّ الإجراءات
  def edit
    @client = Client.find(params[:id])
  end
 
  private
 
    # إن كان المستخدم غير موثوق ولا يملك الصلاحيات المناسبة، فسيرمى استثناء
    def check_authorization
      raise User::NotAuthorized unless current_user.admin?
    end
end
</syntaxhighlight>'''تحذير''': قد يتسبب استخدام <code>rescue_from</code> مع <code>[[Ruby/Exception|Exception]]</code> أو <code>[[Ruby/StandardError|StandardError]]</code> في حدوث آثار جانبية خطيرة حيث تمنع ريلز من التعامل مع الاستثناءات بشكل صحيح. على هذا النحو، لا ينصح باستعمال <code>rescue_from</code> إلا إذا كان هناك سبب قوي لذلك.

'''ملاحظة''': عند التشغيل في بيئة الإنتاج، تعرض كافة الأخطاء <code>ActiveRecord::RecordNotFound</code> صفحة الخطأ 404. ما لم تكن بحاجة إلى سلوك مخصص، فأنت لا تحتاج إلى التعامل مع هذا الخطأ.

'''ملاحظة''': بعض الاستثناءات المحددة هي فقط قابلة للانقاذ (rescuable) من الصنف <code>ApplicationController</code>، كما أنها تُطلَق قبل أن تهيئ وحدة التحكم وأن ينفذ الإجراء.

== فرض بروتوكول HTTPS ==
في وقت ما قد ترغب في فرض وحدة تحكم معينة على الوصول إليها فقط عبر بروتوكول HTTPS لأسباب أمنية. يمكنك استخدام طريقة <code>force_ssl</code> في وحدة التحكم لفرض ما يلي:<syntaxhighlight lang="rails">
class DinnerController
  force_ssl
end
</syntaxhighlight>تمامًا مثل المرشح، يمكنك أيضًا تمرير الخيار <code>‎:only</code> و <code>‎:except</code> لفرض الاتصال الآمن فقط على إجراءات محددة:<syntaxhighlight lang="rails">
class DinnerController
  force_ssl only: :cheeseburger
  # أو
  force_ssl except: :cheeseburger
end
</syntaxhighlight>الرجاء ملاحظة أنه إذا وجدت نفسك تضيف <code>force_ssl</code> إلى العديد من وحدات التحكم، فقد تحتاج إلى فرض استخدام التطبيق بأكمله على HTTPS بدلًا من ذلك. في هذه الحالة، يمكنك ضبط <code>config.force_ssl</code> في ملف البيئة الخاص بك.

== المصادر ==
* [https://guides.rubyonrails.org/action_controller_overview.html صفحة Action Controller Overview في توثيق Ruby on Rails الرسمي.]