Chainlit项目中Azure存储认证时间问题的分析与解决

在Chainlit项目的2.1.0版本中，开发团队发现了一个与Azure Blob存储认证相关的关键问题。这个问题影响了用户在恢复线程后查看或下载文件的功能，导致系统返回认证失败的错误信息。

问题现象

当用户尝试在恢复的线程中点击文件进行查看或下载时，系统会返回一个Azure存储认证错误。错误信息明确指出签名在当前时间范围内无效，具体表现为服务器无法验证请求，提示Authorization头的值（包括签名）未正确形成。

根本原因分析

经过深入排查，发现问题出在data/storage_clients/azure_blob.py文件中的get_read_url函数实现上。该函数在生成账户SAS签名时使用了本地时间而非UTC时间，而Azure存储服务要求所有时间参数必须基于UTC时区。

具体来说，原始代码使用了datetime.now()获取当前时间，这返回的是本地时区的时间值。然而Azure存储服务的generate_account_sas方法明确要求传入的start参数必须是UTC时间。

解决方案

修复方案相对简单但关键：将时间获取方式从本地时间改为UTC时间。具体修改包括：

1. 从datetime模块中额外导入timezone类
2. 使用datetime.now(tz=timezone.utc)替代原有的datetime.now()

这一修改确保了生成签名时使用的时间戳与Azure存储服务预期的时间格式完全一致。

影响范围

该问题主要影响以下场景：

• 使用官方数据层并配置了Azure Storage后端的系统
• 尝试在恢复的线程中访问文件内容的操作
• 跨时区部署的系统（因为本地时间与时区相关）

版本修复情况

此问题已在Chainlit 2.1.1版本中得到修复。对于仍在使用2.1.0版本的用户，建议尽快升级到最新版本以获得稳定的文件访问功能。

开发者启示

这个案例提醒我们，在处理云服务API时，特别是涉及安全认证和时间敏感操作时，必须严格遵循服务提供商的技术规范。时区处理是分布式系统中常见的陷阱之一，开发者应当养成在涉及时间操作时明确指定时区的好习惯，特别是在与云服务交互的场景下，UTC时间通常是唯一被接受的标准。