>自己的个人资料提供者
>外部提供商,即Google,FB等
可能的情况
>因为我有一个SPA,如果我可以把我的用户保留在我的页面上,那么外部(或内部的)会发生的话,这是最好的.我会显示一个包含特定内容的模态图层(甚至可能在一个iframe中).这可以做吗在线例子？
>具有常用的登录/注册功能Asp.net MVC全页重新加载控制器/视图,然后重定向到我的SPA,当这是成功的.如果用户想要使用外部提供商进行身份验证/注册,还要重定向到外部提供商.
>其他任何可能性？
问题
>您在SPA中做了类似的情况,还是建议如何做？
>我应该使用特定的身份验证模式 – 例如提供我的内部认证/注册类似于外部认证/注册,所以SAP总是会以同样的方式行事
>我也将必须验证我的Web API调用后,用户在身份验证后自己在SPA.有什么指导吗？
这也使我们能够在服务器上设置一个UserContext Angular服务,登录后可以通过整个Angular应用程序进行共享,Google Doubleclick Manager在ng-conf presentation中可以看到这种方法的一些好处.由于Web Api支持Asp.Net身份,认证和授权在MVC和Web Api之间无缝工作.
总结主要利弊：
优点：
>非常容易实施.
>跨MVC和Web Api工作.
>客户端代码不需要关心验证码.
>设置UserContext服务器端角度服务在登录期间一次,使用角度DI可以轻松地在整个SPA中共享.见上述presentation.
>与外部提供商集成,与任何正常的MVC应用程序一样容易.
缺点：
>由于浏览器不将URL的部分哈希#发送到服务器,所以返回的URL将永远是您的SPA的根目录.例如.假设您的SPA根是/应用程序,并且您在未通过身份验证时尝试访问/ app#/ client,则将被重定向到登录页面,但是返回URL将是/ app而不是/ app#/ client服务器无法知道URL的哈希部分,因为浏览器永远不会发送.
>如果您打算在SPA之外使您的Web Api可用,则不支持设计.想像一个试图连接到您的API的控制台应用程序？
所以简而言之,我们用来引导我们的SPA的MVC视图使用[Authorize]以及我们的Web Api方法进行保护.在MVC视图中,我们还使用Razor初始化我们的UserContext Angular服务,以注入我们要公开的任何用户属性.一旦通过单独的剃刀视图加载SPA,其他所有内容都将通过Angular进行处理.
