如何在 WCF 中上传文件以及识别凭据?

发布于 2024-09-01 20:29:39 字数 828 浏览 8 评论 0原文

我遇到了 WCF、流媒体和安全性方面的问题,这并不是最严重的问题,但我想了解人们对如何解决这个问题的想法。

我需要允许客户端将文件上传到服务器,并且我通过使用BasicHttpBinding 的transferMode="StreamedRequest" 功能来允许此操作。当他们上传文件时,我想以事务方式将此文件放置在文件系统中,并使用该文件的元数据更新数据库(我实际上使用的是 Sql Server 2008 的 FILESTREAM 数据类型,它本身支持此功能)。我正在使用 WCF Windows 身份验证并将 Kerberos 凭据委托给 SQL Server 以进行所有数据库身份验证。

问题是,正如我得到的异常提示,“HTTP 请求流不能与 HTTP 身份验证结合使用。”因此,对于我的上传文件服务,我无法将 Windows 身份验证令牌与消息调用一起传递。即使我没有使用 SQL Server 登录,我什至无法通过 Windows 凭据识别我的调用客户端。

我暂时解决了这个问题,方法是让上传方法不安全,并将文件转储到临时存储并返回定位器 GUID。然后,客户端第二次调用安全的非流式服务,传递 GUID,该服务使用 Windows 身份验证将文件从临时存储上传到数据库。

显然,这并不理想。从性能的角度来看,我正在对磁盘进行额外的读/写操作。从可扩展性的角度来看,(原则上,使用负载平衡器)不能保证我通过两个后续调用访问同一服务器,这意味着临时文件存储需要位于共享位置,这意味着不是可扩展的设计。

有人能想出更好的方法来处理这种情况吗?就像我说的,这不是最重要的,因为 a) 我真的不需要太多扩展这个东西,没有太多用户,b) 它不像这些上传/下载被大量调用。但是,我仍然想知道我是否在这里缺少一个明显的解决方案。

谢谢, 丹尼尔

I've got an issue with WCF, streaming, and security that isn't the biggest deal but I wanted to get people's thoughts on how I could get around it.

I need to allow clients to upload files to a server, and I'm allowing this by using the transferMode="StreamedRequest" feature of the BasicHttpBinding. When they upload a file, I'd like to transactionally place this file in the file system and update the database with the metadata for the file (I'm actually using Sql Server 2008's FILESTREAM data type, that natively supports this). I'm using WCF Windows Authentication and delegating the Kerberos credentials to SQL Server for all my database authentication.

The problem is that, as the exception I get helpfully notes, "HTTP request streaming cannot be used in conjunction with HTTP authentication." So, for my upload file service, I can't pass the Windows authentication token along with my message call. Even if I weren't using SQL Server logins, I wouldn't even be able to identify my calling client by their Windows credentials.

I've worked around this temporarily by leaving the upload method unsecured, and having it dump the file to a temporary store and return a locator GUID. The client then makes a second call to a secure, non-streaming service, passing the GUID, which uploads the file from the temporary store to the database using Windows authentication.

Obviously, this isn't ideal. From a performance point of view, I'm doing an extra read/write to the disk. From a scalability point of view, there's (in principle, with a load balancer) no guarantee that I hit the same server with the two subsequent calls, meaning that the temporary file store needs to be on a shared location, meaning not a scalable design.

Can anybody think of a better way to deal with this situation? Like I said, it's not the biggest deal, since a) I really don't need to scale this thing out much, there aren't too many users, and b) it's not like these uploads/downloads are getting called a lot. But still, I'd like to know if I'm missing an obvious solution here.

Thanks,
Daniel

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文