Тое, што браўзер дасягае старонкі ўваходу пастаўшчыка ідэнтычнасці, не даказвае, што сервер ASP.NET Core можа атрымаць метаданыя пастаўшчыка або абмяняць токен. Гэтыя запыты на баку сервера выкарыстоўваюць зваротны канал OpenID Connect.

Для існуючай схемы з назвай oidc наладзьце яе апрацоўшчык падчас наладкі службаў, перш чым пачнуцца запыты аўтэнтыфікацыі:

services.Configure<Microsoft.AspNetCore.Authentication.OpenIdConnect
    .OpenIdConnectOptions>("oidc", options =>
{
    options.BackchannelHttpHandler =
        new System.Net.Http.HttpClientHandler
        {
            UseProxy = true,
            Proxy = new System.Net.WebProxy(
                "http://proxy.example.net:8080")
        };
});

oidc заменіце на фактычную зарэгістраваную назву схемы. Захавайце налады authority, кліента і праверкі токена. Калі проксі патрабуе ўліковы запіс, далучыце патрэбныя ўліковыя даныя да WebProxy.

Праверце, ці праграма ўжо падае options.Backchannel як поўны HttpClient. Калі так, наладзьце маршрут гэтага кліента напрамкі: ASP.NET Core выкарыстоўвае BackchannelHttpHandler пры стварэнні свайго зваротнага канала па змаўчанні, а не для замены ўжо пададзенага кліента.

Каб ацаніць гэтую наладу, выкарыстоўвайце няўдалы запыт выяўлення або токена з боку сервера. Для публічнага маршруту HTTP спіс HTTP-проксі прапануе варыянты для адрасу WebProxy. Палітыка проксі браўзера і іншыя HTTP-кліенты маюць уласныя шляхі наладкі.

Падобныя артыкулы