- 我应该对用户名施加什么限制?为什么?
- 我不应该对用户名施加哪些限制?为什么?
PS db 是通过最佳实践 PDO 实现的,因此没有 sql 注入的风险
谢谢
PS db 是通过最佳实践 PDO 实现的,因此没有 sql 注入的风险
谢谢
好的,让我们假设您正确地完成了所有字符串编码任务。您没有任何 SQL 注入、HTML 注入或您不应该对某些东西进行 URL 编码的地方。所以我们不需要担心像 "<&%\ 这样的字符在某些情况下会变魔术。而且你对所有东西都使用 UTF-8,所以所有的 Unicode 都在起作用。还有什么其他原因来限制用户名?
首先,所有控制字符,为了理智。没有理由在用户名中包含字符 U+0000 到 U+001F 或 U+007F 到 U+009F。
接下来,拒绝或规范化意外的空白。您可能希望在用户名中允许有空格,但您几乎可以肯定不希望允许前导空格、尾随空格或连续多个空格。它们可能在 HTML 中呈现相同的内容,但可能是会混淆的用户错误。
如果您打算允许该用户名用于通过 HTTP 基本身份验证登录,则必须禁止该:
字符,因为如果用户名或密码中有冒号,基本身份验证方案会编码一个不转义的“用户名:密码”对。所以至少用户名和密码中的一个必须排除冒号,最好是用户名,因为限制人们选择密码比用户名更糟糕。
对于基本身份验证,您可能还希望禁用所有非 ASCII 字符,因为不同浏览器对它们的处理方式不同。IE 使用系统代码页对它们进行编码;Firefox 使用 ISO-8859-1 对其进行编码;Opera 使用 UTF-8 对它们进行编码。如果 HTTP Auth 将可用,则至少应在选择非 ASCII 名称之前警告用户,因为实际使用它们将非常不可靠。
接下来考虑其他 Unicode 控制序列,例如双向覆盖和其他列出的字符不适合在标记中使用。可能您最终会将它们放入标记中,并且您不希望名称中带有 RLO 的人将您页面中的大量文本向后翻转。
此外,如果您允许 Unicode 对您获得的字符串进行规范化。否则,有人可能有一个包含 o-umlaut 字符的用户名ö
,并且想知道为什么他们无法在 Mac 上登录,Mac 默认情况下会使用一个单独的o
字符,然后是组合 umlaut。通常在网络上标准化为组合形式的 NFC。您可能还想使用 NFKC 形式进行兼容性分解;这将允许用户 Chris 从日文键盘以全角罗马字模式键入 chris 登录。这些是解决所有 webapp 输入的一般问题,但对于像用户名这样的标识符,正确处理可能更为关键。
最后,确保长度可以适合数据库,而无需更改名称的静默截断,特别是如果您存储为 UTF-8 字节,而您不想在字节序列中途被截断。用户名截断通常也是一个安全问题。
如果您使用用户名作为唯一的识别方式,您需要担心的还有很多:已经提到的相似问题,例如Сhris
(带有西里尔字母 Es С
)。这些太多了,您无法合理处理;要么限制为 ASCII,要么有其他方法来识别用户。(或者不在乎,就像 SO 不一样;当我可以轻松地称自己为 Chris 时,我不需要称自己С
为 -hrs。)
取决于很多事情,例如,如果用户将拥有自己的 URL,您需要注意创建用户名“%41llan”的人不会与名为“Allan”的用户发生冲突,同时允许转发-斜线可能会导致问题。注意这些限制。
我从来没有看到对用户名添加限制的意义。如果您的代码能够抵抗 sql 注入攻击,那么就让他们放入任何他们想要的东西。
我要添加的唯一限制是最大长度,以便它可以存储在数据库表中
让他们在其用户名中使用任何 Unicode 字符。对允许的字符添加限制可能只会惹恼使用非 ascii 语言的人。
SQL 注入保护是必须的,但这可能应该在您的代码中,而不是在用户名限制中。某些字符绝对应该转义,例如 \、% 等。
它会在你运行什么样的网站上,但我认为一些淫秽的字词限制会让你的网站看起来更专业。如果有人看到人们可以使用“脏话”作为用户名四处走动,那么您的网站就会显得幼稚。恕我直言,这就像让青少年在您的书店里肆无忌惮地奔跑。您可能不需要比这更挑剔,尽管这完全取决于您。
这有点偏离主题,但作为另一条用户名建议,任何网站的一个重要功能是允许用户随着时间的推移更改他们的用户名。您可以只使用一个数字作为主键,并且允许他们这样做可以节省很多抱怨和创建新帐户的人,因为他们想更改他们的用户名。:D