我对asp.net核心标识框架还很陌生。许多教程，文章和指南似乎都以相同的方式处理IdentityError。它们向用户公开错误的描述，即，将错误的描述添加到ModelState。
人们已经知道，向用户暴露错误是一个可怕的主意，因为它可以增强攻击者的能力。
因此，我认为，这必须取决于描述中提供的信息类型。例如，如果错误是“您的密码太弱”或“您需要输入有效的电子邮件地址”。这类信息对用户来说很有价值，应该可以显示。但是，“数据源响应时间太长”已经是太多信息，并且价值不大。我宁愿捕获这种类型的错误，并用一些通用的500错误代替。
所以我的问题是：向用户显示原始身份错误是否安全？如果没有，我该如何过滤应该和不应该显示给用户的内容？
我尝试查看MSDN docs以了解我可能收到的所有可能的代码。但是这些文档提供的信息很少。
我正在专门与
一起工作var userCreationResult = await userManager.CreateAsync(newUser, password);
但是它适用于可能出现IdentityError的任何实例。
答案 0 :(得分：2)
许多软件质量和安全法规对此都有审核要求（向最终用户显示的任何错误消息都可能不包含机密信息，或者使用户有恶意意图危害系统或访问敏感数据），因此这很重要题。如果有专门针对此问题的文档或文章，那么它将被隐藏起来。
IdentityError类的两个成员可以假定的可能值被放入框架中。因此，看起来您可以确定它将始终是其中之一，除非您从IdentitiyError以外的任何其他地方获取UserManager的实例。
从错误方法的Code中分配了nameof字段，并从核心框架资源中读取了相关的Description文本，因此将对其进行本地化。
Source Code
en-us Descriptions
当前实现中的错误列表（版本3.0.0）：
其中大多数是静态字符串，不会公开任何变量信息。
以下内容确实披露了可变信息。这是前八种情况下用户先前提供的数据，后两种情况是服务器配置属性的值，有效密码中所需的最小密码长度和最少唯一字符数：
如果在您的项目的约束和规范内可以认为是“安全”，那么答案是肯定的。
答案 1 :(得分：1)
关于第二个问题，您可以执行以下操作以过滤掉 遇到错误时，用户名重复
if (error.Code == _userManager.ErrorDescriber.DuplicateUserName(user.UserName).Code)
{
//Hide info to user by, e.g. redirecting to a page for a registration flow, or display an invalid login attempt for a login flow
}