validationJson Web令牌并在login后redirect
我最近读了Angularjs的Cookies和Tokens ，并实现了login和身份validation部分，以允许用户从login页面login。 该应用程序设置为将账户模块（负责login，账户注册，个人资料等）作为单独的页面，将redirect到主应用程序的SPA。
成功login后，令牌作为JWT发送回login页面客户端，并通过js设置sessionStorage / localStorage值。 最后用户被redirect到（也通过js）到主应用程序。 这个问题是因为我通过jsredirect无法设置头，这显然在加载页面时主应用程序中的身份validation失败（因为我的身份validation中间件比静态和身份validationAPI要求都高）。 如果我尝试在表单发布之后从服务器redirect，而不是在成功时通过JSON返回标记，那么sessionStorage将不会按照博客文章中的描述通过js进行设置。
我已经提出了一些想法，并希望得到有关如果哪一个对最佳实践都有好处的意见。
-
从服务器设置一个响应authenticationcookie'只有'（我们所有的浏览器要求允许这个）cookie在下一个请求中读取到主应用程序。 然后cookie将被服务器读取并允许安全的静态资产被服务。 我最初的想法是设置一个cookie，它违背了在每个请求上使用授权标头的目的，因为即使在第一个API请求中删除了cookie，也可以读取该cookie。
-
允许之前提到的静态资产在不需要authentication的情况下（html，css，application js）和第一个内部API请求（在应用程序中几乎立即被加载）加载，然后通过Angular的$ http拦截器访问请求授权标头。 如果发回401，则相同的拦截器可以redirect到login页面。
我认为第二种方法是比较简单的方法，因为只需要将静态文件中间件下的auth中间件移动到Angular中，然后更新http拦截器，但是认为静态文件可以加载然后redirect事后。 任何input赞赏。
回应你的观点1
…我最初的想法是设置一个cookie，因为在每个请求中使用Authorization标头的目的是失败的，因为即使在第一个API请求中删除了cookie，也可以读取该cookie。
授权头的使用并不是与cookie的使用相互排斥的。 当最适合单页面应用程序和本地移动应用程序的问题时，这个想法就是使用它。 但是，由于它确实依赖于某种客户端存储，最好是sessionStorage，所以如果在旧的浏览器中存在sessionStorage的使用方面的问题，甚至有时甚至使用cookie来存储令牌。 因此，只要你使用cookie来存储令牌，而不是用于authentication，你还没有达到目的。 请参阅后续文章中的第1点 https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/
如果你想知道“但是如果我把曲奇存储在cookie中，我就回到原点”。 实际上，在这种情况下，您将Cookie用作存储机制，而不是身份validation机制（即Web框架不会使用cookie来validation用户身份，因此不会进行XSRF攻击）