我正在创建一个基于向导的表单系列，用于获取用户输入。该向导的要求之一是脚本（PHP）无法将输入保存到数据库（MySQL），直到用户单击“保存”按钮，因此我必须设置一种机制将用户输入以一种形式传输到另一种形式当用户点击“上一个”或“下一个”按钮时。我研究了使用各种方法，包括cookie，会话，临时文件等，但我决定将base64_encoded序列化数据嵌入到系列中所有形式的隐藏字段中。此字段中的值将在表单提交时解码，并在插入当前表单的其他值后重新编码以放入下一个表单。
以下是隐藏字段的外观示例：
<input type="hidden" name="wizard:presave" value="YTo2OntzOjU6InRpdGxlIjtzOjEwOiJRdWVzdGlvbiAyIjtzOjQ6InRleHQiO3M6MTk6IlllcyBpdCdzIGEgcXVlc3Rpb24iO3M6NDoidHlwZSI7czo2OiJjaG9pY2UiO3M6NzoiY2hvaWNlcyI7YTowOnt9czo1OiJwb2ludCI7aToxO3M6Mjoib3AiO3M6MTM6ImVkaXRfZXhlcmNpc2UiO30=" />
所以问题是：
它被视为好/坏做法？
HTMLform中的隐藏字段是否有任何长度限制？
可能存在哪些安全问题？
还有更好的选择吗？ （附带说明，最好不使用javascript）
提前致谢！
答案 0 :(得分：1)
在我的职业生涯中，我从未见过这种特殊的参数传递方法，所以我不能说这是好还是坏。它当然不是“标准”。标准方法要么使用隐藏的输入传递提交的方法（未编码/正常），要么存储在会话中。我想你可能正在为自己做工，所以从这个意义上来说，它会倾向于“不理想”。
只要您为表单使用POST，就没有我在HTTP规范中知道的数据大小的定义限制。较旧的服务器可能有实际限制，但除非您正在做一些极端的事情，例如媒体文件上传，否则不应该担心。
可能的安全问题是正常的网络安全漏洞。您从用户那里获取并重新输出到页面的任何内容都可能包含跨站点脚本漏洞，并且必须进行适当的清理（如果您对所有内容进行编码，这有点没有用）。用户可以制作自己的数据并在需要时提交。基本上，假设您处理的所有数据都不安全且受到污染。
会话在这里会更好。用户提交的数据不必经过冗长的编码过程。同样，您只需要验证一次。在提交并验证之后，您只需将其存储在$ _SESSION中的服务器上并保持不变直到单击最后一个按钮。否则，您必须担心重新输出，重新接收它，并在每一步重新验证它。恶意用户可以提交一组数据，检查并重新输出为编码数据，然后通过取消编码，更改数据和重新编码来制作下一个表单提交。
我强烈建议您重新考虑会话，因为它会将您的所有数据操作简化为“一次性”方案。
答案 1 :(得分：1)
它被视为好/坏做法吗？
取决于目的。到目前为止，我只看到这样的构造作为客户端URL哈希，以记住基于ajax的大型应用程序中的选择状态（因此它们是可收藏的），然后通常也经过Gzip来缩短它。在您的特殊情况下，我会说：使用HTTP会话并仅在隐藏字段中传递基于请求的标识符（也称为标记），以便您可以从会话中获取相关信息。
HTMLform中的隐藏字段是否有任何长度限制？
在GET中，完整的查询字符串（所有参数名称和值以及分隔符）通常限制为2048个字符，但您可以更好地遵守256个字符的管理限制。在POST中，它取决于服务器配置。通常这默认大约为2GB。
可能存在哪些安全问题？
嗯，它显然是可解码的。
还有更好的选择吗？ （有解释，最好不使用javascript）
你可以通过Gzip来缩短它并使其不那么明显。或者，如前所述，将会话与基于请求的标识符结合使用。
答案 2 :(得分：0)
好吧，您可以通过序列化存储到会话中，或者只是按照每个步骤的方式存储它。当用户单击“保存”时，您将获取并验证会话中所有步骤的数据。
答案 3 :(得分：0)
tsk tsk：）
它被视为好/坏做法？ 主观上 - 糟糕的做法......你正在使用错误的锤子来完成工作。
HTMLform中的隐藏字段是否有长度限制？ - 不确定是否有限制。
可能存在哪些安全问题？ - 可能有很多，但您可以清理每个请求收到的数据。此外，数据很容易解码，并且可以在客户端轻松修改（我可以看到它正在使用的某种json :)）
还有更好的选择吗？ （有解释，最好不使用javascript） - 使用正确的工具.. sessions或许？
是的......您很可能会遇到性能和可伸缩性问题（如果您有大量用户负载），并为每个请求运行所有清理，解析，格式化和安全代码。