我有一个运行 .Net 4.5.1 和 Identity 2 的网络应用程序。
在我的 WebApi 中,我有一个 iOSLoginController.cs,它使用从主 .NET Identity 的 AccountController.cs 移植的代码。它是使用 AFNetworking 2.0 从我的 iOS 应用程序提供的。
它在我的本地 iis 本地运行良好。登录正常。但是当发布到 Azure 时,它实际上并没有登录,但它仍然在以下位置显示“成功”:
var result = await SignInManager.PasswordSignInAsync(usernameToCheck, model.Password, false, shouldLockout: false);
// switch on result
switch (result)
{
case SignInStatus.Success: <-- it says it's successful ?!?
但是,如果我立即在 WebView 中使用 AFNetworking 检查,它没有登录并重定向到 Login?ReturnURL=..c(我的应用程序是混合的,使用 Webviews 来获取信息/统计信息,使用 native 来登录/注册并且工作正常在 Identity 1 中很好,这是一个升级站点)
这不是 iOS 应用程序,它在我的本地 IIS 和另一个常规物理服务器上运行良好。但是,当我将 API 的基本 URL 更改为指向 Azure 机器的位置时,它只是没有将人登录...而是说成功... 我通过附加到 VS2015 中的进程进行验证
我也在 web.config 中手动设置了机器 key ,因此当 IIS 开始回收进程时它不会轮换和注销用户。
有什么想法吗?
Best Answer-推荐答案 strong>
现代浏览器引用 Public Suffix List对于被视为公共(public)的 cookie 域。
列表的想法最初来自保护顶级域的需要,例如 .com ,因为任何人都可以为所有以 结尾的域设置 cookie。 com ,这将影响顶级 .com 域的所有站点。
该列表还包含其他被视为公共(public)的域。此列表由社区维护,azurewebsites.net 域以及其他域是此列表的一部分。
因此,一个人不可能在共享域上设置一个 azure 应用程序并劫持其他人应用程序中的 cookie。
关于ios - PasswordSignInAsync 在本地工作,但不在 Azure 中,我们在Stack Overflow上找到一个类似的问题:
https://stackoverflow.com/questions/33116769/
|