Rails 5 在传递参数时将对象转换为字符串答案

【问题标题】：Rails 5 converts object to a string when passing on the paramsRails 5 在传递参数时将对象转换为字符串
【发布时间】：2018-02-10 02:45:09
【问题描述】：

在 Rails 5 中，我的注册页面使用 form_for 助手创建用户，然后将其定向到我的自定义确认页面。

  <%= form_for @user, url: {action: :confirm} do |f| %>

在我的确认控制器中，我可以毫无问题地访问参数。这就是它们在控制台中的显示方式。

 Parameters: {"utf8"=>"✓",
"authenticity_token"=>"<longBlaString>", 
"user"=>{"name"=>"Railsmastanot", 
         "email"=>"example@domain.com", 
         "password"=>"[FILTERED]", 
         "password_confirmation"=>"[FILTERED]"}, 
"commit"=>"Sign up"}

然后我用

<%= button_to "Yes", {controller: "users", action: "create", params: params}, class: 'btn btn-success' %>

重定向到实际的users#create 方法。在里面我试图访问参数，例如params[:user][:email] 但报错

没有将 Symbol 隐式转换为 Integer

检查控制台显示我的参数哈希变成了这样：

Parametes:
 {"authenticity_token"=>"longBlaString", 
"commit"=>"Sign up",
"user"=>"email=example@domain.com&name=Railsmastanot&password=
<myActualPassword!>&password_confirmation=<myActualPassword!>", 
"utf8"=>"✓"}

所以用户键不再保存哈希，而是一个字符串。这应该发生还是错误？如果不是错误，那么处理此问题的正确方法是什么？我做错了吗？

编辑：

我发现params 实际上不是 Rails 5 中的哈希值。如果我传递 params: params.to_unsafe_h 之类的参数，它可以工作，但我不确定这样做是否安全。

【问题讨论】：

您想创建注册表单，但在发布数据后为什么需要重定向页面来创建？您的问题不清楚。
我的注册表单工作正常。它按预期传递参数。以前，我可以毫无问题地创建用户。现在我想添加一个中间确认页面，所以[new user form] => [confirm]=>[create user]。从 [new user form] 到 [confirm] 的参数按预期传递。但是，当我将参数从 [confirm] 传递给 [create user] 时，参数哈希会按上述方式进行修改。
in users#create 如果您执行 sample_hash = JSON.parse(params) 会发生什么。您可以使用 sample_hash 吗？放个byebug看看

标签： ruby-on-rails ruby ruby-on-rails-5

【解决方案1】：

可以这样完成

在用户表中确认添加列
当表单提交时保存用户确认 => false 并从中获取 id。
然后从确认页面发送带有确认的用户 ID。
如果信息得到确认，则将用户更新为 Confirm = true。
如果信息未得到确认，则删除用户。

您使用的方法可能不安全，因为参数打印在确认页中。

【讨论】：

是这样的吗？在确认之前创建用户似乎有点不干净，还是这是一种正常做法？
您能否解释一下“可能不安全”是什么意思？我在确认页面中打印的参数只有姓名和电子邮件，而不是密码。

【解决方案2】：

好的，我在这里得到了一个很好的答案，但它并没有真正回答发生了什么的问题。问题的根源在于 Rails 5 中的 params returns an object, not a hash.所以实际上在 Rails 5 中执行params: params.to_unsafe_h 似乎等同于在 Rails 4 中简单地 params: params。有人告诉我这样做只是因为 Rails 5 想让你知道你正在传输的确切数据，以便你不'不要无意中不必要地传输安全数据（例如，在不需要时传递整个用户对象）。它是 Rails 4 中已经实现的 Strong Parameters 功能的扩展。

据我所知，在这种情况下这并没有真正引入任何安全风险，因为params.to_unsafe_h 会立即转换回参数对象。

【讨论】：

【解决方案3】：

除了接受的答案之外，params.permit! 也可以解决问题。

【讨论】：

您可能希望通过解释该代码的作用来对此进行扩展，然后删除“除了接受的答案之外”的语句。您的目标肯定是让您的答案被接受，不是吗？