我最近发布了一个关于在Web应用程序中运行的Windows Workflow的问题.当然,这是一个相当技术性的问题,包含像ManualWorkflowSchedulerService,HandleExtrenalEvent等术语......它在20天的过程中得到了大约15个视图.
虽然我很可能不会以正确的方式提出问题,但它让我想到了在现实世界的应用程序中采用Windows工作流程,特别是在Web应用程序中.
您是否已经成功实施了WF的现实互联网应用程序并回顾过去,您的时间(金钱)投资是否得到了回报？
在MS SQL Server中,"数据库属性"对话框左侧有"查看连接属性"链接.单击该按钮将显示"连接属性"对话框,其中包含当前连接的属性,例如身份验证方法,网络协议,计算机名称等...
有没有办法通过运行SQL查询以编程方式获取该信息？那个查询会是什么样的？
您使用什么样的SQL技巧将数据输入到两个表中,其中包含循环引用.
Employees
EmployeeID <PK>
DepartmentID <FK> NOT NULL
Departments
DepartmentID <PK>
EmployeeID <FK> NOT NULL
员工属于某个部门,部门必须有经理(部门主管).
我是否必须禁用插入的约束？
有许多商业产品,它们为您提供了一个基于Windows的安装程序,用于配置您的应用程序和后端SQL Server数据库.通常,它会询问您是否要使用Windows或SQL Server身份验证连接到数据库.他们中的大多数建议使用Windows Auth,然后使用分配给db_owner数据库角色的网络服务帐户配置数据库.我了解Windows身份验证更安全,因为您不必在web.config中存储凭据并在对SQL Server进行身份验证时通过网络发送凭据,但这是生产环境的安全配置,其中网络服务帐户是或db_owner？我们应该注意哪些特定的风险？
谢谢StingyJack,
我听到你在说什么,他们必须首先以网络服务用户身份登录数据库.有一个简单的方法吗？
我真正想弄清楚的是,是否存在任何固有的风险,因为它是分配了db_owner角色的默认网络服务帐户.
正如最初在这里宣布的那样，谷歌似乎一直在为原生应用程序实现 OAuth 交互的现代化 https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
并且正如他们当前的文档页面所证明的那样 https://developers.google.com/identity/protocols/OAuth2InstalledApp
我已经能够在引用的 github 存储库中成功运行示例控制台应用程序。
此流程使用客户端密码和其他参数交换访问令牌的授权代码。但是，众所周知（并且如参考文章中所述）客户端机密无法安全地存储在已安装的应用程序中。同一篇文章以下列方式陈述了这一事实
该过程会生成一个客户端 ID，在某些情况下还会生成一个客户端机密，您将其嵌入到应用程序的源代码中。（在这种情况下，客户端机密显然不被视为机密。）
因此，如果此流程是已安装应用程序的推荐流程，我们是否应该不必担心保护 client_secret 并将其嵌入到应用程序中？如果是这样，那么这个流程是怎么做到的？
此外，如示例所示，随机的 http 重定向 url 是在本地生成的，该 URL 未在 Google Developer Console 的 Credentials 页面中的任何位置注册。这与 Azure AD 不同，在 Azure AD 中，您必须在注册本机应用程序时具体说明重定向 uri。