基于Codeigniter和Aauth的SaaS跨账号用户注册架构方案问询

针对你在小型SaaS产品中遇到的「同一用户需在不同Account下注册，但Aauth强制邮箱唯一」的问题，结合你试过的方案缺陷，我整理了几个实操性强的架构思路，既能保留Aauth的核心功能，又不用大规模修改源码或做冗余的系统复制：

方案1：利用Aauth钩子扩展，新增账号关联字段 #

架构调整 #

• 在Aauth默认的users表中新增account_id字段（关联你的tbl_Accounts表主键）
• 给users表添加联合唯一约束：UNIQUE(email, account_id)，这样同一邮箱在不同账号下可以重复，同一账号下依然保持唯一

适配Aauth的核心逻辑（无需修改源码） #

Aauth自带钩子（hooks）机制，我们可以通过钩子拦截注册和登录流程，不用动核心源码：

1. 注册阶段：启用before_register钩子，自定义校验逻辑——检查email + account_id的组合是否已存在，而非单纯校验邮箱唯一
   • 在application/config/aauth.php中开启钩子：$config['hooks'] = true;
   • 编写钩子回调函数，比如在application/hooks/AauthExtend.php中：

     function check_unique_email_per_account($params) {
         $aauth = get_instance()->aauth;
         $account_id = get_instance()->input->post('account_id'); // 注册时需传入所属账号ID
         $exists = $aauth->db->where('email', $params['email'])
                             ->where('account_id', $account_id)
                             ->get($aauth->db_table['users'])->num_rows();
         if ($exists) {
             $aauth->set_error('此邮箱在当前账号下已注册');
             return false;
         }
         return true;
     }
     

   • 在config/hooks.php中注册钩子：

     $hook['before_register'] = array(
         'function' => 'check_unique_email_per_account',
         'filename' => 'AauthExtend.php',
         'filepath' => 'hooks'
     );
     

2. 登录阶段：登录时需要用户选择所属账号（或从上下文自动获取），验证时拼接account_id条件，比如重写登录方法：

   function custom_login($email, $password, $account_id) {
       $aauth = $this->aauth;
       $user = $aauth->db->where('email', $email)
                         ->where('account_id', $account_id)
                         ->get($aauth->db_table['users'])->row();
       if ($user && password_verify($password, $user->pass)) {
           $aauth->login_as($user->id); // 复用Aauth原生登录方法
           return true;
       }
       $aauth->set_error('邮箱/密码或账号错误');
       return false;
   }
   

优缺点 #

• ✅ 无需修改Aauth核心源码，低侵入性
• ✅ 数据结构简洁，维护成本低
• ❌ 需要调整注册/登录的前端交互（让用户选择或切换账号）

方案2：拆分认证凭证与用户真实信息 #

架构调整 #

• 保留Aauth的users表作为认证凭证表，但email字段存储「真实邮箱+账号标识」的组合（比如user@example.com:account_123）
• 新增user_profiles表，存储用户真实邮箱、姓名等业务信息，关联users.id和account_id

适配逻辑（完全兼容Aauth） #

1. 注册阶段：用户输入真实邮箱后，系统自动拼接当前账号的唯一标识（如账号ID或slug），生成复合邮箱存入users表，同时把真实信息存入user_profiles
2. 登录阶段：用户输入真实邮箱和密码后，系统根据当前选中的账号拼接复合邮箱，直接调用Aauth原生login方法验证
3. 显示逻辑：所有面向用户的场景（如个人中心、邮件通知），都从user_profiles取真实邮箱，用户完全感知不到复合邮箱的存在

优缺点 #

• ✅ 完全兼容Aauth所有原生功能，不用改任何源码
• ✅ 用户体验无感知
• ❌ 需要在注册/登录的入口层做邮箱拼接处理，增加一层转换逻辑

方案3：多租户数据库分组（适合数据隔离要求高的场景） #

架构调整 #

• 给每个Account配置独立的数据库分组（在application/config/database.php中新增多个数据库配置项）
• 初始化Aauth时，根据当前请求的Account标识，切换对应的数据库连接

适配逻辑 #

1. 在CodeIgniter的全局前置钩子中，根据当前域名/账号ID切换数据库连接：

   function switch_account_db() {
       $CI =& get_instance();
       $account_id = $CI->session->userdata('current_account_id'); // 从会话或请求参数获取
       $CI->load->database("account_{$account_id}", false, true);
       // 重置Aauth的数据库连接实例
       $CI->aauth->db = $CI->db;
   }
   

2. 每个Account的Aauth数据（users、groups等）完全隔离，各自的users表依然保持邮箱唯一，但不同账号之间互不影响

优缺点 #

• ✅ 数据隔离性极强，适合对数据安全要求高的场景
• ✅ 不用修改Aauth任何逻辑
• ❌ 数据库维护成本较高（备份、迁移需处理多个库）
• ❌ 仅适合Account数量不多的SaaS产品

方案对比与选型建议 #

• 如果你的SaaS账号数量多、对代码侵入性要求低：优先选方案1
• 如果想完全保留Aauth的所有功能、不想动核心逻辑：选方案2
• 如果对数据隔离要求极高、账号数量少：选方案3

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