【问题标题】:Connecting Windows Service with Web Api?使用 Web API 连接 Windows 服务?
【发布时间】:2019-07-21 19:02:58
【问题描述】:

我目前有一个网站(reactjs)和一个 asp.net 核心 api。现在我的核心 api 中的所有端点都受到“授权”标签的保护。用户将登录并颁发令牌/刷新令牌,并将在每个请求中发送。

现在我正在构建一个需要访问我的数据库的 Windows 服务。我真的不认为这项服务直接访问数据库是一个好主意,我认为最好有一个可以访问数据库的端点(即 web api)。

现在这让我弄清楚我的 Windows 服务将如何连接到我的 api。我能想到的唯一方法是创建一个将登录的假用户,然后每次我的服务需要连接到 api 时,它都会发送该令牌。

否则我想我将不得不制作某种 api 密钥之类的东西?

【问题讨论】:

  • 您使用什么来验证用户身份?身份服务器?您可以使用ClientCredentials 通过 API 对服务进行身份验证吗?
  • 我正在使用 asp.net 核心身份。
  • 在这种情况下你最终做了什么?

标签: api authentication asp.net-core jwt asp.net-core-webapi


【解决方案1】:

因此,如果我们正在讨论解决方案 - 请在下面为您提供建议的解决方案。

真正的问题是确保您的核心 API 了解传入的请求是有效的,而不必以当前形式过多地重构 API。

您对 API 密钥的想法是我会考虑做的事情,您可以在您的 API 中编写一个中间件,该中间件将从 Windows 服务发送的标头中读取 Api 密钥,对其进行验证,然后生成一个有效的 JWT 令牌并添加它到请求标头。一旦该请求到达 MVC 层,它将包含一个有效的 JWT 令牌并传递 Auth 标头。

这引入了复杂性,因为必须在数据库中维护一组 API 密钥并在请求级别验证它们。这意味着发送的每个请求都必须经过这个过程并为密钥进行数据库查找。

为了缓解这种情况,我将添加另一个标头,指示传入请求来自用户以外的其他来源(在中间件中检查),并可能在 api 键集上添加缓存实现以将它们保留在内存中以减少查找.

如果您的 Windows 服务需要执行与用户完全相同的操作,上述场景将非常有用。

如果它的不同逻辑没有什么能阻止您使用您可以为该控制器定义的自己的授权策略为您的服务定制端点的新控制器。然后,该控制器将负责为 Windows 服务(或其他组件)提供服务。

【讨论】:

  • 是的,我认为 API Keys 是要走的路,但现在我们没有立即计划向外部应用程序开放我们的 api,所以这一切都只是为了这项服务,所以我不是确定此时是否值得它似乎要做的工作量。制作一个新的控制器并拥有自己的策略可能是一种选择,但我不知道检查将是什么以确保它确实是服务。
猜你喜欢
  • 2014-04-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-10-28
  • 2012-06-23
相关资源
最近更新 更多