This controller action uses strong parameters to only allow name and email when creating a new user. It prevents any other data from being saved.
Ruby on Rails
class UsersController < ApplicationController
def create
user_params = params.require(:user).permit(:name, :email)
@user = User.new(user_params)
if @user.save
render plain: "User created: #{@user.name}, #{@user.email}"else
render plain: "Failed to create user"
end
end
end
OutputSuccess
Important Notes
Always use strong parameters in Rails controllers when handling user input.
Without strong parameters, Rails will raise an error to protect your app.
You can permit nested attributes by passing a hash to permit.
Summary
Strong parameters keep your app safe by filtering input data.
Use require and permit to specify allowed data.
This helps prevent security problems like mass assignment.
Practice
(1/5)
1. What is the main purpose of using strong parameters in a Rails controller?
easy
A. To speed up database queries
B. To style the HTML output
C. To filter and allow only permitted attributes from user input
D. To handle user authentication
Solution
Step 1: Understand the role of strong parameters
Strong parameters are used to control which attributes can be set through forms or API requests.
Step 2: Identify the security purpose
This filtering prevents unwanted or harmful data from being saved, protecting against mass assignment vulnerabilities.
Final Answer:
To filter and allow only permitted attributes from user input -> Option C
Quick Check:
Strong parameters = filter input [OK]
Hint: Strong parameters filter input data to keep app safe [OK]
Common Mistakes:
Thinking strong parameters speed up queries
Confusing with styling or authentication
Ignoring security risks of mass assignment
2. Which of the following is the correct syntax to permit the name and email attributes inside a user_params method?
easy
A. params.require(:user).permit(name, email)
B. params.permit(:user).require(:name, :email)
C. params.permit(:name, :email).require(:user)
D. params.require(:user).permit(:name, :email)
Solution
Step 1: Recall the correct order of methods
The correct pattern is to first require the parent key, then permit the allowed attributes.
Step 2: Check the syntax for symbols
Attributes must be symbols (with colon), so :name and :email are correct.
Final Answer:
params.require(:user).permit(:name, :email) -> Option D
Quick Check:
require then permit with symbols = C [OK]
Hint: Use require first, then permit with symbols [OK]
Common Mistakes:
Swapping require and permit order
Using attribute names without colons
Calling permit before require
3. Given this controller code snippet:
def create
user = User.new(user_params)
if user.save
render json: user
else
render json: user.errors
end
end
def user_params
params.require(:user).permit(:name, :age)
end
What happens if the incoming params include { user: { name: "Alice", age: 30, admin: true } }?
medium
A. The entire user hash is rejected
B. The admin attribute is ignored and not set on the user
C. An error is raised because admin is not permitted
D. The admin attribute is saved as true
Solution
Step 1: Understand permit filtering
Only :name and :age are permitted, so admin is filtered out.
Step 2: Check behavior on extra params
Extra keys are ignored silently, no error is raised, and only permitted attributes are assigned.
Final Answer:
The admin attribute is ignored and not set on the user -> Option B
Quick Check:
Unpermitted keys are ignored = D [OK]
Hint: Unpermitted keys are ignored, not saved or error [OK]
Common Mistakes:
Expecting unpermitted keys to be saved
Thinking unpermitted keys cause errors
Assuming entire params rejected
4. Identify the error in this user_params method:
def user_params
params.permit(:name, :email).require(:user)
end
medium
A. require should be called before permit
B. The method should use fetch instead of require
C. The attributes should be strings, not symbols
D. There is no error; the code is correct
Solution
Step 1: Recall correct method order
In strong parameters, require must be called first to get the nested hash.
Step 2: Understand method chaining
Calling permit before require causes an error because permit is called on the whole params, not the nested hash.
Final Answer:
require should be called before permit -> Option A
Quick Check:
require before permit = A [OK]
Hint: Always call require before permit in strong params [OK]
Common Mistakes:
Swapping require and permit order
Using strings instead of symbols (not an error)
Thinking fetch replaces require
5. You want to allow nested attributes for a user's profile with bio and avatar_url. Which user_params method correctly permits this nested data?
hard
A. params.require(:user).permit(:name, profile: [:bio, :avatar_url])
B. params.require(:user).permit(:name, :profile => :bio, :avatar_url)
C. params.require(:user).permit(:name, :profile: [:bio, :avatar_url])
D. params.require(:user).permit(:name, :profile, :bio, :avatar_url)
Solution
Step 1: Understand nested attributes syntax
To permit nested hashes, use a hash with the key and an array of permitted keys inside permit.
Step 2: Check each option's syntax
params.require(:user).permit(:name, profile: [:bio, :avatar_url]) correctly uses profile: [:bio, :avatar_url]. params.require(:user).permit(:name, :profile => :bio, :avatar_url) and C have syntax errors or wrong hash style. params.require(:user).permit(:name, :profile, :bio, :avatar_url) permits keys at top level incorrectly.
Final Answer:
params.require(:user).permit(:name, profile: [:bio, :avatar_url]) -> Option A
Quick Check:
Nested permit uses hash with array = A [OK]
Hint: Use hash with array for nested attributes in permit [OK]
Common Mistakes:
Passing nested keys as separate symbols
Using wrong hash rocket syntax inside permit
Permitting nested keys at top level
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.