The create action uses the message params method to safely collect data from the form and update the database.

What does it mean by "safely"? How could this have been designed in an unsafe way?

If the server accepted any data you sent it, you would be able to send in database queries (for example). Those could be a serious problem, especially if you were storing password hashes or other sensitive information on your server, because then malicious people could get it easily.

There’s a series of callbacks associated with save. If any of the before_* callbacks return false the action is cancelled and save returns false.

For example, maybe if you specified that a certain field couldn't be empty (empty fields are allowed by default, which is why you didn't get an error), or had a minimum length, and the data didn't meet those criteria, then save would return false

Why is :message required in the message_params function but :content is only permitted?

See this Stack Overflow answer and this documentation page. require will throw an error if it's missing, but permit doesn't care if it's fields are missing. permit's job is to weed out all of the fields that aren't allowed, such as if you tried to submit a title with your message somehow.

For example, maybe if you specified that a certain field couldn't be empty (empty fields are allowed by default, which is why you didn't get an error), or had a minimum length, and the data didn't meet those criteria, then save would return false

As we didn't set up any minimum length etc validation am I right in thinking that in this case @message.save will never return false?

I have since modified my message model with the following:

validates :content, presence: true,
length: {minimum: 5}

So now it will render new.html again with some error message if the text field is blank or less than 5 characters so I think i have a decent handle on this now, thanks for your help!

zystvan:

If the server accepted any data you sent it, you would be able to send in database queries (for example). Those could be a serious problem, especially if you were storing password hashes or other sensitive information on your server, because then malicious people could get it easily.

How would someone else be able to get at it? These functions run on the server so how would someone else be able to run them? I assume this has something to do with the "private" before def message_params? What does that do?

As we didn't set up any minimum length etc validation am I right in thinking that in this case @message.save will never return false?

I think so, I don't know of any situations in which it'd return false without you adding validations.

How would someone else be able to get at it?

That's a good question The easiest way would be to use the browser developer tools to add an extra field to the form, then submit it. Here's a blog post talking about the permit() stuff (called “strong parameters”) when it was introduced:

We’re exploring a new way to deal with mass-assignment protection in Rails. Or actually, it’s not really a new way, it’s more of an extraction of established practice with some vinegar mixed in for when you forget. This new approach is going to be a...

These functions run on the server so how would someone else be able to run them?

You'd run them by submitting the form, which will send an HTTP request to the server, which will then take care of checking it's validity and adding it to the DB and anything else.

I assume this has something to do with the "private" before def message_params? What does that do?

If I remember correctly, private just means you can't access those methods (or variables or whatever else you put inside the private part) from outside that controller file. It's been a while since I took the Ruby course though