我使用数据存储中实体的键值作为 URL 中的唯一标识符来提取记录：
http://mysite.appspot.com/myaction/1x7s3fgdlbnRlcklkcicLAbcXc2VyQWNjb3VudCIFYW9uZ
这不是一个非常有吸引力的解决方案，也不是对 SEO 友好，但它是我发现在 App Engine/Java 中唯一标识实体的最简单方法。
不过，我主要关心的是是否存在与显示实体的唯一键值相关的任何安全问题？
【问题讨论】：
标签： java security google-app-engine primary-key bigtable
在编码密钥包含应用ID，命名空间（如果有的话），实体类型名称，和键名称或ID。这里有两个可能的问题：披露的信息（可能不是问题），而且你要接受编码的关键事实。如果你不检查，通过键值为指定的实体传递是正确的那种，并且用户应该可以访问它，然后他们可以在自己的键传递给你造成信息披露你不应该
几乎普遍，但是，你已经知道了实体你取的样的名字，所以一个更好的主意是使用的关键就在关键的名称或ID，构建随需应变的全键。这也使得更干净的URL。 P>
【讨论】：
安全问题是潜在的黑客知道一些关于您的数据库的信息，无论多么少。
如果您的数据库的某些部分曾经遭到破坏，实体 ID 可能对黑客有用。
和您一样，我不太喜欢显示数据库 ID，但如果您正确保护您的应用程序，则无需担心，因为知道实体 ID 不会有用。 p>
【讨论】：
你确定那是一把真正的钥匙吗？它看起来不像一个（un-base64'd 数据通常包括您的应用标识符）。
documentation 覆盖了它，不过：
注意：字符串编码的密钥可以转换回原始密钥数据。这使得在已知一个密钥时很容易猜测其他密钥。虽然字符串编码的键值可以安全地包含在 URL 中，但只有在键的可猜测性不是问题时，应用程序才应该这样做。
做这样的事情要干净得多：
foo = FooModel.get_by_id(int(foo_id))
这并不能阻止攻击者猜测 ID，但至少它不会让您误以为 ID 是“不透明的”（您可以简单地更改 ID 以测试访问控制，而不需要乱搞base64-protobuf 编码的数据）。
【讨论】：
在我看来，这不是安全问题。许多站点使用 id 作为站点内的标识符。键只是数据库表中一行的键，您确实希望避免在表和用户帐户等方面显示有关数据库的太多详细信息。
在这方面，您希望禁止您的网站在发生数据库错误时将其转储出来，并加以捕捉并妥善处理。
【讨论】：