为何context.getUser().getMail()返回null？跨Domino服务器xPage访问问题排查

我来帮你搞定这个跨服务器的xPage用户邮件地址获取问题，这种差异通常和服务器配置、数据库权限或者用户目录访问有关，咱们一步步排查解决：

一、服务器层面的配置差异排查 #

• Domino目录访问配置：首先确认出问题的服务器能不能正常访问正确的names.nsf。如果两台服务器用的不是同一个目录，或者出问题的服务器配置了Directory Assistance（目录辅助）但指向了缺少用户邮件字段的目录，就会导致获取不到。你可以检查服务器文档里的“目录”设置，确保和正常服务器一致。
• 身份验证方式一致性：如果服务器用了Web SSO，要确认出问题的服务器的Internet Site文档里的身份验证配置（比如SSO密钥、认证类型）和正常服务器完全匹配。如果SSO配置有问题，用户身份无法被正确解析，context.getUser()拿到的就是不完整的用户对象。
• 匿名访问限制：检查服务器文档的“Internet协议”→“HTTP”部分，确认是否开启了“允许匿名访问”。如果用户是匿名访问的话，context.getUser()会直接返回null，但如果是已登录用户出现这个问题，这条可以作为辅助排查点。

二、数据库ACL的关键调整 #

• 用户权限与身份确认：确保当前用户在数据库ACL里有至少读者权限，且不是以“匿名”身份访问。另外，ACL里的用户条目要关联到Domino目录中的有效个人文档，避免使用本地个人条目（如果数据库是从正常服务器复制过来的，可能ACL条目未同步）。
• 读取公共文档权限：在ACL的“高级”设置里，务必勾选“读取公共文档”选项。因为用户的邮件地址存储在names.nsf的公共个人文档中，数据库需要这个权限才能访问目录里的用户属性，正常服务器应该是已经勾选的。
• 继承服务器权限：检查数据库属性的“高级”标签，确认“继承服务器权限”选项是否开启。如果未开启，数据库可能无法继承服务器访问names.nsf的权限，导致无法读取用户邮件字段。

三、用Session对象获取邮件地址的替代方案 #

当然可以通过Session对象获取，这里给你几个可靠的方法：

1. 通过用户名查询目录文档：
   先拿到当前有效用户名，再去names.nsf中查询对应个人文档的邮件字段，代码示例：

   String userName = session.getEffectiveUserName();
   Database dirDb = session.getDatabase("", "names.nsf");
   if (dirDb != null && dirDb.isOpen()) {
       View peopleView = dirDb.getView("($People)");
       Document personDoc = peopleView.getDocumentByKey(userName, true);
       if (personDoc != null) {
           String userMail = personDoc.getItemValueString("Mail");
           // 后续逻辑
           personDoc.recycle();
       }
       peopleView.recycle();
       dirDb.recycle();
   }
   

   注意要做好资源回收和异常判断，避免空指针。
2. 直接调用Session的用户对象：
   试试session.getUser().getMail()，它和context.getUser()底层逻辑类似，但Session直接关联当前会话的用户身份，有时候比Context更稳定，你可以替换测试下。

四、额外排查点 #

• 用户文档完整性：在出问题的服务器的names.nsf中，找到当前用户的个人文档，确认“邮件”字段是否有值。如果用户文档本身就缺失这个字段，那不管用什么方法都拿不到，这时候需要补全用户文档。
• 目录复制状态：如果两台服务器的names.nsf是复制关系，检查复制任务是否正常运行，确认用户文档的邮件字段已经同步到出问题的服务器。

内容的提问来源于stack exchange，提问作者John Glabb