跨服务器脚本通过REST API更新SharePoint列表的认证与实现问询

针对你的场景，我分SharePoint 2013 Foundation和SharePoint Online两个版本，结合你的Node/PHP定时脚本需求，梳理最适合的方案，帮你理清认证、API适配和项目启动的问题：

你的核心困惑是认证方式和是否需要Add-in注册，这里给你两个可选方向：

选项1：AD用户账号认证（最简便，优先推荐） #

如果你的脚本运行在域内服务器，或者可以访问域控制器，这个方案完全不需要注册任何Add-in，直接用域账号的权限调用REST API：

• 实现方式：
  • Node.js：用sp-request库（封装了NTLM认证），或者axios配合ntlm-client手动添加认证头，直接调用SP2013的REST端点，比如：

    const spRequest = require('sp-request').create({
      username: 'DOMAIN\\username',
      password: 'your-password'
    });
    spRequest.post('http://sp2013-site/_api/web/lists/getbytitle(\'YourList\')/items', {
      body: { __metadata: { type: 'SP.Data.YourListListItem' }, Title: 'New Item' },
      headers: { 'Content-Type': 'application/json;odata=verbose' }
    });
    

  • PHP：用curl设置NTLM认证，示例：

    $ch = curl_init('http://sp2013-site/_api/web/lists/getbytitle(\'YourList\')/items');
    curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_NTLM);
    curl_setopt($ch, CURLOPT_USERPWD, 'DOMAIN\\username:your-password');
    // 其他POST参数、请求头设置...
    curl_exec($ch);
    

• 注意：确保使用的域账号拥有目标列表的编辑权限，这种方式没有额外配置成本，适合快速落地。

选项2：High-trust证书认证（更安全，适合非域环境） #

如果脚本不在域内运行，或者不想暴露用户账号密码，这个方案需要注册Add-in：

• 必须在SP2013服务器上运行PowerShell脚本注册Add-in，生成客户端ID并关联证书，建立服务器与Add-in的信任关系。
• 实现上，Node.js可以用node-sp-auth库的high-trust模式，PHP则需要手动处理证书签名的SAML断言，相对复杂。
• 优势：不需要用户账号密码，适合跨域或无人值守的非域环境，但配置成本比AD认证高。

重点纠正你的一个误解：你的项目1是纯后台定时脚本，完全不需要注册Provider Hosted Add-in——Provider Hosted Add-in是为带前端界面的应用设计的，纯后台服务用下面的方案更高效：

选项1：Azure AD应用权限认证（最优推荐） #

这是微软现在主推的后台服务认证方式，比ACS更现代、更安全：

• 步骤：
  1. 在Azure AD中注册一个应用，授予Sites.ReadWrite.All（或更细粒度的列表编辑权限）的应用权限（不是委托权限）。
  2. 生成客户端密钥（Client Secret）或证书，用于获取访问令牌。
  3. 脚本通过Azure AD令牌端点获取令牌，然后调用SPO的REST API。
• 实现示例（Node.js）：

  const { PublicClientApplication } = require('@azure/msal-node');
  const msalConfig = {
    auth: {
      clientId: 'your-app-client-id',
      authority: 'https://login.microsoftonline.com/your-tenant-id',
      clientSecret: 'your-client-secret'
    }
  };
  const pca = new PublicClientApplication(msalConfig);
  // 获取令牌
  const tokenResponse = await pca.acquireTokenByClientCredential({
    scopes: ['https://your-tenant.sharepoint.com/.default']
  });
  // 调用SPO REST API
  await axios.post('https://your-tenant.sharepoint.com/sites/yoursite/_api/web/lists/getbytitle(\'YourList\')/items', 
    { __metadata: { type: 'SP.Data.YourListListItem' }, Title: 'New Item' },
    { headers: { Authorization: `Bearer ${tokenResponse.accessToken}` } }
  );
  

• 优势：无需用户交互，权限长期有效，适合定时任务，且可以精确控制应用的访问范围，没有多余的前端托管需求。

选项2：用户账号认证（简便，适合测试/小场景） #

如果是测试环境或者小体量任务，可以用普通SPO用户账号认证：

• 非MFA账号可以用密码流获取令牌，但微软不推荐（密码泄露风险高）；MFA账号需要用设备码流，不适合无人值守的定时任务。
• 实现上Node.js用node-sp-auth的modern auth模式，PHP用OAuth2库对接Azure AD。

选项3：Provider Hosted Add-in + ACS（不推荐） #

虽然这个方案可行，但ACS是旧的认证体系，微软已经逐步淘汰，而且需要配置前端托管站点，对于纯后台脚本来说完全是冗余的复杂度，不建议采用。

• 启动方式：
  • Node.js：用node-schedule库在脚本内实现定时，或者用服务器的crontab（Linux）、任务计划程序（Windows）定时运行脚本。
  • PHP：直接用服务器的crontab或Windows任务计划执行php your-script.php即可，不需要任何前端部署。
• 跨版本兼容：可以把认证逻辑抽象成独立模块，根据环境变量（比如SP_ENV=2013或SP_ENV=ONLINE）切换认证方式，业务逻辑（拉取第三方数据、构造列表项）保持一致，半年后迁移到SPO时只需要修改认证模块即可。

你提到的SPFX React应用展示数据的思路是对的，SPFX可以直接调用SPO的REST API（用内置的spHttpClient自动处理认证），和项目1的后台推送完全独立，互不影响。

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