ASP.NET Core 试题 29：ASP.NET Core Identity
0561 在 UserManager 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建
- B. UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作
- C. 业务应检查 IdentityResult.Errors，不能只看是否抛异常
- D. 观察到“注册接口向客户端返回成功但数据库无用户”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 UserManager 的主规则：UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作。选项“业务应检查 IdentityResult.Errors，不能只看是否抛异常”是使用规则时要验证的边界，不是规则本身；“CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0562 注册接口向客户端返回成功但数据库无用户。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“业务应检查 IdentityResult.Errors，不能只看是否抛异常”。
- C. 以一次成功请求作为结论，不再确认“UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作”是否成立。
- D. 先验证“业务应检查 IdentityResult.Errors，不能只看是否抛异常”，再依据“UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“注册接口向客户端返回成功但数据库无用户”指向 UserManager，但症状本身不能证明根因。正确排查应先确认边界“业务应检查 IdentityResult.Errors，不能只看是否抛异常”，再用主规则“UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作”解释证据。直接采用误区“CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0563 关于 UserManager，以下哪项说法不成立？
难度： 实战
- A. UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作
- B. 业务应检查 IdentityResult.Errors，不能只看是否抛异常
- C. CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建
- D. 出现“注册接口向客户端返回成功但数据库无用户”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建”正是 UserManager 的典型误区。其余三项分别给出了主规则“UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作”、适用边界“业务应检查 IdentityResult.Errors，不能只看是否抛异常”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0564 针对“注册接口向客户端返回成功但数据库无用户”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作”修正实现，并用测试或遥测验证“业务应检查 IdentityResult.Errors，不能只看是否抛异常”。
- B. 按“CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建”修改实现，并把一次请求成功作为验收结果。
- C. 按“UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作”修改代码后直接上线，不验证“业务应检查 IdentityResult.Errors，不能只看是否抛异常”。
- D. 只验证“业务应检查 IdentityResult.Errors，不能只看是否抛异常”，但实现仍继续依赖“CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：UserManager 封装用户创建、密码、Claim、角色和令牌等身份存储操作；并确认 业务应检查 IdentityResult.Errors，不能只看是否抛异常。继续接受“CreateAsync 返回后即使 Result.Failed 也表示用户已成功创建”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“注册接口向客户端返回成功但数据库无用户”这一生产场景能否安全上线。
0565 在 SignInManager 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. PasswordSignInAsync 返回 false 只可能是密码错误
- B. PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态
- C. SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程
- D. 观察到“被锁定用户被错误记录为无效密码”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 SignInManager 的主规则：SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程。选项“PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态”是使用规则时要验证的边界，不是规则本身；“PasswordSignInAsync 返回 false 只可能是密码错误”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0566 被锁定用户被错误记录为无效密码。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“PasswordSignInAsync 返回 false 只可能是密码错误”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态”。
- C. 以一次成功请求作为结论，不再确认“SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程”是否成立。
- D. 先验证“PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态”，再依据“SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“被锁定用户被错误记录为无效密码”指向 SignInManager，但症状本身不能证明根因。正确排查应先确认边界“PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态”，再用主规则“SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程”解释证据。直接采用误区“PasswordSignInAsync 返回 false 只可能是密码错误”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0567 关于 SignInManager，以下哪项说法不成立？
难度： 实战
- A. PasswordSignInAsync 返回 false 只可能是密码错误
- B. SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程
- C. PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态
- D. 出现“被锁定用户被错误记录为无效密码”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“PasswordSignInAsync 返回 false 只可能是密码错误”正是 SignInManager 的典型误区。其余三项分别给出了主规则“SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程”、适用边界“PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0568 针对“被锁定用户被错误记录为无效密码”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“PasswordSignInAsync 返回 false 只可能是密码错误”修改实现，并把一次请求成功作为验收结果。
- B. 按“SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程”修正实现，并用测试或遥测验证“PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态”。
- C. 按“SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程”修改代码后直接上线，不验证“PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态”。
- D. 只验证“PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态”，但实现仍继续依赖“PasswordSignInAsync 返回 false 只可能是密码错误”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：SignInManager 处理密码登录、外部登录、双因素和锁定等登录流程；并确认 PasswordSignInAsync 结果需区分成功、锁定、需双因素和禁止登录等状态。继续接受“PasswordSignInAsync 返回 false 只可能是密码错误”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“被锁定用户被错误记录为无效密码”这一生产场景能否安全上线。
0569 在 密码哈希 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 密码哈希可通过管理员密钥解密回原密码
- B. 密码哈希用于验证而非解密，不能把密码或哈希写入日志
- C. 观察到“客服系统要求显示用户原密码”即可把一次现象当成完整框架契约。
- D. IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希
查看答案与解析
正确答案D
正确答案直接描述 密码哈希 的主规则：IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希。选项“密码哈希用于验证而非解密，不能把密码或哈希写入日志”是使用规则时要验证的边界，不是规则本身；“密码哈希可通过管理员密钥解密回原密码”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0570 客服系统要求显示用户原密码。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“密码哈希可通过管理员密钥解密回原密码”定性，不再检查配置、身份或运行时证据。
- B. 先验证“密码哈希用于验证而非解密，不能把密码或哈希写入日志”，再依据“IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“密码哈希用于验证而非解密，不能把密码或哈希写入日志”。
- D. 以一次成功请求作为结论，不再确认“IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希”是否成立。
查看答案与解析
正确答案B
场景“客服系统要求显示用户原密码”指向 密码哈希，但症状本身不能证明根因。正确排查应先确认边界“密码哈希用于验证而非解密，不能把密码或哈希写入日志”，再用主规则“IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希”解释证据。直接采用误区“密码哈希可通过管理员密钥解密回原密码”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0571 关于 密码哈希，以下哪项说法不成立？
难度： 实战
- A. IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希
- B. 密码哈希用于验证而非解密，不能把密码或哈希写入日志
- C. 密码哈希可通过管理员密钥解密回原密码
- D. 出现“客服系统要求显示用户原密码”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“密码哈希可通过管理员密钥解密回原密码”正是 密码哈希 的典型误区。其余三项分别给出了主规则“IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希”、适用边界“密码哈希用于验证而非解密，不能把密码或哈希写入日志”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0572 针对“客服系统要求显示用户原密码”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希”修正实现，并用测试或遥测验证“密码哈希用于验证而非解密，不能把密码或哈希写入日志”。
- B. 按“密码哈希可通过管理员密钥解密回原密码”修改实现，并把一次请求成功作为验收结果。
- C. 按“IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希”修改代码后直接上线，不验证“密码哈希用于验证而非解密，不能把密码或哈希写入日志”。
- D. 只验证“密码哈希用于验证而非解密，不能把密码或哈希写入日志”，但实现仍继续依赖“密码哈希可通过管理员密钥解密回原密码”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：IPasswordHasher 使用带盐、版本化的密码哈希格式，并可在验证后建议重新哈希；并确认 密码哈希用于验证而非解密，不能把密码或哈希写入日志。继续接受“密码哈希可通过管理员密钥解密回原密码”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“客服系统要求显示用户原密码”这一生产场景能否安全上线。
0573 在 安全戳 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效
- B. 更新安全戳会立即远程删除所有浏览器 Cookie
- C. 失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出
- D. 观察到“改密码后另一个设备短时间仍保持登录”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 安全戳 的主规则：SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效。选项“失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出”是使用规则时要验证的边界，不是规则本身；“更新安全戳会立即远程删除所有浏览器 Cookie”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0574 改密码后另一个设备短时间仍保持登录。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“更新安全戳会立即远程删除所有浏览器 Cookie”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出”。
- C. 先验证“失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出”，再依据“SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效”是否成立。
查看答案与解析
正确答案C
场景“改密码后另一个设备短时间仍保持登录”指向 安全戳，但症状本身不能证明根因。正确排查应先确认边界“失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出”，再用主规则“SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效”解释证据。直接采用误区“更新安全戳会立即远程删除所有浏览器 Cookie”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0575 关于 安全戳，以下哪项说法不成立？
难度： 实战
- A. SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效
- B. 更新安全戳会立即远程删除所有浏览器 Cookie
- C. 失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出
- D. 出现“改密码后另一个设备短时间仍保持登录”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“更新安全戳会立即远程删除所有浏览器 Cookie”正是 安全戳 的典型误区。其余三项分别给出了主规则“SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效”、适用边界“失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0576 针对“改密码后另一个设备短时间仍保持登录”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“更新安全戳会立即远程删除所有浏览器 Cookie”修改实现，并把一次请求成功作为验收结果。
- B. 按“SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效”修改代码后直接上线，不验证“失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出”。
- C. 只验证“失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出”，但实现仍继续依赖“更新安全戳会立即远程删除所有浏览器 Cookie”。
- D. 按“SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效”修正实现，并用测试或遥测验证“失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：SecurityStamp 可表示凭据或安全状态变化，并用于使旧会话在重新验证后失效；并确认 失效速度取决于验证间隔和票据流程，不是修改后所有请求瞬时登出。继续接受“更新安全戳会立即远程删除所有浏览器 Cookie”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“改密码后另一个设备短时间仍保持登录”这一生产场景能否安全上线。
0577 在 Identity 令牌 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 邮箱确认令牌可以安全地复用于密码重置
- B. 密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护
- C. 令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌
- D. 观察到“泄露的确认链接被用于其他敏感操作”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 Identity 令牌 的主规则：密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护。选项“令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌”是使用规则时要验证的边界，不是规则本身；“邮箱确认令牌可以安全地复用于密码重置”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0578 泄露的确认链接被用于其他敏感操作。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌”，再依据“密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护”判断实现是否符合契约。
- B. 直接按“邮箱确认令牌可以安全地复用于密码重置”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌”。
- D. 以一次成功请求作为结论，不再确认“密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护”是否成立。
查看答案与解析
正确答案A
场景“泄露的确认链接被用于其他敏感操作”指向 Identity 令牌，但症状本身不能证明根因。正确排查应先确认边界“令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌”，再用主规则“密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护”解释证据。直接采用误区“邮箱确认令牌可以安全地复用于密码重置”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0579 关于 Identity 令牌，以下哪项说法不成立？
难度： 实战
- A. 密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护
- B. 令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌
- C. 出现“泄露的确认链接被用于其他敏感操作”时，应收集证据并同时核对主规则与适用边界。
- D. 邮箱确认令牌可以安全地复用于密码重置
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“邮箱确认令牌可以安全地复用于密码重置”正是 Identity 令牌 的典型误区。其余三项分别给出了主规则“密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护”、适用边界“令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0580 针对“泄露的确认链接被用于其他敏感操作”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“邮箱确认令牌可以安全地复用于密码重置”修改实现，并把一次请求成功作为验收结果。
- B. 按“密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护”修改代码后直接上线，不验证“令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌”。
- C. 按“密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护”修正实现，并用测试或遥测验证“令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌”。
- D. 只验证“令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌”，但实现仍继续依赖“邮箱确认令牌可以安全地复用于密码重置”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：密码重置、邮箱确认等令牌由用户、目的和安全状态等信息保护；并确认 令牌应一次性语义使用、限制有效期并通过正确 Purpose 验证，不能当长期访问令牌。继续接受“邮箱确认令牌可以安全地复用于密码重置”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“泄露的确认链接被用于其他敏感操作”这一生产场景能否安全上线。