我已经阅读了RFC,但无法理解它的目的,请有人帮我简化一下。
总长:
对于我们大多数只在 ascii 领域键入可打印字符的人来说,saslprep 和 stringprep 是无操作的。
仅对于 unicode 中奇怪的边缘情况才重要。
通过编程语言中常见的“字符串比较”例程,在人眼看来相同的两个字符串可能不相等。
某些用户在创建用户名或密码时,会设法键入 unicode 控制字符、“不间断”类型字符或
" "
(空格)的其他变体,这些变体看起来像普通空格,但具有不同的 unicode 值。或者不知何故,非法的 unicode 字符、双向希伯来字符或“土耳其字母 I”的多种变体看起来相同,但序数值不同。此外,除了可打印字符之外,unicode 还有很多其他奇怪的东西。像代码点、格式等之类的东西...
如果用户在创建帐户时输入的用户名和密码超出了 ASCII 范围,大多数网站都会崩溃并向用户显示错误。问题解决了。为此无需 saslprep。
但这是一个经典的例子。
假设我向服务台发送电子邮件,请求有关名为
t-bone
的内部帐户的帮助。 但 Outlook 有一个奇怪的功能,它将键盘上所有键入的连字符 (-) 替换为破折号 (-) 字符,因为它看起来更美观。如果支持代理将该字符串从我发送给他们的电子邮件中剪切并粘贴到支持工具中,它将被查找为 t—bone
。 我们来比较一下:
t-bone
对
t—bone
您必须眯着眼睛才能看到一个使用连字符 (-) 和另一个使用破折号 (—) 的区别。使用浏览器放大,看看是否可以看到上面两个字符串之间的区别。 再次使用相同的字符串,无需等宽处理:
对
现在您也许能够发现细微的差别!
因此,如果该电子邮件从 Outlook“剪切并粘贴”到支持代理使用的在线帮助工具中,他们可能无法查找我的帐户。
这是 saslprep (stringprep) 解决的问题类型之一。它需要客户端软件将破折号规范化回常规的 ascii 连字符,以便进行密码和用户名比较。同样,某些不可打印的字符也会被压缩为空。其他字符会折叠成常规空格字符(ascii:0x20)。 我没有阅读规范来了解它如何处理预组合字符,但我猜它有一个相应的策略。
当我几年前实现 Stuntman 时,我记得在 RFC 中看到过并阅读了它。 然后我得出结论,服务器不需要关心,因为标准化字符串是客户端的工作。如果我在客户端命令行工具中实现了 STUN 身份验证,我可能会合理化认为,由用户来确保他们在输入之前提交了“saslprep”规范化字符串。 :)
我的另一个观点是,我认为 STUN RFC 作者只是将 SASLprep 要求猛烈地纳入了他们的规范中 - 要么是因为他们遵循了其他 RFC 中提出的相同内容,要么是因为他们在同行评审中得到了反馈,认为这是一个问题。