angular - 使用 Angular 4 和 Asp.Net Core 2 获取 ValidateAntiForgeryToken

Question

我目前正在尝试让 Angular 4 (4.3.5) 在新发布的 Asp.Net Core 2.0 上正常工作，特别是防伪 token 。

我正在使用 JavascriptServices，它提供了入门应用程序(它是 Visual Studio 2017.3 中的默认 Angular 模板)。 Javascript 服务在 .cshtml 页面上托管 Angular 站点的主页。这实际上是非常有益的，因为我可以使用标准表单例份验证(dot net core Identity)锁定所有内容，当用户不在时，它将用户重定向到/Account/Login 的单独(非 Angular)登录页面已登录。然后您可以在该页面上登录并重定向到主页，水疗中心将在授权用户的上下文中启动并运行。

可以找到该工作应用程序 here .

难题的最后一部分是让 ValidateAntiForgeryToken 属性发挥作用。当您登录到帐户/登录页面时，这很好，因为它没有在 Angular 4 的上下文中运行。但是当我在主页上的 Angular 4 中运行时，当我发回服务器时，如果存在该属性，帖子将被 ValidateAntiForgeryToken 阻止。

因此，我在帐户/注销方法上注释掉了 ValidateAntiForgeryToken 属性。这是因为我正在使用 Angular http post 从站点注销。它在不使用属性时有效，但在使用时失败/被阻止。

根据 Angular 4 文档，找到 here ，我更改了 Anti Forgery Token 名称以匹配 Angular 4 识别的名称。为此，我修改了 Startup.cs 文件，添加了一些行，如下所示:

public void ConfigureServices(IServiceCollection services)
{
            services.AddAntiforgery(options =>
            {
                options.Cookie.Name = "XSRF-TOKEN";
                options.Cookie.HttpOnly = false;
            });
...
}

这应该使 Angular 应用程序能够访问具有 Angular 4 期望的名称的 Anti Forgery cookie。

在我的应用程序中，我刚刚改用新的 HttpClient 服务(显然 Http 服务已被弃用!)，该服务应该使用拦截器自动将 XSRF_TOKEN 发送到服务器。

但我一直无法完成这项工作。

我尝试使用 HttpClient 服务进行标准的 post 调用:

this.httpClient.post(this.baseUrl + 'Account/Logout', "", options).subscribe(result => {
    location.replace("/");
}, error => {
    console.error(error);
})

我尝试手动添加 header :

let token = this.cookieService.get("XSRF-TOKEN");
console.log(token);

var httpHeaders = new HttpHeaders({ 'XSRF-TOKEN': token })

this.httpClient.post(this.baseUrl + 'Account/Logout', "", { headers: httpHeaders }).subscribe(result => {
    location.replace("/");
}, error => {
    console.error(error);
})

我尝试在添加和不添加 header 的情况下使用旧服务:

let token = this.cookieService.get("XSRF-TOKEN");
        console.log(token);

        let headers = new Headers({
            //'Content-Type': 'application/json',
            'X-XSRF-TOKEN': token
        });
        let options = new RequestOptions({ headers: headers });
        this.http.post(this.baseUrl + 'Account/Logout', "", options).subscribe(result => {
            location.replace("/")
        }, error => console.error(error));

不幸的是，我没有运气。还有其他人设法让这个工作吗？

Answer 1

好的，我找到了解决方案。

我的 Index.cshtml 页面现在看起来像这样:

@Html.AntiForgeryToken()

<app>Loading...</app>

<script src="~/dist/vendor.js" asp-append-version="true"></script>
@section scripts {
    <script src="~/dist/main-client.js" asp-append-version="true"></script>
}

这样做是在服务器端生成一个防伪 token ，并将其放置在页面的隐藏输入字段中。当您查看页面源代码时，隐藏的输入字段如下所示:

<input name="__RequestVerificationToken" type="hidden" value="CfDJ8DaEnvKVNL9EhPVzHKQWhC-PeT4eNm_svdTEyGZje4WnH34sBfG_D_AphtPzBM1JEkQUHsSX1KWBivxAOtPsOvfMKs5N_dLn0Sr3xRG-N2s0oFaa3-yvG87qdzXYm1yBSYH7dlRiBu5It3wi2iYzWqyo4B1i_iRtmikz41gmuldze8VE72zVqmeHZav5rQiHkw" />

在我的注销方法中，我获取 token 并将其在 header 中提交给服务器端 Controller 。 header 的名称是 RequestVerificationToken，不需要下划线。

Logout() {

    let token: any = $("input[name=__RequestVerificationToken]").val();
    if (token !== null) {
        var httpHeaders: any = new HttpHeaders({ 'RequestVerificationToken': token });

        this.httpClient.post("/Account/Logout", null, { headers: httpHeaders }).subscribe(() => {
            window.location.replace("/Account/Login");
        }, error => {
            console.log(error);
        });
    }
}

在服务器端，AntiForgery 过滤器运行，将其与提交的值进行比较，如果它是预期的值，将允许执行服务器端的帐户/注销方法。

服务器端方法如下所示:

//
// POST: /Account/Logout
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Logout()
{
  await _signInManager.SignOutAsync();
  return RedirectToAction(nameof(HomeController.Index), "Home");
}

在Logout方法中打个断点就可以证明它执行了。

这里可能有一个陷阱。我不确定 token 是否会根据每个请求更改。我没有对此进行任何测试。如果是，则需要在每次请求后向页面添加一个新 token 。

此外，我不需要修改默认 cookie 的行为。我不是按照 Angular 4 的方式来做的。它纯粹是 ASP.Net 方法。即在Startup.cs文件中的ConfigureServices方法中，我已经注释掉了Cookie的变化:

public void ConfigureServices(IServiceCollection services)
        {
            //services.AddAntiforgery(options =>
            //{
            //    options.Cookie.Name = "XSRF-TOKEN";
            //    options.Cookie.HttpOnly = false;
            //});

如果您认为自己找到了更好的方法，请务必发布您的解决方案。