Forms & Strong Parameters

Forms are how users hand data to your app. Rails gives you form_with to build them, form helpers to render each field, and strong parameters to accept only the fields you intend to — safely.

Learn Forms & Strong Parameters in our free Ruby course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free Ruby course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

By the end of this lesson you'll build a model-backed form, whitelist input with params.require.permit, understand CSRF protection, and show a flash message.

What You'll Learn in This Lesson

1️⃣ Building a Form with form_with

In the view, form_with model: @post creates a form bound to a model. Helpers like form.text_field and form.submit render each control, pre-fill values when editing, and the CSRF token is added automatically.

2️⃣ Strong Parameters in the Controller

In the controller, never pass raw params to a model. Use params.require(:post).permit(:title, :body) to whitelist fields, then branch on save : redirect with a flash on success, or re-render the form on failure.

Your turn. Finish a CommentsController#create with a proper strong-parameters method and a flash message.

Build a form_with for a @message and a controller that whitelists name, email, and body, then shows a flash on success.

📋 Quick Reference — Forms & Strong Parameters

Practice quiz

Which helper is the modern way to build a form bound to a model?

  • form_tag
  • form_for
  • form_with
  • make_form

Answer: form_with. form_with is the current unified form helper in Rails.

What is the purpose of strong parameters?

  • To speed up the database
  • To whitelist which params may be mass-assigned
  • To validate the model
  • To encrypt the form

Answer: To whitelist which params may be mass-assigned. Strong parameters let only permitted attributes through to the model.

Which call correctly permits title and body for a post?

  • params.permit(:post)
  • params.allow(:title, :body)
  • params.require(:post).permit(:title, :body)

Answer: params.require(:post).permit(:title, :body). params.require(:post).permit(:title, :body) requires the post key and whitelists fields.

What does Rails' CSRF protection guard against?

  • SQL injection
  • Cross-site request forgery on state-changing requests
  • Cross-site scripting only
  • Slow database queries

Answer: Cross-site request forgery on state-changing requests. CSRF protection blocks forged state-changing requests from other sites.

How does form_with normally include the CSRF token?

  • You must add it by hand
  • It is added automatically as a hidden field
  • Only on GET forms
  • It is sent as a cookie

Answer: It is added automatically as a hidden field. form_with injects the authenticity_token hidden field automatically.

Inside form_with |form|, which helper renders a text field for title?

  • form.input :title
  • text_field(:title)
  • form.field :title, :text
  • form.text_field :title

Answer: form.text_field :title. form.text_field :title renders the input bound to the model attribute.

What is the flash used for?

  • Permanent settings
  • A short-lived message shown on the next request
  • Caching query results
  • Storing the CSRF token

Answer: A short-lived message shown on the next request. The flash holds a message available to the immediately following request, ideal after a redirect.

Why call permit on params instead of using them directly?

  • For faster JSON parsing
  • To avoid ForbiddenAttributesError and unwanted mass assignment
  • To translate the params
  • It is purely stylistic

Answer: To avoid ForbiddenAttributesError and unwanted mass assignment. Passing raw params to a model raises ForbiddenAttributesError; permit whitelists safe fields.

Which flash key is conventional for a success message after creating a record?

flash[:notice] (often via notice:) is the conventional success message.

If a create action fails validation, what is the usual response?

  • Redirect to the index
  • Re-render the form with the invalid object and status :unprocessable_entity
  • Raise a 500 error
  • Silently ignore it

Answer: Re-render the form with the invalid object and status :unprocessable_entity. You re-render :new with the unsaved record so its errors display, using 422.