داخلېدونکی bearer غوښتنه کولی شي د سرچینو سرور ته ورسېږي، خو د JWT تصدیق د وتلو JWK ډاونلوډ پر مهال ناکامېږي. هغه HTTP کلاینت ترتیب کړئ چې دا ډیکوډر یې کاروي:

var factory = new org.springframework.http.client.SimpleClientHttpRequestFactory();
factory.setProxy(new java.net.Proxy(
    java.net.Proxy.Type.HTTP,
    new java.net.InetSocketAddress("proxy.example", 8080)));
var rest = new org.springframework.web.client.RestTemplate(factory);

var decoder = org.springframework.security.oauth2.jwt.NimbusJwtDecoder
    .withJwkSetUri(jwkSetUri)
    .restOperations(rest)
    .build();
decoder.setJwtValidator(
    org.springframework.security.oauth2.jwt.JwtValidators
        .createDefaultWithIssuer(issuer));

د اپلیکیشن ریښتیني jwkSetUri او issuer وکاروئ او دا ډیکوډر په ریښتیني سرچینې-سرور ترتیب کې نصب کړئ. بېلګه د servlet سټایل Nimbus ډیکوډر سره بې تصدیقې HTTP پروکسي کاروي. د اجازه شوې عامه-پروکسي لارې پر عامه JWK URL لپاره د HTTP پروکسي لیست د host او port ممکنه ارزښتونه وړاندې کوي.

په بېلګه کې issuer تصدیقوونکی د اړین audience یا نورو اپلیکیشن څېړنو بدیل نه دی. د اتوماتیک ترتیب شوي ډیکوډر د بدلولو پر مهال هغه وساتئ؛ د کیلي-ډاونلوډ لار بدلول نه ټاکي چې اپلیکیشن کوم ټوکنونه ومني.

reactive ډیکوډر بله برخه کاروي. نور د issuer کشف یا ټوکن ترلاسه کولو کلاینتونه هم خپل ټرانسپورټ ترتیب ساتي.

کېش شوي کیلي کولی شي تصدیق پرته له نوي ډاونلوډ بریالی کړي. د لارې ارزولو پر مهال د ناکامې کیلي URL او د تازه کولو یا پیل مرحله وساتئ.

اړوندې مقالې