问题标签 [credentials]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
python - 我的谷歌应用引擎部署的源代码安全吗?
我正在考虑存储第三方凭据的好方法,这基本上意味着在某个地方需要有一个秘密,无论是在代码中还是在数据中。我正在谷歌应用引擎上部署。
如果“秘密”是这样的
我可以依赖非 appengine 管理员从未见过的这段代码吗?
...如果凭证保护诸如个人财务数据之类的超级敏感信息,我们仍然信任它吗?
(sha2 位可与任何其他秘密伪随机函数交换。)
asp.net - WCF 服务 - ASP.net 托管 - 单点登录,如何传递凭据
我的情况是这样的——我有两个 ASP.net 网站。两个站点都在同一台机器上运行,我使用默认的 asp.net 成员提供程序(基于表单的身份验证)相对简单地实现了单点登录。
我在一个站点上有一个新的 WCF 服务,它将从另一个站点调用。用户将登录到该站点,但将在回发后从代码隐藏中调用该服务。
有人可以指出我正确的方向,以便我可以将登录用户的基于表单的凭据传递到另一个站点上的 WCF 服务吗?目前它正在通过 NETWORKSERVICE windows 凭据。
active-directory - 处理 100 万个用户帐户的 Web 服务
想象一下,你正在编写一个拥有 100 万用户的 Web 应用程序(他们都长得那么大,对吧!)
您将如何处理用户帐户?我可以想象几个场景:
- 滚动您自己的(数据库表、存储在用户配置文件表中的加盐/散列密码)
- 如果使用 ASP.NET 编写,请使用登录/角色提供程序(回退到数据库)
- 如果在 Windows 环境中,请使用 Active Directory
- 使用其他一些 LDAP 服务器
- 第三方提供商,如 OpenID 或 .NET Passport
稳定性和可扩展性当然很重要。
我想这确实是一个问题,即 Active Directory 和其他 LDAP 服务器是否能够很好地轻松扩展。Facebook、Twitter 和 Gmail 使用什么作为其后端帐户提供商?
让我想到这一点的是 Google App Engine。看起来真的很酷。但是,如果我使用内置的身份验证内容,用户将需要获得一个 Google 帐户。或者使用上面的#5,用户需要去获取一个 OpenID。我正在努力做到这一点,这样他们就可以在我的网站上进行简单的注册,而无需访问其他网站——对于世界上的非极客来说:)
c# - 使用凭据和代理时响应 401(调用 Web 服务)
我使用 VB.NET 2.0。
我正在尝试调用 Web 服务。此 Web 服务需要身份验证。因此,我只能在使用凭据时执行 Web 服务。但是,当我添加本地代理(我尝试使用 ezProxy Manager)时,我收到 401 错误。
我也需要使用代理来解决这个问题。任何想法为什么这可能会失败?
c# - Internet Explorer 的绕过凭据对话框
我的 c# 应用程序为不同的 Web URL/域打开 Internet Explorer。我将所有这些凭据信息(用户名、密码和域名)存储在每个 Web 应用程序的数据库中。现在如何在不使用代码在“网络凭据”对话框中输入凭据或绕过该对话框的情况下自动进行身份验证?换句话说,我需要将这些凭据存储在系统上,因此无需输入。我正在使用 C#
windows - Win32:CredUIConfirmCredentials 行为异常
我将CredUIConfirmCredentials与 CredUIPromptForCredentials结合使用。
我设置了, 并且当用户首次提供EXPECT_CONFIRMATION
凭据时,调用返回NO_ERROR按预期。CredUIConfirmCredentials
CredUIConfirmCredentials
但是,在使用相同凭据的所有后续调用中,将返回ERROR_INVALID_PARAMETER。SDK 文档将其描述为:
尝试确认等待的凭据失败,因为凭据包含无效或不一致的数据。
这相当令人困惑,因为它们与最初成功保存的凭据完全相同。
如果您为相同的用户名输入不同的密码,则会返回相同的结果。更令人困惑的是,新凭据实际上是持久化的——这似乎表明返回值实际上表明持久化的凭据被覆盖了——而不是存在错误。我错过了什么,还是文档不正确?
背景
您可以使用 Window 的凭据系统来存储您自己的应用程序的凭据。您告诉 Windows 您要提示某些“目标”的“通用”凭据:
伪代码:
然后将导致 Windows 显示一个对话框:
然后,您的工作就是检查用户输入的凭据。如果它们有效,则通过调用ConfirmCredentials告诉 Windows 。这是为了确保只保存有效的凭据:
一旦凭据被确认为有效,Windows 会将它们保存在安全存储中,您可以通过控制面板查看:
关键词:credui, CredUIConfirmCredentials
django - 寻找在 Django 中设置自定义身份验证后端的综合指南,或指针
我正在尝试设置一个自定义后端来查询另一个数据库,为此我在系统中创建了一个模型。它使用自己的规则(电子邮件而不是用户名,以及不同的加盐/哈希密码),所以我不能使用内置身份验证。我已经设置了一个自定义身份验证后端,如下所示:
我添加了 BlahBlahBackend 作为身份验证后端:
AUTHENTICATION_BACKENDS = ('django.contrib.auth.backends.ModelBackend', 'socialauth.auth_backends.OpenIdBackend', 'socialauth.auth_backends.TwitterBackend', 'socialauth.auth_backends.FacebookBackend', 'socialauth.auth_backends.BlahBlahBackend', )
如您所见,我还使用了一些预先存在的身份验证后端,这些后端也在 socialauth 中。
我有一个指向以下观点的提交表单:
但是,当我尝试以这种方式登录时,似乎一个或多个其他后端的行为就好像我正在尝试使用他们的方法登录一样。
我读到后端已缓存,因此运行
清除后端缓存。
我的主要问题是:
- AUTHENTICATION_BACKENDS 中列出项目的顺序
- 系统如何决定/知道使用哪个后端?任何文档都没有明确说明这一点,我觉得这有点令人困惑。
- 有没有办法根据请求强制使用特定的授权。换句话说,如果有人提交表单,有没有办法强制他们使用基于表单登录的身份验证,而不是通过 openid 或 Twitter 登录?
更新:
有用!这很酷,谢谢。我想 django 文档似乎在说“你不必做任何其他事情,它就像魔术一样工作”,事实证明确实如此。只要后端在那里并且凭据设置正确,身份验证就会起作用。事实证明,真正的问题是 urls.py 文件中的错误配置,没有将登录表单中的帖子发送到正确的处理程序,这就是它一直尝试使用另一种身份验证方法的原因。
asp.net - 在与当前用户不同的用户下运行 ASP .NET Web 应用程序
IIS 正在利用当前登录用户的凭据来访问 ASP.NET 应用程序。是否可以在应用程序上创建登录页面并传递其他用户凭据,以便特定 Web 应用程序在不同用户下运行?
git - Git:从存储库中删除凭据
当前状态:我将带有内部数据库凭据的文件提交到我的 Git 存储库。这很好,因为我只单独使用它。然后我的团队开始在这个项目中进行克隆、推送和拉取。我们现在有几个 Git 存储库(一个中央存储库和一些开发人员)。
问题:我们现在想要公开访问源代码和 Git 存储库,或者至少让 Git 管理其他贡献代码的人的详细信息。
问题:什么是一个好的策略
a) 从中央或所有存储库中删除带有凭据的文件,或
b) 建立一个新的 Git 存储库作为与外部世界的“接口”?
如果选择 (b),我们如何轻松地将更改传达回主存储库?
由于已经广泛分布,我们真的不想在每个当前存储库上执行 agit rebase
或 a 。git filter-branch
asp.net - 使用“发现凭据”对话框添加凭据的 Web 参考提示,但不接受有效凭据
我正在尝试向我的 ASP.Net 3.0 项目添加 Web 引用。这是对 SQL Server Reporting Services Web 服务的引用。我已验证该服务已启动并正在运行,但是当我尝试在我的项目中添加 Web 引用时,系统会提示我输入我的凭据,然后再一次又一次地提示。我必须点击取消才能停止恶性循环。当我这样做时,服务定义会出现在窗口中,但“添加引用”按钮被禁用,因此我无法将引用添加到我的项目中。
我对 SQL Reporting Services 配置的了解有限。如果有人知道如何解决这个问题,我真的很感激。